TDD Guard
Automated Test-Driven Development enforcement for Claude Code: blocks skipped tests and over-implementation so your coding agent stays test-first.
The skill uses disable-model-invocation and restricts allowed-tools to Read/Glob/Grep (least privilege); guidelines explicitly forbid modifying test frameworks or other dependencies, instruct it to inform the user on ambiguity, and defer to the user when configuration cannot be migrated without guessing; data flow (reporters writing .claude/tdd-guard/data/test.) is disclosed. Deductions: installing third-party reporter packages adds registry supply-chain reliance, and the skill offers no rollback/uninstall path or explicit pre-modification confirmation step.
SKILL.md is internally consistent across nine frameworks with concrete config snippets and clear abnormal-path guidance (ask when multiple frameworks, stop and report on failure). Deductions: static review only — framework detection and migration key paths are inferred, not reproduced; repo CI and reporter tests exist but do not cover this setup skill's own key paths, so the static cap of 10 applies.
Audience and scenarios are clear (Claude Code users configuring TDD Guard), the supported-framework table is explicit, scope and non-fit boundaries are written into Guidelines, and disable-model-invocation prevents false triggering. Deductions: degraded behavior for unsupported frameworks is undeclared; core installation depends entirely on overseas registries (npm, PyPI, Packagist, crates.io, RubyGems, go install) with no mirror/offline guidance, which may be unreachable from mainland China.
MIT license, attributed author (Nizar Selander), semver version 1.7.0, CI and security workflows, contributor list; README transparently discloses the project has evolved into Probity while remaining maintained, giving a clear update path. Deductions: no skill-level changelog/version mapping, hidden assumptions about the Claude Code plugin mechanism, and no FAQ or troubleshooting section.
The goal is well-defined (detect framework, install matching reporter, configure to spec); snippets are directly adaptable per framework and clearly beat manual configuration, with tdd-guard on/off control. Deductions: static review cannot verify actual outputs; end-to-end usability evidence is thin since validation only works after reporter wiring is confirmed.
Auditable primary material exists: CI with a reporter-test matrix, CodeQL and npm-audit security scanning, and pytest reporter test helpers corroborating the test. data structure. Deductions: this evidence covers the repository, not the setup skill's key paths; no independent third-party reproduction, and confidence is low under static review, hence 4.
- The skill instructs installation of third-party reporter packages (npm/PyPI/Packagist/crates.io/RubyGems), introducing supply-chain reliance; verify package provenance and versions after installation.
- The install flow depends entirely on overseas registries and may be unreachable from mainland-China networks; no mirror or offline guidance is documented.
- The upstream README states the project has evolved into Probity and TDD Guard is maintained only for existing users; long-term maintenance is uncertain.
- No rollback/uninstall instructions are provided; back up test configuration files before allowing modifications.
- This is a static source review without execution; framework detection and configuration migration behavior should be verified by the user.
What does this skill do, and when should you use it?
TDD Guard is a plugin that enforces Test-Driven Development in Claude Code. When the agent tries to write implementation without failing tests or over-implements beyond current test requirements, it blocks the action and explains what should happen instead. The project ships reporters for nine test frameworks (Vitest, Jest, Storybook, pytest, PHPUnit, Go, Rust, RSpec, Minitest), all writing results to .claude/tdd-guard/data/test. at the project root. Note that the README states the project has evolved into Probity, which supports Claude Code, Codex, and GitHub Copilot CLI with no test reporters to set up; new projects are directed there, while TDD Guard remains maintained for existing users.
The setup skill detects the project's test framework, installs or updates the matching TDD Guard reporter from npm, PyPI, Packagist, RubyGems, crates.io, or go install, and writes or migrates the reporter configuration to the current specification (e.g., the Vitest/Jest reporters array, pytest's tdd_guard_project_root, or a piped go test - command). All reporters write test results to .claude/tdd-guard/data/test.; TDD Guard then uses Claude Code hooks to validate agent actions against TDD principles and blocks violations with an explanation. Validation rules are customizable via .claude/tdd-guard/data/instructions.md, and enforcement can be toggled mid-session with tdd-guard off / tdd-guard on.
- Teams doing daily development in Claude Code who want test-first TDD enforced automatically, preventing the agent from writing implementation without tests
- Polyglot projects running both Vitest and pytest that need reporters installed and configured for multiple frameworks in one pass
- Projects with an older TDD Guard reporter whose configuration has drifted and needs migration to the current specification
- Developers who want to tailor validation rules, such as loosening or tightening minimal-implementation checks, by editing instructions.md
- Review or pairing sessions where enforcement must be paused temporarily via tdd-guard off / on
What are this skill's strengths and limitations?
- Covers nine test frameworks across five language ecosystems (JS/TS, Python, PHP, Go, Rust, Ruby)
- The setup skill has a clearly scoped mandate: install and configure only the reporter, never modify test frameworks or other dependencies
- Customizable rules via instructions.md, plus mid-session toggling, lint integration, and ignore patterns
- MIT-licensed; README credits per-language contributors and shows CI and security-scanning workflow badges
- The README explicitly says the project has evolved into Probity and directs new projects there, so long-term investment should be weighed
- Per-project test reporter configuration adds setup cost compared to its successor Probity, which claims to need no reporters
- Reporters require an absolute-path projectRoot; when configuration cannot be migrated without guessing, the skill only informs the user
- Requires Node.js 22+, and validation depends on the chosen model's judgment — no public data on false positives/negatives on atypical workflows
- The setup skill is limited to Read, Glob, and Grep tools, so it cannot troubleshoot issues beyond its scope (by design; the user must act)
How do you install this skill?
Open Claude Code in your project and run: 1) /plugin marketplace add nizos/tdd-guard; 2) /plugin install tdd-guard@tdd-guard; 3) /tdd-guard:setup. Step three configures the test reporter for your framework. You may need to restart your terminal session or IDE extension for the setup skill to appear. Requirements: Node.js 22+ and a supported test framework. Manual installation and configuration are documented in docs/installation.md (contents not included here).
How do you use this skill?
After installing and running /tdd-guard:setup, TDD Guard validates each code change automatically through Claude Code hooks — no manual triggering. Common operations: toggle enforcement with tdd-guard off / tdd-guard on mid-session; customize validation rules by editing .claude/tdd-guard/data/instructions.md; further options (lint integration, ignore patterns, validation model choice) are documented in the repository's docs/ directory.
How does this skill compare with similar options?
The README names its successor, Probity (github.com/nizos/probity): the same TDD enforcement, extended to Claude Code, Codex, and GitHub Copilot CLI, with more reliable validation and no test reporters to set up. New projects should start there; existing projects relying on TDD Guard can continue using it.