Why this needs more than one source
A weekly update fails when it treats every tool as a duplicate task list. The useful details are usually distributed by role: intent and coordination in Slack, declared state in Linear, and implementation evidence in GitHub.
The goal is not to count activity. It is to explain what meaningfully changed, which evidence supports that conclusion, and where the systems disagree about the state of the work.
Build the answer step by step.
Each step leaves something concrete to inspect before the next layer adds interpretation.
- 01
Define the project map
Write down the channels, Linear teams, and GitHub repositories that describe the same body of work. Include the Linear project name and stable public keys in the query when similarly named initiatives share a selected team.
Output
One cross-system scope that refers to the same project.
- 02
Fix the reporting window
Use explicit dates and the team timezone. “From Monday 09:00 through Friday 16:00” is auditable; “this week” becomes ambiguous around weekends, distributed teams, and scheduled delivery.
Output
A repeatable temporal boundary.
- 03
Assign each source a job
Use Slack for decisions, risks, and commitments; Linear for issue and project movement; GitHub for pull requests, reviews, comments, default-branch commits, releases, and workflow results. Evidence can cross those roles, but the distinction prevents a merge from being mistaken for an outcome.
Output
A source-aware evidence plan.
- 04
Generate a four-part draft
Ask for outcomes, decisions, blockers, and next commitments. Require a citation on each concrete claim and a separate mismatch list for items whose states differ across Linear, GitHub, or Slack.
Output
A concise draft that preserves traceability.
- 05
Review the exceptions
Check merged work that was not released, completed Linear issues with no matching implementation evidence, and Slack commitments with no owner or due date. These exceptions are often more valuable than the happy path.
Output
A short list of reporting risks and missing evidence.
- 06
Publish with a human owner
The project owner removes noise, confirms interpretations, and keeps citations attached. The update should say “no evidence found” when a section is empty rather than manufacturing progress.
Output
A reviewed update that can survive follow-up questions.
Evidence example
See the evidence path
The example is illustrative. Its purpose is to make the provenance pattern visible, not to imply customer data or a guaranteed conclusion.
Question
What changed in the Acme rollout from Monday through Friday?
ENG-241 moves to urgent while SSO validation continues.
PR #482 merges and CI #1602 passes.
The broad rollout remains held for Friday’s SSO review.
Implementation merged; the rollout is still waiting on SSO.
PR #482 merged with passing checks, but ENG-241 still needs another SSO validation run before Friday’s review. The evidence supports implementation completion, not broad-release readiness. Source citation 01Source citation 02Source citation 03
- 01Blocker escalated
- 02Code merged
- 03Rollout held
Ask a question with clear edges
Try this question
“Create the weekly update for [project] from [start date and time] through [end date and time] in [timezone]. Use selected Slack, Linear, and GitHub evidence. Return four sections: outcomes, decisions, blockers, and next commitments. Distinguish issue completion, merge, release, and verified outcome. Cite every claim, list source mismatches, and say when evidence is missing.”
A good query fixes the scope, time window, output shape, citation requirement, and treatment of missing or conflicting evidence.
Source roles
What each source contributes
Each source contributes a different part of the answer. Timeline keeps those roles distinct instead of flattening everything into one activity feed.
Slack
Decisions, blockers, and commitments
Selected-channel messages, threads, edits, reactions, and shared-file signals.
What to know
A discussion is evidence that something was said, not proof that the work shipped or a decision was approved.
Linear
Declared plan and work state
Issue updates, comments, status changes, assignees, priorities, and projects.
What to know
A Linear status reflects the tracker. It does not prove that code was released or that users received the outcome.
GitHub
Implementation and delivery evidence
Pull requests, reviews, review comments, issues, conversation comments, default-branch commits, releases, and workflow runs from selected repositories.
What to know
Native commit polling follows the repository’s default branch; feature- or release-branch commits may be absent until they reach another captured surface. A merge or passing workflow is not automatically a production deployment, customer outcome, or completed rollout.
Report state transitions, not activity volume.
Ten comments and five commits can be noise. One approved decision, one released change, or one newly discovered blocker can be the whole update. Ask for changes in project state and the evidence behind them rather than a digest of everything that happened.
When the systems disagree, preserve the disagreement. “Linear says Done; GitHub shows a merge; Slack says release is blocked” is a more useful update than choosing whichever status looks most complete.
What this cannot prove
- 01The update is only as complete as the selected channels, Linear teams, and repositories; project names narrow retrieval inside that source boundary.
- 02Timeline can show that an event occurred; it cannot infer customer impact without customer-impact evidence.
- 03Naming and linking conventions improve cross-system retrieval, but the guide does not assume automatic one-to-one issue and pull-request linkage.
- 04Commit polling follows each selected repository’s default branch; use pull-request, release, workflow, or discussion evidence for changes that have not reached it.
- 05Late comments, delayed sync, and work recorded after the reporting cutoff belong in the next update or a clearly marked revision.
- 06A generated update remains a draft until a human owner confirms the interpretation and audience.
Common follow-up questions
Should the update list every completed issue and merged pull request?
Usually not. Lead with changes that affect the project state, then link to detailed evidence for readers who need the full activity trail.
What if Linear says Done but GitHub has no matching change?
Keep it in the mismatch list. The issue may represent non-code work, the repository may be outside the selected scope, or the tracker may be ahead of delivery evidence. The update should not guess.
Can this be used for a non-engineering project?
Yes, if the connected sources match the work. The reporting contract still holds: outcomes, decisions, blockers, and commitments, each supported by visible evidence.
Related walkthroughs
Try it on one real question
Build one update you can audit.
Connect the channels, Linear scope, and repositories for one active project. Generate the update, then challenge every sentence against its citations.
Create a cited update