implement

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

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`.

From gregwebs/skills-sdlc, MIT.

More from gregwebs/skills-sdlc