- 01EvidenceGives the question a reasoninput
- 02LinearHolds the decision contextrecord
- 03GitHubShows the change and checksbuild
- 04ReleaseWaits for human approvalgate
- 05SlackMakes the state visiblesignal
Give each tool one job
The workflow stays understandable when each system has a clear ownership boundary. GitHub is not the research database. Slack is not the project record. Linear is not the source code repository.
- GitHub: code, pull requests, checks, and releases.
- Linear: issue, owner, evidence, acceptance criteria, and decision.
- Slack: notification, escalation, and operational pulse.
Start with a reason
A useful change begins with a question or observation that a person can understand. Keep the reason attached to the decision so a reviewer can see why the work exists, what is being changed, and what should be checked afterward.
The GitHub Actions documentation explains the automation layer. It does not replace the decision record.
Move through a human gate
An agent may suggest a change and prepare a draft pull request. It should not silently publish changes to the public site. Human review protects voice, accuracy, privacy, and the difference between a useful improvement and a false claim.
A reviewer should be able to move from the notification to the issue, from the issue to the pull request, and from the pull request to the checks without reconstructing the story.
Close the loop
After deployment, the next observation links back to the issue and pull request. The record then shows the full chain: what was observed, what changed, who approved it, and what happened afterward.
Questions people ask
Why not put everything in Slack?
Slack is excellent for attention and coordination, but a durable decision needs an owner, context, acceptance criteria, and a history that can be found later.
Does this require an autonomous agent?
No. The operating model works with manual observations too. Automation can reduce repetition, while the approval boundary keeps the public decision accountable.