implement

name	implement
description	Implement one ready slice, bug fix, or PR follow-up from the configured issue tracker. Use when Codex needs to read a durable work item, make scoped code changes, use TDD where practical, run verification, prepare acceptance evidence, and hand off one completed unit of work.

Implement

Implement exactly one ready work item. The input should be a slice issue, bug issue, agent brief, PR follow-up, or local markdown item.

Read docs/agents/issue-tracker.md, docs/agents/triage-labels.md, docs/agents/domain.md, and docs/agents/verification.md if they exist.

Workflow

1. Resolve The Work Item

Resolve the user's link, title, branch, local path, or "next ready item" to a durable work item.

Extract:

• Parent PRD or issue.
• Current behavior and desired behavior.
• Acceptance criteria.
• Acceptance evidence requested.
• Regression checks.
• Out of scope.
• Constraints from comments or prior acceptance records.

If the item is not ready-for-agent and lacks a clear contract, route it back to triage instead of guessing.

2. Inspect The Codebase

Explore the current code fresh:

• Relevant public interfaces and user-visible paths.
• Existing tests and similar implementation patterns.
• Domain vocabulary and ADR constraints.
• Verification commands.

Identify the smallest vertical path that satisfies the work item. Do not pre-design broad future modules.

3. Plan The Slice

Write a short implementation plan:

• Behavior to change.
• Test seam or verification seam.
• Files or areas likely to change.
• Regression checks to run.
• Risks or unknowns.

Use tdd when there is a reasonable test seam. Use bug diagnosis when the task is a bug or a regression and there is not yet a red-capable feedback loop.

4. Implement

Keep changes scoped to the work item.

Prefer this loop:

1. Add or update one behavior-focused test.
2. Watch it fail when practical.
3. Implement the smallest change that makes it pass.
4. Refactor only while tests are green.
5. Repeat for the next behavior.

When no automated seam exists, use a documented manual or command-based verification path and record the risk.

5. Verify

Run the smallest relevant checks during implementation and the broadest reasonable regression check before handoff.

Use docs/agents/verification.md when available. If a required command cannot run, record why and what evidence replaces it.

Collect:

• Commands run and summaries.
• Tests added or updated.
• Manual checks performed.
• CI links or status if GitHub is the source of truth.
• Regression evidence for previous behavior.

6. Prepare Acceptance

Before declaring done, compare the final diff against the work item:

• Every acceptance criterion is satisfied or explicitly blocked.
• Requested acceptance evidence exists.
• Regression checks were run or risk is recorded.
• Out-of-scope items were not included.
• Unrelated changes are explained or removed.

If the user asked for full acceptance in the same round, use acceptance after implementation. Otherwise leave the evidence ready for acceptance.

7. Hand Off

Return:

• What changed.
• Evidence and commands.
• Acceptance criteria status.
• Regression checks.
• Risks, blockers, or follow-up.

Update the issue, PR, or local work item when the tracker config and user request make that appropriate.

Do not merge, close, or mark complete when verification is missing, failing, or blocked.