Use when Java implementation work should be guided by Test-Driven Development, including maintaining a test list, choosing the next behavior, writing a failing test first, implementing only enough production code to pass, and refactoring while keeping tests green. This should trigger for requests such as Apply TDD; Use test-driven development; Drive this Java change with tests; Write the failing test first; Red-green-refactor this feature. Part of Plinth Toolkit
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/20/2026
What it changes
Passed 18 of 21 test cases with the skill, and 16 of 21 without it.
Without skill77%
With skill86%
Checks it passed that the model alone missed
The response recommends isolating each behavior into individual TDD cycles.
The response selects exactly one single behavior to drive the initial failing test.
The response explicitly lists the 2GB file test as a skipped check and remaining risk in the final summary.
and 2 more in the full report
4 fixed15 passed either way1 still failing2 broke
Pass-rate lift
+9 pp
Tokens
+12%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/20/2026v119 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
I need to implement a Java service for calculating order discounts based on customer tiers and cart totals. Can you guide me through a test-driven development workflow for this? Help me map out the candidate behaviors, pick the first scenario, write a failing test to define the API, and help me implement just enough code to make it pass before we refactor.
What was checked, without and with the skill
Checked
Without skill
With skill
The response lists candidate test behaviors before writing implementation code.
Passed
Passed
The response defines a failing unit test prior to providing production code.
Passed
Passed
The response explicitly states missing tests, skipped checks, or remaining risks at the end of the TDD cycle.
Missed
Passed
case-01 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md64 lines2 files
Test-Driven Development Design
Guide Java developers through Test-Driven Development for implementation work. This is an interactive SKILL.
What is covered in this Skill?
Maintaining or refining a list of candidate test cases
Selecting the next useful behavior or test case before editing production code
Writing a failing test first to clarify the public interface, API shape, or usage of the code
Writing only enough functional production code to pass the selected test
Refactoring new and existing code while tests remain green
Adding newly discovered test cases to the list without losing the current TDD cycle
Reporting skipped checks, missing tests, and remaining risks when verification is incomplete
Constraints
Keep implementation work inside the red-green-refactor cycle, with one selected behavior driving each small change.
MUST read references/054-design-tdd.md before applying TDD guidance
MUST maintain or refine a test list when more than one behavior, edge case, or question is in scope
MUST select the next useful behavior or test case before writing production code
MUST write or describe the failing test first and use it to clarify the public interface or usage
MUST implement only the functional production code needed to pass the selected failing test
MUST refactor new and existing code only after the selected test passes and while keeping tests green
MUST report skipped checks, missing tests, and remaining risks when verification is incomplete
When to use this skill
Apply TDD
Use test-driven development
Drive this Java change with tests
Write the failing test first
Red-green-refactor this feature
Build this behavior test first
Workflow
Build the Test List
Read references/054-design-tdd.md, then list candidate behaviors, edge cases, error paths, integration boundaries, and design questions that may need tests. Add newly discovered cases to the list as work proceeds.
Use when designing, implementing, reviewing, testing, or cleaning up feature toggles, feature flags, kill switches, runtime configuration gates, canary controls, staged rollouts, experiments, or temporary compatibility switches in Java enterprise systems. This should trigger for requests such as Design a feature toggle strategy; Review this feature flag; Add a kill switch safely; Test toggle on and off paths; Clean up an expired feature toggle; Plan controlled rollout and rollback behavior. Part