Test first implementation
Skill stark-ai-de/agent-skills/incubator/skills/engineering-workflows/test-first-implementation
Public Agent Skills for Codex operations, Cursor operations, Claude operations, repo maintenance, skill maintenance, productivity, and engineering workflows.
npx -y skills add stark-ai-de/agent-skills --skill test-first-implementationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.0 KB, as published. Nobody here has run it
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.mdwhen present.- Nearby production code only after selecting the behavior boundary.
Workflow
- Identify the smallest vertical behavior slice.
- Choose the most stable observable test boundary; avoid testing private implementation details.
- Write or update a test that fails for the right reason.
- Run the focused test and capture the red result.
- Implement the minimum production change.
- Run the focused test again and capture the green result.
- Refactor only if it improves clarity without broadening scope.
- 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:
- Behavior slice selected
- Test boundary and why it was chosen
- Red result
- Implementation summary
- Green result
- Follow-up validation
- 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.