Stale docs are not a writing problem. They are a placement problem: the explanation lived in a PR, the debate in Slack, the scope in Linear—and the wiki never got the memo.
What this article solves: How the GitHub + Slack + tracker trio keeps documentation tied to work, and when to add Supabase, wikis, or Datadog without boiling the ocean.
Who this is for: Teams evaluating ScopeDocs who want a clear picture of the "core three" vs nice-to-have integrations.
GitHub: truth for what shipped
PRs are the only place where "what we built" and "why we built it" sit next to each other under mild accountability.
When docs generate from PRs:
- Architecture summaries update when services split or merge
- Review comments preserve rejected options (the part ADRs usually forget)
- New hires click from doc → PR and see the real conversation
If your doc cannot link to a merge on main, treat it as suspect.
Slack: where the informal "why" lives
The database choice, the rollback plan, the "we are not doing microservices this quarter" message—often in a thread, not a ticket.
Connecting Slack is not about archiving every channel. It is about pulling decision-shaped threads into docs with a link back to the original message. Future readers verify in one click.
Linear or Jira: the narrative between plan and ship
Linear teams: ticket → PR → doc should read as one story.
Jira teams: same pattern, different UI. Epics and incident tickets matter for compliance-heavy orgs.
Pick one tracker for source linking unless you enjoy duplicate context.
When the backbone is not enough
| Add… | When readers keep asking… |
|---|---|
| **Supabase** | "Which table / migration is canonical?" |
| **Notion** or **Confluence** | "Where is the official handbook?" |
| **Google Drive** | "Which RFC approved this?" |
| **Fathom** | "What did we agree on that call?" |
| **Datadog** | "Which monitor should I trust at 2 AM?" |
You do not mention all of these in every doc. You wire them so the right source appears for the right question. See what to connect first.
Checklist
- GitHub: PR template includes Why + verification
- Slack: engineering channels connected, not the whole company
- Linear or Jira: ticket IDs in PR titles
- One test doc with working links to PR + thread + ticket
- Add Supabase / wiki / Datadog only after a real unanswered question
Bottom line
Current documentation is not more pages. It is fewer lies—because every summary can be checked against the systems where work already happened.