Warestack does not treat Refs: DEV-XXX in a PR body as a link. The issue must exist in Warestack’s store and be associated with the pull request. Then:
- Linear keeps the native GitHub attachment.
- Warestack maintains one resource on that issue, updated for the life of the PR (reviews, checks, findings). No duplicate resources on later edits.
- Slack cards and slash commands show the same association.
Classify PRs honestly: no ticket string / string only / GitHub↔Linear attachment / Warestack associated. Only the last is “already governed.”
How to ticket so Warestack can govern
Warestack evaluates this pull request against the Linear issue associated with it. It does not inherit a parent issue onto child issues, and it does not treat sibling PRs as one pass.
Use Linear parent/sub-issues for planning. Put the association on the sub-issue that describes this diff.
| Kind of work | Linear | Associate the PR to |
|---|---|---|
| One change in one repo | A single issue is enough | That issue |
| End-to-end feature across repos (API, UI, schema, …) | Parent = the outcome. One sub-issue per repo / independently reviewable PR | The sub-issue for that repo, not the parent |
| Several stacked PRs in the same repo | One issue per layer if the diffs differ | Each layer’s own issue. Stacks show order; they do not share governance |
Each sub-issue should be assigned, in an active workflow state you name, and have acceptance criteria that match that diff. Then custom.linear_issue_required, catalog 7, 8, and 12 can all fire honestly.
Do not hang every repo’s PR off the parent. Rule 12 compares files and diff with the associated issue’s title, description, and acceptance criteria. A frontend PR linked to “ship checkout across API, UI, and schema” looks like scope drift even when it is the right feature.
Do not rely on PAY-184 in the branch while the PR implements a child. A ticket string is still not association.
Cross-repository delivery order is not a stack. Same-repository stacks are available today. Named counterpart-repo guards are not generally available.
Linear agent
After an admin installs/enables the Warestack workspace agent, mention or delegate to it on the Linear issue. It uses Warestack evidence only: linked pull requests, checks, reviews, unresolved findings, repository status, team attention / violations / activity, and workload. It does not invent a ticket association. In the default governance turn it does not mutate GitHub or Linear.
Typical asks:
- “Summarize this issue’s linked PRs, checks, reviews, and open findings.”
- “Does the linked PR match this issue’s scope?”
- “Who on this team has capacity to take the next related ticket?”
Creating follow-up issues, commenting a checklist, or changing assignment is not part of the default turn. Enable those actions explicitly.
When a PR exists
Short assessment per PR: evidence, severity, blocker, recommended next action, confidence. Name owner/repo#n only from Warestack’s snapshot.
When several PRs are associated with one issue, the agent assesses each PR separately: an on-scope helper blocked on two human approvals, a large backend refactor with scope drift, and a frontend change that does not implement the issue. It recommends review for the first and link verification for the others.
When no PR is linked
Say so. Do not invent a repository or number. Suggested next action: link the PR if it exists in GitHub but is not synced; otherwise name the blocker.
If someone asks it to compare “the linked pull request” and the stored list is empty, it returns unknown and asks for owner/repo#n rather than guessing.
See both agent response shapes →
Connect Linear from Integrations.
Propose this when
PRs with no Linear association, or only a key in the title/branch/Refs:. Enable custom.linear_issue_required plus catalog 7, 8, 12. Confirm which workflow states count as active before turning 8 on.
Do not
- Treat a GitHub↔Linear attachment as Warestack association unless you can see it in Warestack (you usually cannot — write
unknown/ “string or attachment only”). - Treat a Linear parent as covering child issues or sibling PRs. Associate each PR with the issue that describes its diff.
- Invent
owner/repo#nwhen no PR is linked. - Describe create/comment/assignment actions as enabled by default. The normal governance turn is read-only.