| 1 | # Slack Conversations |
| 2 | |
| 3 | ## What this source contains |
| 4 | |
| 5 | - Real-time discussions of problems and decisions |
| 6 | - Incident channels where fire-drill decisions were made |
| 7 | - Design discussion threads where tradeoffs were debated |
| 8 | - Questions answered by senior engineers that didn't make it into docs |
| 9 | - Post-merge discussions that explain why something was revisited |
| 10 | - DMs (usually not searchable, scope accordingly) |
| 11 | |
| 12 | Slack is frequently where the *real* decisions got made, especially for smaller changes that didn't warrant a doc. It's also the most ephemeral source. Threads get deleted, channels get archived, and search quality degrades over time. |
| 13 | |
| 14 | ## How to search it |
| 15 | |
| 16 | Slack MCP tools vary. Check which Slack MCP is available and inspect its tool schema first. It may require `mcp_auth`. If authentication fails, stop and report the gap. |
| 17 | |
| 18 | 1. **Author-bounded search.** Messages from the PR author around the PR merge date. Limits scope dramatically and often hits gold. |
| 19 | 2. **Keyword search for the feature name and key symbols.** Include misspellings and casual phrasings. |
| 20 | 3. **PR URL search.** Slack often links PRs when they're reviewed or discussed. Search for the PR URL (or just |
| 21 | 4. **Error string search.** If the code handles a specific error, search for the error string. Incident threads often surface. |
| 22 | 5. **Channel-scoped search.** Narrow to likely channels: |
| 23 | - `#eng-*`. Engineering discussions |
| 24 | - `#proj-*`. Project channels |
| 25 | - `#incident-*` / `#sev-*` |
| 26 | - Team-specific channels for the owning team |
| 27 | - Design review channels |
| 28 | 6. **Thread traversal.** When you find a relevant message, fetch the whole thread. The decision often lives in the replies. |
| 29 | |
| 30 | ## What good evidence looks like here |
| 31 | |
| 32 | - A thread where tradeoffs were explicitly debated ("I was going to use A but B is better because...") |
| 33 | - An incident channel message describing the bug the code prevents |
| 34 | - A question from a reviewer and an authoritative answer from the author or lead |
| 35 | - A reference to a meeting where a decision was made |
| 36 | - A message from a product manager or customer-facing engineer explaining a customer ask |
| 37 | |
| 38 | ## Common pitfalls |
| 39 | |
| 40 | - **Channel archaeology limits.** Very old messages may be gone due to retention policies. If you can't find anything before a certain date, note the retention cliff. |
| 41 | - **Unsearched DMs.** Many decisions happen in DMs that aren't searchable. You'll miss them. That's a known limitation. |
| 42 | - **Speculative jokes as "decisions."** Slack is casual. "Lol just do the thing" isn't a decision, even if it preceded the commit. Look for considered discussion. |
| 43 | - **Context collapse in single messages.** Without the thread, a single message often reads differently than in context. Always fetch threads. |
| 44 | - **Auth failures.** If the MCP isn't authenticated, stop. Don't make up findings. Report that Slack wasn't searchable. |
| 45 | |
| 46 | ## What to return |
| 47 | |
| 48 | For each relevant thread: |
| 49 | - Channel name |
| 50 | - Permalink or thread ID |
| 51 | - Participants |
| 52 | - Date range of the discussion |
| 53 | - The key quotes (verbatim) with attribution |
| 54 | - Context: what thread/incident/discussion this was part of |