REPRODUCIBLE WORKFLOW SPECIFICATION
Release coordination with GitHub, Linear, Notion, and Slack
REVIEWED SEPTEMBER 2, 2026 / NOT A CUSTOMER PERFORMANCE CLAIM
Create a consistent release record across engineering and communication systems after repository and CI evidence is verified.
EXECUTION ORDER
Actions, purpose, and confirmation
- 01GitHub
get_commitResolve the exact release commit and repository state.
No confirmation for a read.
- 02Linear
get_linear_projectLoad current release scope and unresolved work.
No confirmation for a read.
- 03Notion
create_pagePublish a release brief under the approved project parent.
Confirm parent, title, claims, and linked evidence.
- 04Linear
create_project_updateAttach the verified release status to the project.
Confirm status and final update text.
- 05Slack
post_messageNotify the release channel with links to the brief and project update.
Confirm channel and externally visible text.
Verification checklist
- Repository and commit identities match the intended release.
- Unresolved blocking work is not hidden by the summary.
- Notion and Linear links resolve and contain matching status.
- Slack links to the canonical release records rather than duplicating all content.
Known limitations
- CI and deployment status require provider-specific evidence not represented by a repository commit alone.
- This page is a workflow specification, not proof of a production deployment.
- Release approval remains an organizational decision.
- Write steps should be idempotent or checked before retry.
How to run this workflow safely
Begin with discovery and read-only actions, then verify the selected accounts before any write. Ask for confirmation at the step where the workflow becomes externally visible, financial, destructive, or difficult to reverse. Keep the structured result from every action so the final response can separate completed work from skipped, rejected, or failed steps. Retry only operations that are safe to repeat or protected by an idempotency key.