Use TDD by Matt Pocock to implement a feature or fix through small, observable steps. Agree which public interfaces to test, write one failing behavior test, and add the minimum implementation needed to pass before choosing the next slice of work.
Define the observable behavior and the public interface through which it can be tested. Prepare a TDD request that connects one failing test with a minimal implementation, keeping unrelated cleanup and private implementation assertions outside that increment.
Give the acceptance rule, current behavior, and the public interface that exposes it.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: TDD https://github.com/mattpocock/skills/blob/main/skills/engineering/tdd/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Use Matt Pocock’s TDD for the checkout discount change. First propose the public testing seams, then implement one behavior at a time with a failing test. Expected deliverable: A sequence of failing tests, minimal implementations, and verification for each accepted behavior.
TDD is Matt Pocock’s reference Skill for test-first implementation through public interfaces. It asks the user and agent to agree the testing seams before writing tests, so effort goes toward meaningful behavior rather than private implementation details. Each cycle follows one failing test with one minimal implementation, then uses that feedback to choose the next slice. The current source explicitly separates refactoring into the review stage instead of bundling it into the red-to-green cycle. The collection includes testing and mocking references, while codebase-design supplies shared vocabulary when the interface itself is unsettled. An existing test environment and a clear behavior specification remain necessary.
A new feature, regression fix, and critical integration should each be tested where behavior is observable. These examples show how TDD connects failing tests with minimal changes while keeping private implementation details out of the acceptance criteria.
An observable feature needs concrete acceptance behaviors at its public interface. Describe what callers should be able to do, write a failing test for that behavior, and implement the smallest change that makes it pass. Build the feature through these increments rather than testing private implementation choices in isolation.
A bug fix needs a regression test that reproduces the reported defect with the triggering input. Choose a test seam where the incorrect external result is actually observable, then verify that the test fails before the repair and passes afterward. Assertions about unrelated internals do not protect that failure.
A critical integration test should exercise behavior across a meaningful boundary with known expected results. Identify which dependencies are real and which are replaced by test doubles, then check the combined behavior. The test should detect boundary failures rather than merely confirming that isolated components were called.
A structural change should not alter the behavior callers already rely on. Identify the public outcomes that need protection and establish meaningful tests before a separate refactor proceeds. Reuse the same checks afterward, keeping assertions focused on observable results so moving internal code does not make a correct implementation appear broken.
A TDD cycle needs observable requirements and a working test command. Agree on the public boundary, make one failing test pass with a minimal implementation, and assess broader cleanup separately so each increment remains tied to a specific behavior.
Provide the required behavior and test command. Confirm which public interfaces matter and what each proposed test catches.
Write a test that fails for the intended reason, then implement only enough behavior to pass it.
Use the last cycle’s evidence to choose the next slice. Review refactoring separately once the selected behavior works.
Read another Skill guide and check its original source before using it.
