init

Detects test lanes, verifies them by dry-run probe, and writes the TDD Guardian lane configuration.

10|7|Updated Feb 23, 2026
One-click install
npx skills add https://github.com/xiaolai/tdd-guardian-for-claude --skill init-xiaolai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: init
Source: https://github.com/xiaolai/tdd-guardian-for-claude/tree/main/skills/tdd-guardian/init
Command: npx skills add https://github.com/xiaolai/tdd-guardian-for-claude --skill init-xiaolai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Setting up test-driven development enforcement requires knowing which test lanes a repository actually has and which commands truly run them. This Skill automates that discovery and writes a verified .claude/tdd-guardian/config.json instead of a guessed template. ## Core Features & Use Cases - Evidence-based lane detection: Reads CI config first, then manifests, test topology, and dry-run probes before proposing any lane. - Probe-verified configuration: Every proposed lane command is dry-run tested; a lane that discovers zero tests is reported, never silently configured. - Coverage and trigger assignment: Assigns per-lane triggers (taskCompleted, commit, push, manual), coverage participation, thresholds, and staleness rules, including a no-decrease mode for repos with pre-existing gaps. - Use Case: Onboarding a polyglot repository with unit and e2e suites — the Skill detects both lanes, probes their commands, sets the e2e lane to gate only on push, and writes the config with correct coverage report paths. ## Quick Start Ask the assistant to initialize TDD Guardian for this repository by detecting the test lanes and writing the verified lane configuration.

Frequently Asked Questions about init

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I set up TDD enforcement in an existing repository?

Run the init flow, which detects your test lanes from CI config and manifests, dry-run probes each proposed command, and writes a verified config.json. Lanes that discover zero tests are reported rather than configured.

How are test lanes detected and verified before configuration?

Detection follows an evidence order: CI config first, then manifests, test topology, and finally a dry-run probe command. A lane that fails its probe is never written to config as though it were working.

Can I use coverage gates on a repo with pre-existing coverage gaps?

Yes, set coverageMode to no-decrease, which blocks only when coverage drops below a per-branch baseline. An absolute 100% threshold on day one typically just gets the tooling disabled.

Does the config support old v1 single-command setups?

Yes, a v1 config with testCommand and coverageCommand keeps working; hooks migrate it in memory to one unit lane. The upgrade to the lanes schema is offered explicitly and never rewrites the file without confirmation.

Why should some coverage thresholds be set to zero?

Some coverage formats do not track every dimension — for example go-cover lacks functions and branches, and coverage-py lacks functions. Setting untracked dimensions to 0 avoids a permanent warning.