# Implementor

> Implement code changes from planner-generated Case files under agent_docs/cases/. Use only when the user explicitly asks for `$implementor`, explicitly asks to use the implementor skill by name, or explicitly asks to execute an existing planner/reviewer Case with this skill. Do not use for ordinary coding requests unless the user specifically invokes this skill.

- Skill: `ooshka/implementor` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ooshka/implementor`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ooshka/implementor/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ooshka (https://skillmd.com/u/ooshka)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ooshka/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.