This skill uses other skills. If a skill is missing, stop and ask the user to install it.

Before beginning, /update-working-copy

Any modifications to the workflow must be approved by the user.

Agent Delegation

Use the /orchestration skill to manage subagents.

Facts have references

Statements of fact must have references. This can be a reference to:

• a file in the repo (with line numbers)
• a planning document in this flow (with a reference number or at least section indicator)
• a Github issue
• a command run, the state of the environment, and the result

Flow

Phase 1 - A good plan

Delegate planning to a planner sub-agent using /implementation-plan.

An implementation plan needs a spec, that will be task-brief.md with contents:

• For a single user input that is a spec, write the user request verbatim, stripped of any workflow/orchestration modification instructions for you. Do not act on the user request (unless it has workflow/orchestration instructions) yourself.
• Otherwise, provide a summary of implementation needs based on the conversation. If the user input contains a ticket, fetch that ticket information and record it in the brief. The planner output should be persisted as implementation-plan.md.

Have an independent subagent perform an adversarial review of the plan. The exception is if the plan review notes state that this is a trivial change. Use a plan-reviewer subagent if available, otherwise use a reviewer.

Phase 2 - Plan execution

Separate out the specification section from the implementation-plan.md as spec.md. Delete that specification portion from implementation.md. spec.md contents are immutable. If the operator changes a requirement, append that supersedance to spec.md.

Delegate to a fresh coder (falling back to implementer) sub-agent, with only

• spec.md
• implementation-plan.md

If the coder stops due to a plan issue, have the planner sub-agent review the plan issue and revise the plan accordingly. Then restart Phase 2 - Plan execution with the revised implementation plan. The first step will be to make any needed updates to existing changes to satisfy the newly revised plan.

coder sub-agent prompt

Implement an already-approved implementation plan. Do NOT redesign the plan.

Inputs (read both fully, in order)

• spec.md
• implementation-plan.md These are self-contained. The plan restates all needed issue detail.

How to work

• Follow the plan's step-by-step sequence.
• Stay strictly within this ticket's scope. For out of scope bugs or enhancements, suggest creating a ticket.
• Use /verify to verify code as it is written, documenting verifications in verifications.md.
• Read repo documentation (INSERT SPECIFIC DOCS) for conventions before editing code.
• On completion, perform a /code-review of your own code changes without any sub-agents. Your inputs are the spec and your working changes are the fixed point.
• As you work, append to implementation-diary.md a log of what happened during implementation

STOP immediately and report if:

• Verification fails repeatedly
• The plan
  • has a critical gap
  • an instruction you don't understand

Output

Persist a final report as implementation-result.md and make implementation-diary.md available.

Separately, extract all verification (from the plan and anything you performed or recommend) into verifications.md. Provide evidence for all the verifications have been performed along with their results.

Phase 3 - Review

Use /code-review-multi with these files:

• spec.md
• implementation-plan.md
• implementation-result.md
• verifications.md
• implementation-diary.md

During the review, look for additional verifications that will be added to verifications.md. Probe the code by executing it (running verifications or otherwise) and note the result. Update implementation-result.md according to changes made from the code review.

Phase 3 - Verification

Delegate to a verifier (falling back to implementer) sub-agent to perform required verifications. They should have access to

• spec.md
• implementation-plan.md
• implementation-result.md
• verifications.md

Skeptically review the report produced by the verifier. For verifications that are blocked, investigate those claims yourself. For verifications that were ran, review claims of the strength of verifications. If there are issues with the report, have the verifier address them.

verifier sub-agent

Use /verify and verifications.md to determine what verification tests still need to be performed.

Ensure that the changes work as expected in an e2e end user setting. Don't make any changes to data that cannot be undone. If possible work against a backup of data or seed data.

Consider whether any manual verification steps can and should be added as automated tests. Write these additional tests.

For the report, update verifications.md.

Phase 4 - Completion

Use /wrap-up to get the work merged.