Customer Channel Share Recommendations

Customer Channel Share Recommendations

Use this skill when the user wants suggested customer-channel posts or content ideas based on customer-channel analysis and recent brand content.

Inputs

Use the temporary analysis outputs from customer-channel-analysis:

• /tmp/customer-channel-analysis/customer-channel-analysis-<analysis-start>-to-<analysis-end>.md
• /tmp/customer-channel-analysis/customer-channel-analysis-<analysis-start>-to-<analysis-end>.json
• prior share-channel recommendation threads or explicitly provided prior reports when useful

Pull recent content fresh for each run with recent-content-inventory. The content inventory is temporary run context under /tmp, not a permanent data/ artifact.

Slack message content should stay in Slack. If a recommendation depends on prior channel history, use Slack links/API calls during the run rather than storing message excerpts in durable artifacts.

Golden path

Prepare a context packet if helpful:

python3 .agents/skills/customer-channel-share-recommendations/scripts/prepare_context.py \
  --analysis /tmp/customer-channel-analysis/customer-channel-analysis-<analysis-start>-to-<analysis-end>.json \
  --content /tmp/customer-channel-share-recommendations/content-inventory-<content-start>-to-<content-end>.json \
  --output /tmp/customer-channel-share-recommendations-context.md

Do not write recommendation reports to data/ unless the user explicitly asks for a durable report.

Then have the agent curate the final recommendations. Do not rely on code to decide which content matches which channel; the match requires judgment, channel context, and creativity.

For a weekly scheduled run:

• First refresh customer-channel memory by running customer-channel-analysis over its normal rolling analysis window, currently --days 180, and use the resulting analysis as the current channel-memory layer.
• Use a 7-day customer-channel activity window only for the weekly delta: new Slack activity, changed priorities, already-posted links, and what happened since the last run.
• Use a 14-day recent-content window so useful brand content has enough time to match customer interests.
• Build the recommendation context from both layers:
  • weekly delta: new activity, new questions, changed priorities, and already-posted links from the last 7 days;
  • refreshed channel memory: standing workflows, recurring pains, evaluation criteria, sensitivities, and older unresolved interests from the rolling analysis window.
• Do not treat the 7-day window as the full customer profile. It is only the freshness layer.
• Read prior share-channel recommendation threads or explicitly provided prior reports when available to avoid repeating the same suggestion unless there is a newly relevant reason.
• Produce one concise internal summary, one recommendation note per configured customer channel, and one additional general-content note for broadly useful customer-safe content.
• If the scheduled prompt explicitly asks to post to Slack, use the optional share-channel delivery step below.
• For scheduled Slack delivery, keep collection and recommendation working files temporary unless the user explicitly asks for a durable report.

Output

Write the final curated report to temporary run context:

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

Recommendation rules

For each channel, decide whether to share something, follow up without sharing content, or do nothing this period.

Consider two recommendation modes:

• direct relevance: the content answers a need, question, pain point, workflow, or feature area already present in the customer channel.
• general value: the content is likely useful or interesting to that customer even without a direct open thread, such as a high-performing post, a well-made how-to guide, a workflow example, a technical explainer, an ecosystem article, or a team/customer article amplified by your brand.

Do not limit matching to keyword overlap. Use judgment about the customer's sophistication, current evaluation stage, and what would feel helpful rather than promotional.

Before recommending a post, check Slack history for:

• whether the URL or title was already posted;
• whether the topic has already been covered;
• whether the suggestion contradicts prior guidance;
• the best prior Slack thread to link in the suggested post.

Classify each recommendation as safe to post, contextual follow-up, or do not post.

Content exclusions for enterprise channels

• Be careful proactively surfacing features that could reduce the customer's spend (e.g. features that let customers lower their usage or bring their own resources). Only discuss if a customer specifically asks.
• Never share "how we built it" or source-code-walkthrough content in customer channels. Customers want content that helps them extract more value from the product, not content about its internals. Deep-dive "how it works" content is for the developer community, not for enterprise customer channels.
• Hold content recommendations when a customer is experiencing a disruptive incident. A disruptive incident is one where multiple users are blocked, a feature is broken in a way that prevents normal work, billing/credit issues are cutting off access, or a privacy/security issue has eroded trust. Routine bug reports, one-off questions, and non-blocking issues are not holds — these are normal support interactions and should not prevent sharing useful content. Resume recommendations after disruptive incidents are confirmed resolved.

Suggested copy must be customer-sendable as written. The blockquote under Suggested post: should contain only text that would make sense to paste directly into the customer Slack channel. Do not put caveats, analyst reasoning, or meta-commentary inside the suggested post.

If a recommendation needs explanation, caveats, or rationale for the user, put it outside the blockquote under Internal note:. Link the relevant Slack thread when referencing prior discussion. Prefer public customer-facing assets; use docs PRs only as analyst context unless the public docs page is the actual asset.

Optional Slack delivery to share-channel

This workflow may post an internal recommendation summary to the channel in $SHARE_RECOMMENDATIONS_CHANNEL_ID only when either:

• the user explicitly asks to post/send to Slack; or
• the skill is running in scheduled mode and the scheduled prompt explicitly says to post to share-channel.

Never post to customer channels. The customer channel names and IDs in this workflow are input signals only; they must never be used as Slack chat.postMessage destinations. Do not post as Buzz or any Slack app into any customer channel. Customer-facing suggested copy is for the internal team to review and manually send if appropriate.

The internal Slack delivery format is:

• one short parent message in the share channel summarizing the weekly run and top recommendations;

• one thread reply per configured customer channel;

• one additional thread reply titled General customer-safe content that surfaces broadly useful content that could be valuable to many customers even when it is not tied to a specific customer-channel signal;

• every channel name must be a Slack channel link using <#CHANNEL_ID|channel-name>, including the share channel and customer channel names;

• each thread reply should start with a single recommendation sentence that merges the recommendation, match type, and content into one clear sentence with the recommended content linked;

• the second sentence should explain why the recommendation fits that channel;

• include suggested customer-channel copy only when it is useful for internal review, and keep it clearly separated from the recommendation rationale. The general-content reply should list 2-5 linked items with one short sentence each explaining why the item may be broadly useful. Do not draft customer-channel copy in the general-content reply; the internal team should decide which customers, if any, receive those shares and what to write. Use different parent-message styles for tests and production:

• Test DM parent messages may say TEST, explain the message shape, and mention that no customer channels were posted to.

• Production the share channel parent messages must not include test scaffolding, formatting explanations, or meta-commentary about the workflow. They should read like a normal internal weekly update.

• Production parent messages should be 2-3 sentences: title/date, what was reviewed, and the highest-priority linked customer-channel recommendations to inspect in the thread.

• Production parent messages should link the share channel and every mentioned customer channel with Slack channel-link syntax.

Production parent-message style:

*Customer-channel content suggestions — <date>*
Reviewed the last 7 days of customer-channel activity, refreshed rolling customer-channel memory, and recent brand content from the last 14 days. Best current suggestions are for <#CHANNEL_ID|customer-channel>, <#CHANNEL_ID|customer-channel>, and <#CHANNEL_ID|customer-channel>; see thread for per-channel recommendations, suggested customer-channel copy, and broadly useful customer-safe content.

Before posting, create a temporary JSON payload like:

{
  "parent_message": "*Customer-channel content suggestions — <date>*\nReviewed the last 7 days of customer-channel activity, refreshed rolling customer-channel memory, and recent brand content from the last 14 days. Best current suggestions are for <#C000000000A|shared-customer-a> and <#C000000000B|shared-customer-b>; see thread for per-channel recommendations, suggested customer-channel copy, and broadly useful customer-safe content.",
  "thread_replies": [
    {
      "customer_channel_name": "shared-customer-a",
      "reply_text": "*<#C000000000A|shared-customer-a>*\nSuggest sharing <https://example.com|Example brand content> because it connects to their current evaluation workflow.\nWhy this fits: They have been discussing similar workflow needs, and this gives the internal team a concrete customer-facing asset to consider.\n\nSuggested customer-channel copy:\n> ..."
    },
    {
      "reply_text": "*General customer-safe content*\n- <https://example.com/how-to|Example how-to guide>: Broadly useful for customers learning a product workflow, even when there is no active channel-specific thread.\n- <https://example.com/technical-explainer|Example technical explainer>: Useful background for technical evaluators who want deeper context before sharing internally."
    }
  ]
}

Then post it with:

python3 .agents/skills/customer-channel-share-recommendations/scripts/post_growth_devex_summary.py \
  --input /tmp/customer-channel-share-recommendations/share-slack-payload.json

The posting script is intentionally hard-wired to $SHARE_RECOMMENDATIONS_CHANNEL_ID and must refuse customer-channel destinations.

Suggested scheduled-agent prompt:

Run customer-channel-share-recommendations in scheduled weekly mode for the configured customer channels. Use the attached skill as the source of truth for inputs, windows, formatting, Slack delivery, temporary artifacts, and safety rules. For this schedule, produce and post the internal weekly share-channel summary/thread to the share channel only, including the general customer-safe content thread reply; never post to customer channels.