TDD

Own one small behavioral increment at a time: meaningful red, minimal green implementation, then behavior-preserving refactoring while green. This method supports standalone requests and bounded handoffs. It returns local implementation/check evidence; it does not select the next method, provide independent review, or accept a whole delivery.

Loading this skill grants no effects. Inspection/plan-only requests stop at a proposed increment and checks. Writes and test execution need task authority; delegation, disclosure, installation, service operations, merge and release remain separately authorized.

For package changes or validation, read validation. The procedure below is the sole owner of the TDD loop.

1. Establish the bounded increment

Inspect the target's instructions, agreement and relevant code, callers, checks, domain vocabulary and ADRs. Consume current analysis or reproduction evidence directly; reassess only facts dependent on changed agreement, code, callers, tests or environment. Record source revisions/content identities, including relevant dirty files, rather than relying on HEAD alone.

Establish the intended observable behavior, acceptance references, exclusions, owned files/interfaces, protected work, approved effects, dependencies and expected return. A direct request supplies these through context; no handoff form is required. Resolve consequential behavior/authority gaps with their owner; the technical lead chooses routine seams and test strategy without a maintainer questionnaire. Standalone execution acts as its own bounded lead.

Discover companions through the runtime catalog or an explicit approved location, never an assumed sibling path. Read each complete entry and relevant references; record the resolved source/revision or digest and inspect semantic capabilities. Ambiguity or incompatibility blocks only the dependent route; installation is not a fallback.

• Before Git implementation writes, use compatible implementation-preflight, or inspect a current supplied result for the same scope/state: protected work, branch/base and PR target. Outside Git, retain a before/after manifest.
• Required meaning or qualifying decision-record changes use the target's discovered domain-modeling owner. Reading existing definitions requires no invocation.
• Delegated work or correction of recorded acceptance findings requires the discovered work-on execution/repair contract as a read-only library, without invoking delivery. Preserve its root ledger, ownership, limits and finding lineage; workers request additional work from the root rather than spawning workers. An unavailable compatible contract blocks that route, not an ordinary direct development loop. Planned red–green increments are development, not failed-acceptance repair episodes.