Menu
Use an opt-in, project-aware test-driven development loop for a feature, defect, or behavior change. Detects the repository's test framework and commands instead of assuming Rails, RSpec, or a direct host executable.
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.
Based on SOC occupation classification
Pressure-test an assumption, architecture decision, estimate, or inherited constraint. Use when the user asks to challenge a belief, play devil's advocate, test reasoning, or find a simpler alternative.
Explain a code location, component, command, or user-facing system flow. Use when the user asks what code does, why it exists, how a feature works, or wants a trace of entry points, branches, dependencies, and side effects.
Prepare difficult technical or delivery news for a client, stakeholder, or team. Use for delays, incidents, security findings, cost changes, failed approaches, or other conversations where clarity and trust matter.
Plan and work through project, client, vendor, or team offboarding. Use for handovers, access removal, ownership transfer, documentation, credential rotation, data cleanup, and knowledge-transfer checklists.
Discover how a codebase already handles a concern before extending it. Use when asked how the repository does something, where a pattern lives, whether implementations are consistent, or what convention new work should follow.
Help the user think through a confusing problem or decision by asking focused questions and reflecting their reasoning. Use when they want to think out loud, untangle a problem, or find the question beneath the question.
| name | test-driven-development |
| description | Use an opt-in, project-aware test-driven development loop for a feature, defect, or behavior change. Detects the repository's test framework and commands instead of assuming Rails, RSpec, or a direct host executable. |
Use this skill when the user explicitly requests TDD or test-first work. Follow the repository's framework, test levels, fixtures or factories, command wrappers, and container boundary.
Describe one observable behavior and choose the lowest test level that gives useful confidence. Start at a public boundary when the change spans multiple components, but do not duplicate the same behavior at every layer without a risk-based reason.
For an existing defect, first add a focused regression test that reproduces the failure. For legacy code without protection, characterization tests may be the safest first step. Never delete or discard existing user code merely because it was written before a test.
One method does not automatically require one test. Test meaningful contracts, branches, boundaries, and failure modes. Prefer real deterministic values; mock slow or external boundaries according to repository conventions rather than mocking every collaborator.
Exploratory code can be useful for learning. Treat it as disposable only when the user agrees and it does not overwrite valuable work. Do not install test tools, change suite policy, or run a huge suite without task-specific need.
Report which tests were observed failing and passing, what wider checks ran, and what remains unverified. Test-first evidence improves confidence but does not replace code review, security judgment, or production-safe rollout.
Adapted from Thoughtbot's rails-consultant
test-driven-development skill at revision f2cb97d. Distributed under the
accompanying MIT license.
