Recent Content Inventory

Recent Content Inventory

Collect recent public/customer-safe content and normalize it into a temporary inventory that an agent can use while creating customer-channel share recommendations.

Sources

Start with these sources:

• YouTube: the feed at $YOUTUBE_FEED_URL (for example https://www.youtube.com/feeds/videos.xml?channel_id=YOUR_CHANNEL_ID)
• X: direct X API v2 using X_API_KEY as a bearer token in cloud agents; fall back to X_AI_BEARER_TOKEN only if explicitly needed. Include original posts, quote posts, and useful reposts amplified by , especially team/customer articles.
• Docs: recent merged PRs in your-org/docs, plus changed docs paths
• Changelog: https://app.your-brand.example/client_version?include_changelogs=true, matching the in-product changelog source
• Blog: RSS feed at https://www.your-brand.example/blog/feed.xml

Do not use Typefully for this workflow. Typefully is for drafting/scheduling/managing posts, not source-of-truth content inventory.

Output

Write temporary artifacts under /tmp/customer-channel-share-recommendations/:

/tmp/customer-channel-share-recommendations/content-inventory-<start-YYYY-MM-DD>-to-<end-YYYY-MM-DD>.json
/tmp/customer-channel-share-recommendations/content-inventory-<start-YYYY-MM-DD>-to-<end-YYYY-MM-DD>.md

The inventory is run context, not a durable artifact. Keep final selected links and source-status notes in the share recommendations report instead of storing the full inventory in data/. Scheduled workflows must not commit or persist the temporary inventory unless the user explicitly asks for a durable report.

Workflow

Run the bundled collector from the Buzz root:

python3 .agents/skills/recent-content-inventory/scripts/collect_content.py \
  --days 14

If running locally and X_API_KEY is unavailable, mark X as unavailable in source_status or run a fresh cloud agent where X_API_KEY is injected. A fresh cloud agent should use direct X API v2 calls; do not depend on xurl.

Item contract

Each item should include:

• content_id
• source: youtube, x, docs, changelog, or blog
• content_format: video, post, quote_post, repost, docs_pr, changelog_item, or article
• title, url, published_at, summary, raw_text_excerpt
• topic_tags, product_tags, audience_tags
• customer_safe, postability, depth
• content_purpose: e.g. launch_update, how_to, workflow_example, technical_explainer, ecosystem, case_study, or reference
• audience, best_for, avoid_for, suggested_angle
• primary_asset_url, supporting_asset_urls
• do_not_surface_reason when postability is low or the item is not customer-safe
• source_metadata with source-specific fields

Prefer concrete, matchable tags over vague labels. Use tags that describe your product's features, integrations, and audiences — for example getting started, integrations, security, admin, performance, or specific <FEATURE> names.

Inventory broadly valuable educational content even when it does not map to a known customer pain point. Strong examples include how-to guides, workflow walkthroughs, technical explainers, ecosystem analysis, and well-performing posts/articles from team members or customers that the account reposted.

Use postability to distinguish a good downstream recommendation from a merely matchable internal artifact:

• high: public/customer-facing and independently useful as a share.
• medium: useful only as a contextual follow-up to a specific thread.
• low: internal, weak, too generic, or better used only as analyst context.

Docs PRs are usually low or medium unless they point directly to a merged public docs page. Use PR metadata as supporting context, not the primary customer-facing asset.

Source status

Always include source_status for every source. If a source fails, capture the non-sensitive reason and continue with other sources.