policy-core

Enforces behavior-driven test quality rules and completion gates for test-driven development.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Test suites often verify wiring instead of behavior, pass against broken implementations, or gate on coverage numbers that hide zero-test runs. This Skill defines a global TDD governance policy that makes tests verify observable behavior and makes completion gates meaningful. ## Core Features & Use Cases - Assertion hierarchy (Level 1-7): Ranks assertions from output verification down to mock-was-called, and rejects tests that only assert mock call arguments. - Specification strength (S1-S6): Requires property, invariant, or metamorphic tests for units that have a law such as conservation, round-trip, or idempotence. - Completion gates: Fails lanes that discover zero tests, rejects 0/0 coverage passes, audits mocked boundaries against integration tests, and checks red receipts so specifications do not move during implementation. - Use Case: When reviewing a pull request, apply the policy to flag a wiring-only test that asserts mock call args for a container creation, and require an integration test that inspects the actual created resource instead. ## Quick Start Ask the agent to review the current test suite against the TDD policy and report any wiring-only tests, missing property tests, or unmet completion gates.

Frequently Asked Questions about policy-core

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

FAQPage Schema
How do I write behavior-driven tests instead of mock-based tests?

Assert observable results such as return values, state changes, or side effects rather than mock call arguments. Prefer real objects like in-memory databases or app.inject() over mocks, and reserve mocks for true boundaries like network I/O or child processes.

What is the difference between assertion level and specification strength?

Assertion level (1-7) measures how implementation-independent a check is, while specification strength (S1-S6) measures how much of the input space a test claims. A test can be Level 1 yet only S1, passing against an implementation that returns a constant.

When should I use property-based testing instead of example tests?

Use property-based tests (S4-S6) when a unit has a law such as conservation, round-trip, idempotence, ordering, or monotonicity. Units without a law should record that fact explicitly rather than forcing contrived generators.

Why does a coverage report showing 100% still fail the gate?

A report measuring zero lines scores 100% under the 0/0 convention, so a silent no-op run would otherwise pass. The gate fails any coverage report measuring zero lines and warns on metrics the tool does not measure.

Why should I avoid v8 ignore next comments for coverage?

The line-count form silently miscounts on nullish coalescing, ternaries, catch bodies, and short-circuit operators, leaving code uncovered or skipping wrong lines. Use the explicit start/stop range comments instead.