pr-lifecycle

Everything that happens after git push on a PR: spec-issue linking, CI triage, review-comment discipline, webhook subscription + the post-push sweep, and the manual ticking of Plan items / umbrella trackers on merge.

This is the repo-agnostic half. The consumer repo's CLAUDE.md / <repo>-dev-process overlays its CI-failure patterns, its scope (which repos this operates on), and any repo-local automation (a pr-spec-sync workflow, audit scripts) or the lack of it.

Tool discipline

• No gh CLI, no hub, no direct GitHub API. Always use mcp__github__*.
• Scope to the repo you're working on (and any sibling the repo's CLAUDE.md sanctions). Don't query unrelated repos.
• Don't open PRs unless the user explicitly asks. Creating one is a one-way door in this workflow.

Spec-issue linking (mandatory)

Every PR must either:

1. Link to a spec issue in its body via Closes #N / Fixes #N / Resolves #N (slice complete) or Part of #N / Refs #N (scaffolding), OR
2. Carry the trivial label (typo, doc-only, one-line obvious fix).