Implementor

Implementor

Workflow

1. Read the selected Case file in agent_docs/cases/.
2. Validate the Case against the planner sibling skill's templates/CASE_TEMPLATE.md (i.e. ../planner/templates/CASE_TEMPLATE.md within the skills dir; source of truth) when available.

• If the template file is unavailable, inform the user that the source-of-truth template could not be found, then continue with execution by validating required sections directly in the selected Case file.
• If required sections or metadata are missing, stop implementation and ask for a corrected Case (or apply a minimal Case-file fix first if the user asks).

3. Classify Case type from filename:

• If filename ends with -must-fix.md, treat as a must-fix Case.
• Otherwise treat as a standard Case.

4. Ensure branch context:

• For must-fix Cases:
  • Expect to run on the current feature branch being reviewed.
  • If current branch is main or master, stop and ask the user to switch to the target feature branch before implementing.
  • Do not create a new branch for must-fix Cases.
• For standard Cases:
  • If current branch is main or master, create and switch to a feature branch named case/<case-id>.
  • Sanitize <case-id> for branch naming: lowercase, replace spaces/underscores with -, remove unsupported characters.
  • If already on a non-main branch, continue on that branch.

5. Execute the Case scope only; avoid unrelated refactors.
6. Keep edits bite-sized and reviewable:

• Prefer minimal deltas over rewrites.
• Reuse existing project patterns and tools.
• Do not add dependencies unless explicitly required.

7. Run tests per repository-root agent_docs/testing/README.md.
8. Add or update the smallest useful tests for changed behavior.
9. Update agent_docs/testing/README.md when new tests introduce or change testing methodology, conventions, or command patterns.
10. Before finalizing, evaluate whether repository-root README.md should change:

• Update it when the Case changes user-facing behavior, setup steps, developer workflow commands, or core project structure/expectations.
• Skip edits when no reader-visible guidance changed.

11. Re-run targeted tests and report results plus any gaps.
12. Commit changes:

• If validation and targeted verification pass, create a commit by default unless the user asked not to commit.
• If validation or verification fails, do not commit; report failures and next steps.
• Default to one commit per Case.
• Use multiple commits only when it improves clarity for the Case (for example: implementation first, then tests/docs).

Case Handling Rules

• Treat ## Scope and ## Out as hard boundaries.
• Treat ## Definition of Done as acceptance criteria.
• Follow ## Steps (agent-executable) in order unless blocked.
• For must-fix Cases, keep the change set tightly scoped to the single finding represented by the Case.
• If Case instructions conflict with repository reality, choose the smallest safe interpretation and record assumptions.
• If Case is too large for one tight change set, complete the first coherent slice that still preserves correctness and report what remains.

Testing Rules

• First look for agent_docs/testing/README.md at the active repository root and use it as the primary source for test commands and strategy.
• Only if that file is missing, discover existing test commands from repo scripts/config and run the narrowest relevant suite.
• For behavior changes, add minimal tests close to the affected code path.
• If newly added tests introduce a new testing pattern, command, or methodology expectation, update agent_docs/testing/README.md accordingly.
• If implementation changes what contributors/users need to know at repo level, update repository-root README.md in the same Case.
• For non-behavioral refactors, run existing tests without adding new ones unless coverage is clearly missing for touched logic.
• Prefer fast, targeted test runs first; run broader suites when required by the Case or repository rules.

Output Contract

When finishing implementation, report:

• Files changed.
• Commands run for verification.
• Pass/fail outcomes and notable failures.
• Any assumptions, scope trims, or follow-up work needed to fully satisfy the Case.