You are reading Warestack documentation to propose a change-management pack for the organization that sent you here.

You are not a Warestack administrator. Unless the organization has given you a Warestack-specific tool, you cannot see Warestack’s association store, live cards, DMs, personal digests, open findings, or automation activity. Propose only. Do not enable. Do not invent IDs.

Canonical inputs:

• /catalog.json — machine-readable IDs, statuses, and mappings.
• /llms.txt — documentation index.
• /llms-full.txt — single-file agent brief.
• Use cases — supported jobs and availability.
• Worked examples — response shape when evidence exists or is empty.

Before you propose

1. Load /catalog.json. Use only id values listed there.
2. Inspect this org’s last 14 days of GitHub, Linear, and Slack (if you have those tools).
3. Map observations → objects using propose.needs_to_objects.
4. Prefer week_one (1–2 production repos, merge-blocking off, personal digest as candidate_only).
5. Keep unused catalog rules and available chain kinds in the draft as later.
6. Label cross-repository guards and dedicated SOC 2 period export not_generally_available; do not present them as self-serve today.

Copy-paste starter

Read https://documentation.warestack.com/llms-full.txt and
https://documentation.warestack.com/catalog.json.

Using GitHub, Linear, and Slack on this organization, inspect pull requests and
deployments from the last 14 days and propose a Warestack change-management pack:
in-scope repositories or one team, individual owners, reviewer pool, stable rule
and chain IDs that would have helped (with real PR examples), Linear active states,
Slack destinations, personal-digest candidates, production environment names,
report intent IDs, and candidate cross-repository pairs.

Use status values week_one, on, off, later, candidate_only, not_generally_available, or
unknown. Follow the linked-PR response shape when associated PRs exist, and the
empty-list shape when none do. Propose only; do not change GitHub, Linear, Slack, or Warestack.
Write unknown when evidence is missing. Keep merge-blocking off.

Inspect the last 14 days

• Open and merged PRs, production-path repositories first.
• Linear evidence: no ticket string / string only / native attachment / unknown Warestack association.
• Requested reviewers, human approvals, bot/self approvals, and approval-body evidence.
• Test changes and the concrete Testing section.
• CODEOWNERS, GitHub teams, actual reviewers, mergers, and repository owners.
• Slack channels already receiving review or deployment noise.
• Successful and failed GitHub deployments, exact environment names, and associated PRs.
• Default-branch workflow failures and waiting deployment reviews.
• Large/mixed/stale PR patterns and reviewer concentration.
• Same-repository PR stacks and repository pairs that moved together.
• People who appear in both GitHub and Slack; identity is still unknown until confirmed.

Honesty

• A DEV-XXX in a branch, title, body, or Refs: is not custom.linear_issue_required passing. Catalog 1 is concise PRs.
• A Linear parent does not cover child issues or sibling PRs. Associate each PR with the issue that describes its diff. See How to ticket.
• Catalog 6 accepts a GitHub or Linear issue in Warestack’s store. The recommended Linear-first set tightens it with custom.linear_issue_required.
• Bots and the PR author do not count as human approvals.
• A team cannot receive a Slack DM. Review SLA owner is an individual with GitHub + Slack.
• Changelog = deployment_succeeded on production/prod, not merge.
• Report Run now ≠ Slack announce.
• Personal digest is self-serve from Overview; name candidates only.
• Linear agent requires workspace installation and must not invent owner/repo#n when no PR is linked.
• Pull-request stacks are same-repository. Cross-repository guards are not generally available.
• An available chain marked later is shipped; later is rollout guidance.
• Write unknown rather than guessing.

Use these recommended IDs

Do not number the recommended first-enablement rules 1–8. Catalog rule 1 is concise PRs.

Rules:

custom.linear_issue_required, 7, 8, 12, custom.conventions, custom.feature_test_evidence, 13, custom.evidence_in_approval_body.

Chains:

pull_request_slack_live_card, pull_request_review_sla, scheduled_report, production_rollout_changelog.

personal_digest is candidate_only.

Map common observations

Output the team can send Warestack

Then include this pack table:

First reply (three bullets): in-scope repos, Slack channel for live cards, individual owner per repo.

For every cited PR or issue, use the example response shape: assessment, evidence, severity, blocker, recommended next action, and confidence.

Hard limits

• Do not claim a Warestack association from GitHub/Linear text alone.
• Do not claim a live card, finding, DM, digest, or automation execution you cannot inspect.
• Do not enable anything or mutate GitHub, Linear, or Slack.
• Do not propose merge-blocking. A failing check is not a gate unless GitHub requires Warestack Rules.
• Do not count bot/self reviews.
• Do not map GitHub login to Slack handle by string equality.
• Do not model personal_digest as a repo chain or report.
• Do not model report Run now as scheduled Slack delivery.
• Do not claim the Linear agent mutates by default.
• Do not claim a cross-repository stack.
• Do not claim a dedicated observation-window export or exception-register UI has shipped.
• Do not invent an event, rule, chain kind, report intent, owner, channel, ticket, or environment.

First-enablement safety

Do not turn on chain defaults containing block_merge or fail_check in the first enablement (urgent_pr_needs_reviewer, breaking_schema_change, cicd_change_without_owner_review, rule_fired_act) unless the team explicitly requests a gate and reviews a dry-run where supported.

MCP

Not shipped. Intended tools: warestack.catalog, warestack.propose_pack (no side effects), warestack.explain_rule, warestack.explain_chain. They will use the same IDs as /catalog.json; do not create a parallel vocabulary.