Tdd slice

TDD Slice

One caller-visible or user-visible behavior, one focused check, smallest source change.

Rule

Use this only when approved work changes caller-visible or user-visible behavior, adds a new behavior path, or an understood bug needs a new durable behavior or regression check.

Do not use this as the default for every bug, refactor, or repeatable check. Use diagnose-loop when the failure is not understood. Use codebase-cleanup only when a behavior-preserving refactor has structure, caller-interface, testability, duplication, or obsolete-code risk. Use verify-before-done for final claim wording.

First visible move:

Behavior:
Caller/user:
Public or caller contract:
Focused check:
Existing check or new check:
RED needed: yes|no and why

Prefer an existing caller-facing or user-facing check when it already covers the behavior. Write a new check only when behavior is missing, changed, or unprotected.

Fast Path

Use when an existing caller-facing or user-facing check already covers the behavior.

• State the behavior and check.
• Run the check before the change when preserving behavior, or use the reproduced failure from diagnose-loop.
• Make the smallest source change.
• Rerun the same check.
• Use verify-before-done for final done, fixed, passing, ready, or covered claims.

Stop there unless the change expands behavior, weakens the check surface, or adds generated/config/workflow/dependency risk.

RED/GREEN Path

Use when behavior is missing, changed, or unprotected.

1. Write or identify one focused caller-facing or user-facing check.
2. Run it and confirm it fails for the right reason.
3. Make the smallest source change that explains the failure.
4. Rerun the focused check until it passes.
5. Clean up only after GREEN, then rerun the focused check.
6. Run the smallest nearby broader check when risk warrants.

If the check passes immediately, do not edit source from that check. Inspect whether the behavior already exists, the assertion is too weak, or the test surface is wrong.

If RED fails for setup, spelling, fixture, or a different symptom, fix the check or use diagnose-loop before changing source.

Test Shape

Prefer the highest practical caller-facing or user-facing entry point: API, CLI, UI/workflow, command, job, exported module, or integration path users or downstream callers use.

Use simple inputs, fixtures, and states that show the behavior clearly. Keep one main action per check.

Avoid:

• private-shape tests
• mock-call-only tests
• snapshot-only assertions
• implementation-copied expectations
• batches of imagined tests before source changes
• dependency hooks, flags, or options that exist only to make tests easier

Mock only dependency boundaries you do not control, such as network, time, randomness, file systems, external processes, or third-party services. Keep enough real observable behavior that the check would fail if the behavior regressed.

If the only possible check is private, shallow, or setup-heavy for non-low-risk work, stop and question the entry point. Use codebase-cleanup only when a behavior-preserving structure or testability cleanup can unblock a useful behavior check. Stay in this skill when the source change is part of the approved behavior slice; use clarify-scope when the behavior, contract, or test surface needs a decision.

If No Test Setup Exists

Create the smallest repeatable check available: script, fixture, CLI command, smoke command, or repeatable manual check.

The check should observe caller-visible or user-visible behavior strongly enough to guide the source change. If no repeatable check can be created without a behavior, dependency, data, or interface decision, stop and ask before changing source.

Stop Or Ask

Stop or ask before source edits when:

• behavior, public or caller contract, acceptance check, or non-goal is materially unclear after cheap repo evidence
• the first check cannot fail for the right reason because the entry point, fixture, setup, state/data path, or dependency boundary is unknown
• the change would exceed the approved slice or alter API, CLI, UI workflow, data contract, dependency behavior, migration, security/data path, or user-visible behavior beyond scope
• the only available check is private, shallow, or mock-only and risk is not low
• RED contradicts the request, existing tests, fixtures, docs, logs, CI, or caller contract
• a broader check fails after GREEN for a reason unrelated to the slice and the cause is not understood

Handoff

Use diagnose-loop for unexplained failures. Use codebase-cleanup only when behavior-preserving structure or testability cleanup would unblock the check or implementation. Stay in this skill for behavior-changing source edits, use clarify-scope when the behavior or contract is unclear, use workspace-safety for overlapping dirty paths or Git risk, and use verify-before-done for final claims.

Use slice-plan only when the behavior expands into multiple real slices that need a written plan or handoff.

Report

For a small slice:

Behavior:
Check:
RED or baseline:
GREEN:
Broader check or skipped reason:
Risk:

For nontrivial slices, also include test-surface gap and diff-review note.