tdd

A preserved method from https://github.com/mattpocock/skills at 3cca18b368ae, path skills/engineering/tdd, MIT. 21 of 177 source lines differ (12%), every difference claimed by an entry of the ledger with its reason. Entries: baseline-copies-2026-09-11, pull-2026-09-11, fold-2026-09-11, fold-walk-2026-09-11, series-s7-roster-2026-09-11.

  • harness 3
  • lifecycle 3
  • method 2
  • scope 1

Files

Every difference, as it stands

SKILL.md

---
---
harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: tdd
name: "tdd"
description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
description: "Test-driven development: load before writing code in any build stage, red before green at the seams the spec already pinned. Also fires on 'red-green-refactor' and integration tests."
---
---
 
 
# Test-Driven Development
# Test-Driven Development
 
 
scopechangedfold-2026-09-11

one opening paragraph in the skill's voice: applied on the agent's own judgment before code in any build stage at the seams the ticket and spec pinned, also on 'red-green-refactor' and integration tests; seam shape is codebase-design's, review is delivery-review's with findings returning to implementation, suite pruning is sweep-tests' ticket; its use is recorded in the contribution's account; never announced or offered, never re-asks a settled seam

This discipline applies on your own judgment before writing code in any build stage, red before green at the seams the owning ticket and its spec already pinned; it also fires on "red-green-refactor" and on integration tests. The shape of a seam or interface is codebase-design's; the review of the result is delivery-review's, whose findings return to implementation instead of being fixed in the review context; the pruning of an existing suite is sweep-tests' own ticket. It is applied within the request's scope and its use is recorded in the current contribution's account; it is never announced, never offered, and it never asks the user to confirm a seam the ticket or spec already settled.
 
TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.
TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping: what a good test is, where tests go, the anti-patterns, and the rules of the loop. Every section applies on every cycle: consult them before and during the loop, not after.
 
 
lifecyclechangedfold-2026-09-11

the owning ticket and the Testing Decisions its consumed spec records are read while exploring so settled seams are inherited; the seam confirmation is satisfied by an accepted ticket or spec or a standing testing grant (for a compact change, the accepted observable behavior and existing public interface), and the user is asked only for a consequential seam choice outside the grant; a test-value or doubles judgment retrieves configured guidance through the request loop with receipts carrying delivery and the account carrying application evidence

When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
When exploring the codebase, read the owning ticket and any Testing Decisions its consumed spec records, so settled seams are inherited rather than asked again, and read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
 
 
## What a good test is
## What a good test is
 
 
Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure.
Tests verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. A good test reads like a specification: "user can checkout with valid cart" tells you exactly what capability exists, and it survives refactors because it doesn't care about internal structure.
 
 
lifecyclechangedfold-2026-09-11

the owning ticket and the Testing Decisions its consumed spec records are read while exploring so settled seams are inherited; the seam confirmation is satisfied by an accepted ticket or spec or a standing testing grant (for a compact change, the accepted observable behavior and existing public interface), and the user is asked only for a consequential seam choice outside the grant; a test-value or doubles judgment retrieves configured guidance through the request loop with receipts carrying delivery and the account carrying application evidence

See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines. For a judgment about test value or doubles in this repository, when guidance is configured, retrieve through the request loop in AGENTS.md with the testing task and concern and the actual language and runner; generated receipts carry the delivery, and the current account carries your application evidence.
 
 
## Seams: where tests go
## Seams: where tests go
 
 
A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
A **seam** is the public boundary you test at: the interface where you observe behavior without reaching inside. Tests live at seams, never against internals.
 
 
methodchangedseries-s7-roster-2026-09-11

upstream confirms the seams with the user before any test; greenline lets an accepted ticket or spec, or a standing testing grant, stand as that confirmation and asks only about a consequential unresolved seam, which changes when the method stops to ask Confirmed by the operator on 2026-09-11 (method-rulings.md).

**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them: an accepted ticket or spec, or a standing testing grant, that establishes the public boundary is that confirmation, and for a compact change the accepted observable behavior and the existing public interface establish it. Ask the user only when a consequential seam choice remains outside the grant, not for an ordinary test shape. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
 
 
methodchangedseries-s7-roster-2026-09-11

upstream asks the user for the public interface and the seams; greenline establishes them from the accepted ticket or spec and asks only for a consequential unresolved seam, the same method edit as the seam rule above it Confirmed by the operator on 2026-09-11 (method-rulings.md).

Ask: "What's the public interface, and which seams should we test?"
Establish the public interface and the seams under test from the accepted ticket or spec; ask "which seams should we test?" only when a consequential seam is unresolved.
 
 
harnesschangedfold-2026-09-11

upstream's 'call the Skill tool with codebase-design' is the harness's native skill mechanism, or the installed SKILL.md and support files read directly, carried into any delegated brief

When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), call the Skill tool with "codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), load codebase-design through the harness's native skill mechanism, or read its installed SKILL.md and support files, for the vocabulary; carry the same instruction into any delegated brief. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
 
 
## Anti-patterns
## Anti-patterns
 
 
5 unchanged lines
- **Implementation-coupled**: mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
- **Implementation-coupled**: mocks internal collaborators, tests private methods, or verifies through a side channel (querying the database instead of using the interface). The tell: the test breaks when you refactor but behavior hasn't changed.
- **Tautological**: the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, the spec.
- **Tautological**: the assertion recomputes the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, a constant asserted equal to itself), so it passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, the spec.
- **Horizontal slicing**: writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead: one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
- **Horizontal slicing**: writing all tests first, then all implementation. Bulk tests verify _imagined_ behavior: you test the _shape_ of things rather than user-facing behavior, the tests go insensitive to real changes, and you commit to test structure before understanding the implementation. Work in **vertical slices** instead: one test → one implementation → repeat, each test a **tracer bullet** that responds to what the last cycle taught you.
 
 
## Rules of the loop
## Rules of the loop
 
 
- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
- **Red before green.** Write the failing test first, then only enough code to pass it. Don't anticipate future tests or add speculative features.
- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
- **One slice at a time.** One seam, one test, one minimal implementation per cycle.
lifecyclechangedfold-walk-2026-09-11

upstream sends refactoring to the review stage; here delivery-review never implements, so a refactor its findings call for returns to implementation as its own change

- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.
- **Refactoring is not part of the loop.** It is not part of the red → green implementation cycle; a refactor that delivery-review's findings call for returns to implementation as its own change.

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "TDD"
short_description: "Test-driven red-green-refactor"

The timeline

Each entry that touched this method, with the differences it claimed as they stood at its commit, read from the repository's history.

2026-09-11 baseline-copies-2026-09-11

the cutover to an edited copy (ADR 0039): the composed output written as the copy, every difference from upstream claimed with the reason of the overlay that produced it

SKILL.md

harnesschangedbaseline-copies-2026-09-11

greenline renders its own frontmatter: quoted name and description, the description from the manifest override where one existed, no upstream activation flag

name: tdd
name: "tdd"
description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
description: "Test-driven development: load before writing code in any build stage, red before green at the seams the spec already pinned. Also fires on 'red-green-refactor' and integration tests."
lifecyclechangedbaseline-copies-2026-09-11

greenline prelude, to fold: read the owning ticket and its spec's testing decisions; an accepted ticket or standing grant satisfies the confirmation step; seam design deferred to codebase-design

**greenline prelude: the test-first method within the task.** Read the owning ticket and any Testing Decisions its consumed spec records; inherit settled seams instead of asking again. **Seam agreement in this integration:** the body's user-confirmation step is
satisfied by an accepted ticket/spec or standing testing grant that establishes
the public boundary. Name that inherited seam before testing; do not ask to
confirm it again. For a compact change, the accepted observable behavior and
existing public interface can establish that boundary. Ask only when a
consequential seam choice remains outside the grant, not for an ordinary test shape. Apply this method within the request's scope and record its actual use in the current contribution.
 
For judgments about test value or doubles, follow the AGENTS.md retrieval loop: query the testing task and concern with the actual language and runner, then read useful shared and specific guidance. Generated receipts carry delivery; the current account carries your application evidence. Use codebase-design for a module or seam design question. Review findings return to implementation; the independent delivery reviewer reports findings rather than editing the result it reviewed.
 
Where the body says “Call the Skill tool,” use the harness's native skill
mechanism; if none exists, read the named installed skill's SKILL.md and its
required support files. “Twice” means load both named methods. Carry this
translation into any delegated brief; it does not require a tool with that name.
 
renamechangedbaseline-copies-2026-09-11

renamed skill references and bare roster names in prose (the notation pass)

- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.
- **Refactoring is not part of the loop.** It belongs to the review stage (see the `delivery-review` skill), not the red → green implementation cycle.

agents/openai.yaml

harnessremoved filebaseline-copies-2026-09-11

the renderer generates agents/openai.yaml from the manifest; the vendored copy is not projected

interface:
display_name: "TDD"
short_description: "Test-driven red-green-refactor"

2026-09-11 pull-2026-09-11

pin advance to 3cca18b: upstream moved with no change under the vendored paths

2026-09-11 fold-2026-09-11

the fold (ADR 0039, S3): the prelude is gone; the owning ticket and its Testing Decisions, the seam confirmation an accepted ticket or spec supplies, the guidance loop for test-value judgments and the native skill mechanism sit in the sentences where the loop reaches them; a discipline, so no Handoff section

SKILL.md

scopechangedfold-2026-09-11

one opening paragraph in the skill's voice: applied on the agent's own judgment before code in any build stage at the seams the ticket and spec pinned, also on 'red-green-refactor' and integration tests; seam shape is codebase-design's, review is delivery-review's with findings returning to implementation, suite pruning is sweep-tests' ticket; its use is recorded in the contribution's account; never announced or offered, never re-asks a settled seam

This discipline applies on your own judgment before writing code in any build stage, red before green at the seams the owning ticket and its spec already pinned; it also fires on "red-green-refactor" and on integration tests. The shape of a seam or interface is codebase-design's; the review of the result is delivery-review's, whose findings return to implementation instead of being fixed in the review context; the pruning of an existing suite is sweep-tests' own ticket. It is applied within the request's scope and its use is recorded in the current contribution's account; it is never announced, never offered, and it never asks the user to confirm a seam the ticket or spec already settled.
 
lifecyclechangedfold-2026-09-11

the owning ticket and the Testing Decisions its consumed spec records are read while exploring so settled seams are inherited; the seam confirmation is satisfied by an accepted ticket or spec or a standing testing grant (for a compact change, the accepted observable behavior and existing public interface), and the user is asked only for a consequential seam choice outside the grant; a test-value or doubles judgment retrieves configured guidance through the request loop with receipts carrying delivery and the account carrying application evidence

When exploring the codebase, read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
When exploring the codebase, read the owning ticket and any Testing Decisions its consumed spec records, so settled seams are inherited rather than asked again, and read `CONTEXT.md` (if it exists) so test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
lifecyclechangedfold-2026-09-11

the owning ticket and the Testing Decisions its consumed spec records are read while exploring so settled seams are inherited; the seam confirmation is satisfied by an accepted ticket or spec or a standing testing grant (for a compact change, the accepted observable behavior and existing public interface), and the user is asked only for a consequential seam choice outside the grant; a test-value or doubles judgment retrieves configured guidance through the request loop with receipts carrying delivery and the account carrying application evidence

See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines. For a judgment about test value or doubles in this repository, when guidance is configured, retrieve through the request loop in AGENTS.md with the testing task and concern and the actual language and runner; generated receipts carry the delivery, and the current account carries your application evidence.
methodchangedfold-2026-09-11

upstream confirms the seams with the user before any test; greenline lets an accepted ticket or spec, or a standing testing grant, stand as that confirmation and asks only about a consequential unresolved seam, which changes when the method stops to ask

**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them: an accepted ticket or spec, or a standing testing grant, that establishes the public boundary is that confirmation, and for a compact change the accepted observable behavior and the existing public interface establish it. Ask the user only when a consequential seam choice remains outside the grant, not for an ordinary test shape. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
harnesschangedfold-2026-09-11

upstream's 'call the Skill tool with codebase-design' is the harness's native skill mechanism, or the installed SKILL.md and support files read directly, carried into any delegated brief

When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), call the Skill tool with "codebase-design" for the vocabulary. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.
When the shape of that interface is itself in question (how deep the module is, where the seam belongs, what the interface should expose), load codebase-design through the harness's native skill mechanism, or read its installed SKILL.md and support files, for the vocabulary; carry the same instruction into any delegated brief. It is the shared source of the module, interface, depth, seam, adapter, leverage and locality terms, and it is a reference to consult, not a session to run.

2026-09-11 fold-walk-2026-09-11

the coherence walk: the ask line under the seam rule now defers to the accepted ticket or spec; refactoring returns to implementation through delivery-review's findings

SKILL.md

methodchangedfold-walk-2026-09-11

upstream asks the user for the public interface and the seams; greenline establishes them from the accepted ticket or spec and asks only for a consequential unresolved seam, the same method edit as the seam rule above it

Ask: "What's the public interface, and which seams should we test?"
Establish the public interface and the seams under test from the accepted ticket or spec; ask "which seams should we test?" only when a consequential seam is unresolved.
lifecyclechangedfold-walk-2026-09-11

upstream sends refactoring to the review stage; here delivery-review never implements, so a refactor its findings call for returns to implementation as its own change

- **Refactoring is not part of the loop.** It belongs to the review stage (see the `code-review` skill), not the red → green implementation cycle.
- **Refactoring is not part of the loop.** It is not part of the red → green implementation cycle; a refactor that delivery-review's findings call for returns to implementation as its own change.

2026-09-11 series-s7-roster-2026-09-11

The operator's ruling on the method-class edits put to them by the S3 fold: the edit is kept and re-recorded with the ruling as its authority.

SKILL.md

methodchangedseries-s7-roster-2026-09-11

upstream confirms the seams with the user before any test; greenline lets an accepted ticket or spec, or a standing testing grant, stand as that confirmation and asks only about a consequential unresolved seam, which changes when the method stops to ask Confirmed by the operator on 2026-09-11 (method-rulings.md).

**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them with the user. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
**Test only at pre-agreed seams.** Before writing any test, write down the seams under test and confirm them: an accepted ticket or spec, or a standing testing grant, that establishes the public boundary is that confirmation, and for a compact change the accepted observable behavior and the existing public interface establish it. Ask the user only when a consequential seam choice remains outside the grant, not for an ordinary test shape. No test is written at an unconfirmed seam. You can't test everything, so agreeing the seams up front is how testing effort lands on the critical paths and complex logic instead of every edge case.
methodchangedseries-s7-roster-2026-09-11

upstream asks the user for the public interface and the seams; greenline establishes them from the accepted ticket or spec and asks only for a consequential unresolved seam, the same method edit as the seam rule above it Confirmed by the operator on 2026-09-11 (method-rulings.md).

Ask: "What's the public interface, and which seams should we test?"
Establish the public interface and the seams under test from the accepted ticket or spec; ask "which seams should we test?" only when a consequential seam is unresolved.