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). If a rule needs schema, migration, API, or frontend context from another repository, name that repository explicitly, configure the rule directly on each source repository, and have a space admin review and approve the exact context binding before it runs. Repository-context rules cannot be team-scoped.
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. Issue provider connected where ticket rules should evaluate Linear or Jira evidence. Active-ticket evaluation uses each provider’s normalized lifecycle category.
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. Connect MCP when Cursor, Claude, or Codex should read the live space.

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 revalidates and executes saved 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 connected issue providers you approve turn on.
• Findings over screenshots. Review the weekly population. Retune noisy rules and add missing controls from observed work.
• Honesty first. Missing Linear context, unavailable referenced-repository context, 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.

Without the Warestack MCP it cannot see Warestack’s association store, live cards, DMs, or findings. Treat that result as a draft. Ask it to propose, not enable, write unknown when evidence is missing, and keep merge-blocking off.

To inspect the live space from Cursor, Claude, or Codex, connect MCP with the same GitHub account as the console. Slack and Linear OAuth still happen in Integrations.