Skip to content
Development
Skill

/tdd

Red-green-refactor Implement method inside a caller-owned lifecycle for explicit TDD or test-first requests. Requires red evidence, minimal green implementation, and rerun validation.

BOOST
From plugin
khanelinix
34750 skills10 agents6 commands
Install
$ npx -y skills add khaneliman/khanelinix --skill tdd --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/tdd

Context preview

The summary Claude sees to decide when to auto-load this skill.

Red-green-refactor Implement method inside a caller-owned lifecycle for explicit TDD or test-first requests. Requires red evidence, minimal green implementation, and rerun validation.

SKILL.md

tdd.SKILL.md
name: tdd
description: "Red-green-refactor Implement method inside a caller-owned lifecycle for explicit TDD or test-first requests. Requires red evidence, minimal green implementation, and rerun validation."
license: Complete terms in LICENSES/

Test-Driven Development

Use this method when implementing features or bug fixes test-first. Test-driven development executes a red-green-refactor loop across observable behavior boundaries.

This skill is a narrow implementation method. It does not own lifecycle planning, repository design review, or external handoff.

Execution Rules

Execute vertical slices. Complete one seam, one failing test, and one minimal implementation per cycle. Do not write tests in bulk before implementation.

1. **Identify the behavior seam.** Select the public interface that exposes the behavior. Avoid testing private functions or internal state. See [references/test-quality.md](references/test-quality.md) for test quality rules. 2. **Write the failing test.** Write one focused test for the intended behavior. Avoid tautological assertions and implementation coupling. Use mocks only for external system boundaries per [references/mocking.md](references/mocking.md). 3. **Execute the test to verify failure.** Run the test suite on the new test. Confirm the test fails for the expected reason. Capture the failure evidence. 4. **Implement the minimal fix.** Write only enough production code to pass the test. Do not add speculative capabilities or unneeded abstractions. 5. **Rerun the test.** Execute the test to verify green status. Run adjacent tests to verify no regressions. 6. **Apply bounded refactoring.** Clean up duplication and structure while keeping tests green. Re-run tests after each small cleanup.

When Tests Are Impractical

Skip test creation when tests require broad harness setup, brittle mocks, slow end-to-end infrastructure, or production-only state.

When skipping a test:

  • State why a unit or integration test is impractical.
  • Run the closest executable check, such as a script, reproduction command, or

log verification.

  • Capture the output before and after the change.

Output Evidence

Report the following evidence to the caller:

  • Behavior seam and test location.
  • Red phase failure output with the failure reason.
  • Green phase success output and execution duration.
  • Adjacent test verification results.
  • Bounded refactoring changes applied.
Read more
Ships withkhanelinix

Run packages directly with: Or install from the packages output. For example:

Get the whole plugin

Other skills on khanelinix.