agentsclimarketplace
Sign in

054 design tdd

Skill jabrena/plinth/skills/054-design-tdd

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 ToolkitFrom its SKILL.md

Install
npx -y skills add jabrena/plinth --skill 054-design-tdd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its file declares

Copied from the file, not written here

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.8 KB, as published. Nobody here has run it

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

  1. 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.

  1. Select the Next Behavior

Choose the next useful test case: small enough to implement in one cycle, valuable enough to move the design forward, and specific enough to expose the expected observable outcome.

  1. Write the Failing Test First

Write or describe the failing unit, integration, acceptance, or characterization test before production code. Use the test to clarify the public interface, API shape, inputs, outputs, errors, or usage of the code.

  1. Make the Test Pass

Implement the smallest functional production code needed to pass the selected test. Avoid speculative branches, abstractions, framework wiring, or cleanup that is not required by the current failing test.

  1. Refactor While Green

After the selected test passes, refactor new and existing code to improve names, duplication, responsibility placement, type design, and test clarity while keeping the relevant tests green.

  1. Report and Continue

Report the selected behavior, failing-test-first signal, code added to pass, refactoring performed, verification results, skipped checks, missing tests, and remaining risks. Return to the test list for the next cycle.

Reference

For detailed guidance, examples, and constraints, see references/054-design-tdd.md.

What ships with it: 1 file

8.7 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most design frontend skills give

Counted across 1,179 of the 2,086 authors here whose files we hold, read 2026-09-06

  • Commit to a bold aesthetic directionin 31 of 1179, across 24 files
  • Prefer component composition over inheritancein 28 of 1179, across 14 files
  • Animate only transform and opacity propertiesin 27 of 1179, across 22 files
  • Memoize expensive computations with useMemoin 26 of 1179, across 13 files
  • Use semantic HTML elementsin 24 of 1179, across 23 files
  • Virtualize long lists for performancein 21 of 1179, across 10 files
  • Use CSS variables for design tokensin 20 of 1179, across 14 files
  • Implement loading, empty, and error statesin 20 of 1179
  • Lazy load heavy components with Suspensein 19 of 1179, across 8 files
  • Respect prefers-reduced-motion media queriesin 18 of 1179, across 10 files
  • Prioritize CSS-only animations for HTMLin 18 of 1179, across 16 files
  • Use compound components for related UI elementsin 18 of 1179, across 7 files

Said here and by no other author read

  • Read the TDD reference document first
  • Maintain a list of candidate test cases
  • Select the next behavior before writing production code
  • Implement only enough code to pass the test
  • Refactor code while keeping tests green
  • Report skipped checks and remaining risks

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.

Keep looking

Skills are one crate of 626,194. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.