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 they have connected the Warestack MCP. Without that connection 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 listed IDs: the catalog name plus rule_key, and the four custom.* slugs. Do not cite space-local custom or canary rows as catalog IDs. Do not cite console chips (Rule 1–13) as the identifier.
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,
reviewed report-definition 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 reference / unresolved reference / native attachment / persisted Warestack association / unknown.
• 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.
• Closed GitHub implementation issues without a merged PR; assigned issues without acceptance criteria.
• Release workflow jobs and workflow duration.
• Open actionable review-bot findings and sensitive-path changes without owner approval.
• 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 key in a branch, title, body, or Refs: is only a candidate reference. Warestack may resolve a known issue in the connected workspace and persist the association; report Require a Linear issue (custom.linear_issue_required) as passing only from Warestack’s stored evidence. Require concise pull requests (pull_request.size_limit) is a size cap.
• 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.
• Require a linked ticket (pull_request.linked_ticket) 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.
• Reviewed report IDs are the unprefixed report_definition_id values in /catalog.json; do not invent report.* aliases or SQL. 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.
• A space-local custom rule that follows CLAUDE.md or another instruction file uses its pinned checks. A changed requirement in that file needs re-interpret and adopt. Do not draft a replacement with analyze_rule.
• A trusted rule result covers every pinned check. Missing evidence or incomplete applicability is not a pass; a merge-blocking evaluation without a complete outcome fails closed.
• A reason-required acknowledgement is an audited exception for one exact pull-request revision and finding. Do not describe it as a permanent waiver or a complete exception register.

Use these recommended IDs

Cite the catalog name and rule_key. Console chips Rule 1–13 are aliases. Linear-in-store is custom.linear_issue_required, not Require concise pull requests.

Rules:

custom.linear_issue_required, pull_request.linked_ticket_assignee, pull_request.linked_ticket_state, pull_request.scope_alignment, custom.conventions, custom.feature_test_evidence, pull_request.branch_approval_policy, 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; check whether Warestack resolved and persisted it.
• 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 definition, 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

Shipped. Install at MCP. Endpoint https://mcp.warestack.com/mcp. Sign in with the same GitHub account as the console.

With that connection, call space_status before recommending Slack, Linear, rules, or chains. Needs attention and metrics come from Warestack: list_attention for the review queue, list_metrics and get_metric for KPIs and breakdowns. Do not rebuild that queue or those numbers from the GitHub MCP. You can also read rules enabled on each repository and saved chains. The live catalog is list_rules. Cite the name and rule_key that tool returns. enable_rules takes the integer id from that list, not the rule_key; when configuration is required, ask for the values and pass them through parameter_values_by_rule. Console Quality is API home scope. Do not invent warestack.catalog, warestack.propose_pack, or parameter values. draft_report accepts a reviewed report_definition_id; finish_report takes the confirmed query after needs_confirmation, or the returned revision after a completed preview, and commits the server-owned draft. schedule_report creates missing Slack and email addresses and drafts delivery; email recipients do not need a GitHub identity or space membership.

create_chain and create_rule save drafts. Ask before enable_rules or enable_chain. Leave merge-blocking off. list_attention is the current Overview queue, not complete evaluation history for an arbitrary pull request; finding acknowledgement remains in the console. personal_digest is self-serve; do not create it. Slack and Linear OAuth stay in the console.

Without the MCP, stay on this page and /catalog.json. Do not claim association-store facts you cannot inspect.