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.

# 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 or references a spec without reference to a larger conversation, 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 or attempt to resolve links to specs yourself.
* Otherwise, provide a summary of implementation needs based on the conversation.
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

Delegate to a fresh `coder` (falling back to `implementer`) sub-agent, with only
* `task-brief.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)
- `task-brief.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.
- Read repo documentation (INSERT SPECIFIC DOCS) for conventions before editing code.
- On completion, perform a `/code-review` of your own code changes but 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` 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:

* `task-brief.md`
* `implementation-plan.md`
* `implementation-result.md`
* `verifications.md`
* `implementation-diary.md`

During the review, add any new requested verifications to `verifications.md`.
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
* `task-brief.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

Verify manually that the changes work as expected in an e2e end user setting.
Test edge cases and failure modes in addition to the happy path.
Look at `verifications.md` for verification tests to perform.

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

Don't make any changes to data that cannot be undone.
If possible work against a backup of data or seed data.

Provide a report on verifications performed.
Manual verifications or automated tests not ran on the CI must document how they were ran (pointing to other docs is good) and their result.

## Phase 4 - Completion

Use `/wrap-up` to get the work merged.

From gregwebs/skills-sdlc, MIT.

More from gregwebs/skills-sdlc