To PR

Quick start

When the user asks to turn agreed subtasks into a PR:

1. Use the existing subtasks from to-subtasks.
2. Route through do-subtasks behavior automatically if it has not already run.
3. Create a new branch from the current branch, unless the user specifies another base.
4. Implement each subtask, test it, and commit it separately.
5. Push only after all subtasks are complete and tests pass.
6. Create the PR with gh and return the PR URL.

Workflow

1) Preconditions

• If no agreed subtasks exist, stop and instruct the user to run to-subtasks first.
• Run git status --short to check the working tree. If it prints any files, stop and list the dirty files.
• If the user explicitly says to continue despite a dirty tree, ignore unrelated dirty files and proceed without modifying or reverting them.
• Determine the base branch with git branch --show-current, unless the user specifies another base branch.

2) Do-subtasks routing

• If do-subtasks has not already run for these subtasks, automatically enter its subtask execution model without asking the user.
• After that routing step, ignore the do-subtasks requirement to stop after one task.
• Continue through all agreed subtasks, but keep each commit limited to the current subtask.

3) Branch setup

• Create the work branch from the base branch with git switch -c <work-branch> <base-branch> before implementation.
• Infer the branch prefix from the goal and work type, using conventional prefixes such as feat/, fix/, chore/, ci/, docs/, refactor/, or test/.
• Infer a short kebab-case branch name from the project goal.
• Do not push the branch until all subtasks are complete and tests pass.

4) Implementation loop

For each agreed subtask, in order:

1. Implement only the current subtask.
2. Run the relevant tests or checks for that subtask.
3. Treat the subtask as incomplete until tests pass.
4. Stage only the changes for that subtask, then run git diff --cached --check and git diff --cached --name-only to verify the staged changes.
5. Commit only the verified changes for that subtask.
6. Use a conventional commit message with no scope and no body: <type>: <short description>.

5) Push and PR

• After all subtasks are committed and the full relevant test suite passes, push the work branch with git push --set-upstream origin <work-branch>.
• Before creating the PR, get the authenticated GitHub CLI user's login with gh api user --jq '.login'. Assign the PR to that user by default; use another assignee if the user specifies one.
• Check available repository labels with gh label list --limit 1000 --json name,description. Choose the existing label or labels that best match the changes, using their descriptions when available. Do not create or guess labels. If no available label is appropriate, ask the user whether to proceed without a label or use another label before creating the PR.
• Create the PR with gh pr create --base <base-branch> --head <work-branch> --assignee <login> --label <label> [--label <another-label> ...] and include the project-specific title and body. Replace <login> with the authenticated user's login unless the user specified another assignee, and include one --label flag for each selected label.
• After creation, run gh pr view --json url,baseRefName,headRefName,assignees,labels to verify the PR target, assignee, and labels, and retrieve its URL.
• Use a human-readable PR title based on the project goal, such as Add comments to blog posts.
• Do not use conventional commit style for the PR title.
• If the PR resolves an open GitHub issue, include a closing keyword in the PR body (for example, Closes #123) so the issue closes automatically when the PR is merged.

PR description

Use this format for the PR body. Keep prose brief and use the project's domain language:

## Summary

<diagram, diff sketch, or tree that makes the key change clear>

## Evidence

- **Before:** <screenshot, output, or failing test>
- **After:** <screenshot, output, or passing test>
- **Manual QA:** <practical step-by-step checks, when hands-on verification is useful>

## Merge Danger

**Door:** <one-way or two-way>

**Blast Radius:** <one-word label>

Classify Door by whether merging and deploying the PR is reversible:

• Two-way: reverting the code or deployment restores previous behavior.
• One-way: merging or deploying causes effects a revert cannot undo, such as irreversible data changes.

An explicitly invoked destructive operation does not by itself make the PR one-way.

Choose exactly one blast-radius label for the PR, with no accompanying description in the PR field. Classify the credible failure boundary of the actual changes relative to the PR base:

• Local — failure stays within one component, action, endpoint, or isolated workflow.
• Narrow — failure affects one feature or a bounded set of related workflows.
• Broad — changed shared behavior propagates failure across multiple distinct features or workflows.
• Systemic — failure compromises application-wide operation, cross-cutting security boundaries, or the integrity of shared persistent data.

Identify the changed behavior, its consumers, and where a regression stops. Inspect direct consumers when necessary. Require concrete propagation paths, not speculative chains of unrelated failures. Before selecting Broad or Systemic, identify the affected distinct workflows or cross-cutting boundary and explain the causal link. Missing evidence means uncertainty, not automatic escalation.

File count, directory, shared-code status, and user count do not independently determine the label. Keep impact extent separate from severity, likelihood, and reversibility. Passing tests do not shrink blast radius.

Calibration examples: isolated button styling used by everyone = Local; feature-specific calculation = Narrow; shared URL generation breaking editor, checkout, and exports = Broad; tenant isolation bypass = Systemic.

Choose the smallest representation that explains the change:

• Pseudocode for logic or algorithms.
• A call tree for runtime control flow.
• A component tree for UI structure.
• A shallow file tree for file responsibility or broad refactors.
• Mermaid for interactions or data flow.
• A focused diff sketch when the key point is what changed.

Use visuals only when they help explain the change. Include concrete before-and-after evidence; prefer screenshots for visual changes and test or command output for behavior changes. Write manual QA steps in the style of qa when hands-on verification is useful.

Output rules

• Return the GitHub PR URL when finished.
• Include a concise recap of implemented subtasks.
• Include a brief blast-radius classification rationale in the completion recap, not in the label-only PR field. State any uncertainty.
• If blocked, explain the blocker and the exact next action needed.

Guardrails

• Stick exactly to the agreed subtasks.
• Do not add opportunistic refactors or unrelated fixes.
• Do not modify, revert, or stage unrelated dirty files.
• Do not push partial work.
• Do not create a PR until all subtasks are complete and tests pass.