Enable only the repositories (or one team), Slack channel, and owners you name. Everything else stays off. The goal is one real change moving from issue to production with evidence on every step — not a large day-one rollout.

What we need to start

1. One or two in-scope production repositories (or one team and its repos). Name schema, migrations, or API counterparts only if you want an explicit cross-repo request — that control is not generally available.
2. Slack channel for live cards; optional second channel for the weekly digest and changelog.
3. Individual owner per repository (GitHub login we will confirm in Slack). A team cannot receive a Slack DM.
4. Linear workspace connected; workflow state names that should count as “active.”
5. Reviewer pool from people who submitted human reviews, with confirmed Slack identities where DMs are expected.
6. Production environment name on the deploy-producing repo (production / prod / other) so the changelog matches real GitHub deployments.
7. Who wants a personal digest — each person enables it themselves from Overview › Needs attention › Customize.

Connect GitHub, Slack, and Linear first.

Use the first-run evidence

Repository selection can use recent GitHub activity insights: active repos, branch patterns, linked-ticket gaps, review patterns, and production-path signals. These are setup suggestions, not Warestack rule verdicts.

Then take thirty minutes to:

1. Confirm repository scope and owners.
2. Confirm GitHub↔Slack identities.
3. Activate the recommended rule IDs.
4. Enable the live card and Review SLA only where destinations are ready.
5. Leave merge-blocking off.

What lights up in 48 hours

If the pack is on and identities are confirmed:

• One live card per new in-scope PR in the named channel.
• Warestack Rules on that PR (findings, not a merge gate).
• Review SLA DMs only to requested reviewers and the named owner.
• Overview › Needs attention and Events show the same work with a live timeline.
• Next successful GitHub deploy in production/prod can post a changelog.
• Monday (or the calendar you set) posts the weekly digest — Run now rebuilds SQL; the chain calendar is what announces.

Use See it in action for the response shapes and Use cases to choose optional capabilities.

Merge-blocking

A failing Warestack check is not a proven merge gate unless branch protection requires Warestack Rules. Leave block_merge off until you have reviewed two weeks of findings.

Operating agreement

• Scope lock, then iterate. Only the repositories or team, channels, owners, and Linear states you name turn on.
• Findings over screenshots. Review the weekly population. Retune noisy rules and add missing controls from observed work.
• Honesty first. Missing Linear context, an unavailable counterpart, or an unproven human is unknown, never a pass.
• No surprise DMs. Only confirmed identities, requested reviewers, and named individual owners.

Draft the pack from your last two weeks

Point your org Claude, Codex, or similar at /llms.txt, /catalog.json, and For AI agents. With GitHub, Linear, and Slack on your workspace, it should propose repos, owners, channels, rules, chains, and reports using only those IDs.

It cannot see Warestack’s association store, live cards, DMs, or findings. Treat the result as a draft. Ask it to propose, not enable, write unknown when evidence is missing, and keep merge-blocking off. A future Warestack MCP will serve the same catalog so a dashboard is not required to draft.