Warestack resolves known Linear identifiers in a PR title, branch, or body against the connected workspace and persists successful matches. Native GitHub attachments from Linear are also reconciled. A raw or unknown key is not proof of linkage: report a link only after the association appears in Warestack. 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 reference / unresolved reference / provider attachment / Warestack association. Only a persisted Warestack association is ready for rule evaluation.
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 Require a Linear issue (custom.linear_issue_required), Require linked ticket to be assigned (pull_request.linked_ticket_assignee), Require active linked ticket (pull_request.linked_ticket_state), and Detect pull request scope drift (pull_request.scope_alignment) can all fire honestly.
Do not hang every repo’s PR off the parent. Detect pull request scope drift (pull_request.scope_alignment) 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 reference PAY-184 while the PR implements a child. Warestack can resolve the identifier, but it would persist the wrong issue for this diff.
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 persisted Linear association, including unresolved keys in the title, branch, or Refs:. Enable custom.linear_issue_required plus pull_request.linked_ticket_assignee, pull_request.linked_ticket_state, and pull_request.scope_alignment. Confirm which workflow states count as active before turning Require active linked ticket on.
Do not
- Infer an association from PR text or provider metadata alone. Report it only when Warestack returns the persisted link; otherwise write
unknown. - 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.