build-from-qa-plan

build-from-qa-plan

buildwriteshands-on

Use this when: you want the doable items off a QA plan actioned

Build from QA Plan

The QA Plan lists what to do; this does the parts that are yours to do safely. The plan's Claude can: lines are the menu — work them, leave everything outward or irreversible to the user.

Contract

• Task class: build — executes work off the plan.
• Allowed tools: gh (pr view/edit, issue edit), git (rebase/push), Bash (browser smoke / checks), Read/Grep. (Web/remote env: mcp__github__* for gh.)
• Direct vs fork: direct — these are stateful git/PR actions; don't fork them to an agent.
• Verifiable artifact: each actioned item is reflected in the PR (rebased / retargeted / commented) and the QA Plan is refreshed so its boxes + State lines match reality.

Act on live state, not the page — this is the skill

Refresh first: run build-qa-plan before you touch anything, so you act on the current PR state, not whatever the issue body said an hour ago. Then, per item, the judgement that carries this skill: is this genuinely safe for me to do, or is it the user's call? Get it wrong and you merge something half-reviewed or rebase over someone's work. The line:

• Safe to do (then confirm the action): rebase a dirty PR onto its base to clear a conflict; retarget a PR's base branch; run a browser smoke / test check; read a PR and summarise its review comments; tick a box once its work is verifiably done.
• Always the user's call (never auto): merging any PR; closing a PR/issue; force-pushing over divergent history; resolving a reviewer's thread; anything posted outward.

Workflow (onion-ordered guardrails — cheapest/most-general check outermost, irreversible action innermost)

1. Refresh the QA Plan (build-qa-plan) and read it.
2. Select the items whose Claude can: / Recommend is in the safe-to-do set above. Present them as a list (AskUserQuestion, multi-select) — "these are the bits I can action: …".
3. For each confirmed item, in plan order:
   • rebase a conflict: git fetch, rebase the PR head onto its base, resolve, run the affected gate (Pint → affected tests; FE checks if FE touched), push. If conflicts aren't mechanical, stop and surface — don't guess a resolution.
   • retarget base: gh pr edit <n> --base <branch> (confirm — it changes the merge target).
   • run a check: execute the browser smoke / test, report pass/fail, attach the result to the PR's State.
   • confirm review comments: read the threads, summarise what each asks, recommend resolve-or-act — but don't resolve threads yourself.
4. Tick & refresh. Update the plan's checkbox + State for each item done; re-run build-qa-plan at the end so the board is current.
5. Stop at the merge line. When the remaining work is "merge in order", hand back: list what's ready and ask which to merge — never merge unprompted.

Failure branch

A rebase that isn't mechanically resolvable, a check that fails, a base that's ambiguous → leave the PR as-is, record the blocker in its plan State line, and tell the user what's needed. Three failed attempts at the same item = stop and question the approach (circuit-breaker), don't keep retrying.

Output / handoff

A refreshed QA Plan with the doable items done and ticked, plus a one-line recap: what was actioned, what's now ready to merge (the user's call), and what's blocked + why. Offer subscribe_pr_activity to watch the merge-ready PRs.