Implement behavior with a red-green-refactor loop, observable tests, and small vertical slices. Use when the user asks for TDD, test-first work, regression-first fixes, or a feature that needs clear behavior before implementation.
Scanned 9/1/2026
Install to Claude Code
npx -y skills add stark-ai-de/agent-skills --skill test-first-implementation --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Test First Implementation?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/stark-ai-de-test-first-implementation)More formats (shields.io, HTML) on the badges page.
---
name: test-first-implementation
description: Implement behavior with a red-green-refactor loop, observable tests, and small vertical slices. Use when the user asks for TDD, test-first work, regression-first fixes, or a feature that needs clear behavior before implementation.
license: Apache-2.0
metadata:
author: stark-ai-de
category: engineering-workflows
internal: true
version: "0.1.0"
---
# Test-First Implementation
## Goal
Drive implementation from observable behavior: write a failing test, make it pass with the smallest change, then refactor without changing behavior.
## When to use
- The user asks for TDD, red-green-refactor, test-first implementation, or regression-first work.
- A feature can be expressed as observable behavior, API output, UI state, CLI output, or integration behavior.
- A bug fix should start with a failing regression test.
## When not to use
- The repo has no runnable feedback loop and the user only needs a prototype.
- The task is documentation-only or configuration-only.
- The user explicitly asks for implementation without adding tests.
## Inputs to inspect
- User story, acceptance criteria, bug reproduction, or expected behavior.
- Existing tests, test helpers, fixtures, and package scripts.
- `docs/agents/validation.md` when present.
- Nearby production code only after selecting the behavior boundary.
## Workflow
1. Identify the smallest vertical behavior slice.
2. Choose the most stable observable test boundary; avoid testing private implementation details.
3. Write or update a test that fails for the right reason.
4. Run the focused test and capture the red result.
5. Implement the minimum production change.
6. Run the focused test again and capture the green result.
7. Refactor only if it improves clarity without broadening scope.
8. Run the smallest relevant validation suite.
## Safety rules
- Do not test private helpers just to make coverage easy.
- Do not add snapshots for behavior that should be asserted directly.
- Do not change production code before proving the test fails unless the repo cannot run tests.
- Do not broaden the feature while chasing test convenience.
## References
No bundled references. Use downstream `docs/agents/validation.md` for test commands and domain docs for expected behavior when present.
## Scripts
No bundled scripts.
## Output format
Return:
1. Behavior slice selected
2. Test boundary and why it was chosen
3. Red result
4. Implementation summary
5. Green result
6. Follow-up validation
7. Remaining risks
## Completion criteria
- A meaningful test fails before implementation and passes afterward.
- The implementation is scoped to the selected behavior.
- Validation commands and results are reported.
- Any missing test capability is explicitly documented.
## Failure modes
- If no test framework exists, propose the smallest safe test setup or ask before adding one.
- If the red test fails for the wrong reason, fix the test before production code.
- If the behavior is too large, slice it smaller before coding.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!