Tdd

Skill patdhlk/skills/skills/tdd

Agent workflow skills with sphinx-needs-backed issues, requirements, and ADRs — drop-in replacement for mattpocock/skills

Install

npx -y skills add patdhlk/skills --skill tdd

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

One thing to look at

0 stars0 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

Test-driven development in vertical slices - red-green-refactor against real behavior, wired into the issue lifecycle (picks up an issue, sets in-progress, closes done). Use when the user wants to build a feature or fix a bug test-first, mentions TDD or red-green-refactor, or hands over an issue ID to implement.

SKILL.md

3.0 KB, as published. Nobody here has run it

TDD

Red, green, refactor — in vertical slices, against behavior. As the worker skill it owns the issue transitions /triage never makes: in-progress when work starts, done when it's verified.

Picking up the work

When the task cites an issue (an ISSUE_xxxx ID or a GitHub #n), resolve it through the configured backend ([tool.patdhlk-skills] in ubproject.toml):

sphinx-needs: fresh needs.json (ADR_0006) → the issue's body, its implements links, and those requirements' shall-statements. The reqs are the acceptance criteria.
github: gh issue view → body, plus the need IDs from its Implements: line, resolved against needs.json the same way.

Set the issue in-progress before the first test (local: edit :status:

strict gate; github: swap the state label). No cited issue → work from the conversation; the loop below is unchanged.

The loop — per slice

Slice the work vertically: each slice is one behavior a user (or caller) can observe end to end — never "the models, then the handlers, then the UI".

RED — write one test for the next behavior. Run it. Watch it fail, and fail for the right reason (asserting the missing behavior, not a typo). A test you never saw fail proves nothing.
GREEN — write the minimum code that passes. Resist building ahead of the test. Run the whole suite, not just the new test.
REFACTOR — with everything green: remove duplication, name things after the domain (the glossary's terms, if the repo has one), simplify. Suite stays green throughout.
Commit the green slice before starting the next.

Test behavior, not implementation: prefer the realest level you can afford (integration over mocked-out units); assert on observable outcomes, not on internals having been called. Mock only at boundaries you don't own.

Closing the work

When all acceptance criteria are demonstrably met (run the suite, show the output — claims without runs don't count):

Set the issue done (local: :status: edit + strict gate; github: close the issue, the Implements: links keep traceability).
If the work completed a requirement still marked draft, offer to flip it to implemented — ask, don't assume; the user may want review first.
Report: slices shipped, suite status, issue + req transitions made.

Hard rules

Never write production code without a failing test demanding it.
Never weaken, skip, or delete a test to get to green — if the test is wrong, say so and fix it as its own visible step.
One slice in flight at a time; the suite is green between slices.
done requires a run with passing output in the transcript, not an assertion that it "should pass".