agentleFS
npownpow/claude-skills/slack-digest/SKILL.md

slack-digest

Skill4 starsChanged 6 months agoApache-2.0View on GitHub

Use when generating a weekly Slack digest, summarizing channel activity, finding key discussions, or checking what happened in Slack. Trigger phrases: slack digest, slack summary, channel digest, what happened in slack.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Deliver as HTML: Follow the shared HTML delivery pattern in _shared/html-delivery.md.

    line 72
  2. Distinctive:

    Pair metrics with counter-metrics: Never report activity volume without resolution rate.

    line 80

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Slack Digest

Produce a weekly digest of key Slack threads from configured channels using Slack semantic search MCP tools. The digest surfaces high-engagement threads, groups by topic, and highlights unanswered questions.

Configuration

See _shared/report-config.md for the standard config resolution pattern.

Config schema (~/.claude/skills/slack-digest/config.json):

  • channel_ids: list of Slack channel ID strings
  • lookback_days: number (default: 7)

Required scope: at least one channel_ids entry.

Arguments

  • channel_ids: list of Slack channel IDs to scan
  • lookback_days: how far back to search (default: 7)

Workflow

  1. Search Slack channels. See _shared/slack-search.md for the standard Slack search workflow. Use query terms: "discussion update question issue decision" with size=20 per channel. Count replies per thread from the full thread fetch — this is the engagement signal.
  2. Classify threads. For each thread, determine:
    • Topic category: incident, decision, question, announcement, discussion, or request
    • Engagement level: high (10+ replies), medium (4-9 replies), low (1-3 replies)
    • Resolution status: resolved (answer given, decision made), unresolved (question still open, no conclusion), or informational (no resolution needed)
    • Classification is based on thread content: questions end with ? or start with "does anyone", "how do we"; decisions contain "let's go with", "we decided", "agreed"; incidents contain "incident", "outage", "SEV", "pages".
  3. Identify unanswered questions. A thread is "unanswered" if: it was classified as a question AND has fewer than 3 replies AND no reply contains a clear answer (code block, link, or statement without a trailing ?).
  4. Group threads by topic category. Within each category, sort by engagement (highest first).
  5. Generate report. Output markdown:
## Slack Digest — {date}
Channels: {channel names or IDs} | Period: last {lookback_days} days | Threads analyzed: {N}

### Summary
- Total threads: {N} | High engagement: {N} | Unanswered questions: {N}

### Unanswered Questions (action needed)
(For each: channel, thread summary, who asked, when, permalink)

### Key Decisions
(For each: thread summary, decision outcome, participants, permalink)

### Incidents & Outages
(For each: thread summary, status, permalink)

### Active Discussions
(For each: thread summary, reply count, key participants, permalink)

### Announcements & FYI
(Compact list: summary, permalink)
  1. Deliver as HTML. Follow the shared HTML delivery pattern in _shared/html-delivery.md. Report name: slack-digest. TLDR includes thread count, unanswered questions count, and top discussion topic.
  2. Terminate. Report is complete when all channels are searched and threads are grouped with permalinks.

Design Principles

  1. Team-level only. Aggregate to team level — it is the right granularity for a periodic digest. Individual-level detail (messages per person, reply count per author) is too noisy for a team report.
  2. Deterministic math first, LLM narrates only. Thread counts, reply counts, and engagement levels must be computed from actual thread data. The LLM writes summaries around the numbers but never invents engagement metrics.
  3. Pair metrics with counter-metrics. Never report activity volume without resolution rate. If showing total threads, also show how many were resolved vs left open.

Golden Rules

  1. Fetch full threads, not just snippets. The RAG result is a snippet. Use fetch-slack-thread to get the complete conversation before classifying.
  2. Unanswered questions go first. They represent work stuck waiting for input. Surface them before everything else.
  3. Include permalinks for every thread. The reader must be able to click through to the original conversation.
  4. Count replies from the actual thread, not from RAG metadata. RAG returns relevance-matched snippets, not engagement data. The full thread fetch gives the real reply count.
  5. Check ALL configured channels, not a subset.

Anti-Rationalization Counter-Table

ExcuseReality
"I searched the channel and summarized the top results."RAG results are relevance-ranked, not engagement-ranked. You must fetch full threads to count replies and assess engagement.
"There were too many threads so I sampled a few."Increase the size parameter. The digest must cover the full set of significant threads.
"I classified the thread from the snippet alone."Snippets miss context. Fetch the full thread before classifying resolution status.
"No unanswered questions found, so I skipped that section."Still include the section with "None" — it's positive signal that questions are getting answered.
"I can't get the channel name from the ID."Use the channel_id in the report. The reader knows their own channels. Don't block on cosmetic lookups.

Termination Labels

LabelMeaning
report_completeAll channels searched, threads fetched and classified, grouped with permalinks
report_partialSome channels searched but thread fetch failed for some — noted which
no_threads_foundNo threads in the time window — channels may be low-traffic or IDs wrong
api_errorSlack RAG API unreachable or returning errors

Self-Review Checklist

  • Every configured channel was searched
  • Full threads were fetched (not just RAG snippets) for classification
  • Reply counts come from actual thread data
  • Unanswered questions section appears first after summary
  • Every thread entry includes a permalink
  • Threads are grouped by topic category, sorted by engagement within each group
  • HTML version uploaded to S3 with commuter link (unless --no-html or upload failed with noted fallback)
  • Slack/chat delivery uses TLDR + link, not the full report

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.