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. Treat cross-repository context as available only after a space admin reviews and approves its exact rule binding. Keep dedicated SOC 2 period export not_generally_available.

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), linked-ticket lifecycle evidence,
Slack destinations, personal-digest candidates, production environment names,
reviewed report-definition IDs, and rule descriptions for any required cross-repository context.

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 known team key in the branch or title, a terminal Refs: trailer, or an explicit Linear issue URL is only a candidate reference. Arbitrary body mentions are ignored. Report Require a Linear issue (custom.linear_issue_required) as passing only from Warestack’s persisted association. Require concise pull requests (pull_request.size_limit) is a size cap.
• Jira evidence comes from selected-project collection and exact persisted remote-link associations. A Jira-like token or raw Jira URL in pull-request text does not establish an association.
• 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 verified GitHub, Linear, or Jira association in Warestack’s evidence 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. A custom rule may use a separately space-admin-approved, bounded cross-repository context binding; never describe that context as a stack or blanket repository access.
• An available chain marked later is shipped; later is rollout guidance.
• Write unknown rather than guessing.
• A rule that follows CLAUDE.md or another supported repository instruction file interprets the applicable base-revision instructions on every evaluation. A normal custom rule still uses reviewed persisted checks. See Custom rule interpretations.
• A trusted rule result requires complete reviewed-check outcomes or complete authorized runtime instruction/context inputs. 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. A GitHub user with Maintain or Admin access may use the exact command from the current check without a Warestack account. 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 includes follow-up from a pull-request author’s actionable review-thread reply or explicit @mention in a pull-request comment; a head change only refreshes an already-current review-request or changes-requested item. list_metrics, get_metric, and get_metric_breakdown provide KPIs, trends, and bounded contributor pages. Preserve the breakdown’s as_of, definition, and evidence quality across pages. Do not rebuild that queue or those numbers from the GitHub MCP. Use list_repository_rule_context, get_rule_context_binding, and list_rule_context_receipts for content-free scope, currentness, receipt, and cost-capture evidence; these tools are not admin-only and cannot approve or stop a binding. Use list_chain_activity for persisted outcomes rather than assuming a prepared action was delivered. For a Jira issue-creation chain, use a connected jira_configuration_id from space_status and a project-specific type from list_jira_issue_types; installation and write-scope approval remain in the console. 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. It refuses repository_context rules, whose exact scope and enablement remain in the Rules drawer’s Interpretation tab. 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 destination 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. The MCP does not acknowledge findings; use the console or the exact GitHub comment command offered by the current check. 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.