Menu
Use when doing TDD or when dev-workflow routes implementation through a Test List.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Use when finishing a branch or PR after verification and review, including merge, PR publication, keep, discard, cleanup, local sync, and reporting merge or PR URLs with current git state.
Use when handling received code-review feedback on a PR or diff, including requested changes, inline comments, approvals, non-blocking notes, and disputed suggestions. Separates accepted fixes, refutations, deferrals, clarification needs, and merge handoff.
Use when preparing a focused code-review request for a PR or diff after implementation evidence exists, especially to package scope, reviewer focus, PR URL, verification, known risks, and deferred work without deciding final submit readiness.
Use before every submission to decide whether required checks, artifacts, and branch evidence are complete enough to submit.
Use when work is complex, long-running, multi-step, cross-boundary, likely to span multiple PRs/sessions, or needs handoff-ready planning under plans/.
Use when adding or changing Agent-facing workflows, generated prompts, collect plans, executable handoff artifacts, CLI workflows, controller/target-local workflow chains, or validation artifacts consumed by downstream reports. Do not use for ordinary code changes without an Agent-facing workflow or generated instruction surface.
| name | test-driven-development |
| description | Use when doing TDD or when dev-workflow routes implementation through a Test List. |
| metadata | {"short-description":"Test-driven development workflow"} |
Use this skill to keep TDD as a repeatable procedure: you do not “jump ahead” into a large implementation.
The workflow is: Test List → pick one → Red → Green → Refactor → update the list → repeat.
Use this skill when:
Open references/test-driven-development.md. Start from the template.
Write a Test List first (3–10 items). Seed it from acceptance criteria or Definition of Done when available. Pick the smallest item.
Red: write the failing test with a clear name and intent.
Green: implement the simplest code to pass.
Refactor: improve readability / modularity while keeping tests green. If implementation-economy is active, stay within the complexity budget or update the audit before continuing.
Repeat: update the Test List (split or reorder), then go back to step 2.
