RIPDPI: Skill for Claude Code

Test-Driven Development

Full test stack documentation: docs/testing.md. Do not duplicate it here -- read it when you need runner details, CI lanes, or fixture locations. The test rule and the verification policy in AGENTS.md take precedence over this skill.

When to use the cycle

Use red-green-refactor when the user asks for test-first work, or when a defect or new behavior is not caught by an existing test. Search the owning module's tests first: if an existing test covers the behavior, extend it or rely on it instead of adding one. Refactors, renames, and wiring changes need no new test; the existing tests and the module gate prove them.

Workflow

1. RED -- Write one test for one behavior and run only that test. Confirm it fails for the expected reason. If it passes, the behavior is already covered or the test is wrong.
2. GREEN -- Write the minimum implementation that makes it pass. Run the same test again.
3. REFACTOR -- Clean up the test and the implementation, then run the owning module's tests once.

Run the gate that AGENTS.md assigns to the change once, after the last cycle of a batch, not after every cycle.

Running Tests

Kotlin/JVM (fast iteration)

# Single test method
./gradlew :core:engine:testDebugUnitTest --tests "ClassName.method name"

# Single test class
./gradlew :core:engine:testDebugUnitTest --tests "ClassName"

# Single module
./gradlew :core:engine:testDebugUnitTest

Replace :core:engine with the target module (:core:service, :core:data, :core:diagnostics). :app tasks are flavor-qualified (:app:testGithubFullDebugUnitTest).

Rust

# Single test
cargo nextest run --locked -p crate_name test_name

# Single crate
cargo nextest run --locked -p crate_name

Golden contracts

Golden tests are read-only by default. Blessing needs explicit user approval for the affected fixture family; follow golden-bless-discipline.md and the golden-test-management skill.

Test Double Conventions