Tdd discipline
Skill IrfanSadiqRahat/constellation/methodology/tdd-discipline
200 role-specific AI agents across 20 teams with typed artifact pipelines, 14 methodology skills, and 15 pre-baked team formations. The virtual engineering org for Claude Code, Cursor, Codex CLI.
npx -y skills add IrfanSadiqRahat/constellation --skill tdd-disciplineAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Role-aware TDD. NO production code without a failing test first. Tests live alongside the role's typed artifact.
SKILL.md
2.4 KB, as published. Nobody here has run it
tdd-discipline
Iron law (non-negotiable)
NO production code without a failing test that asserts the desired behaviour, observed RED, then implemented to GREEN.
This is not "tests recommended". It is a refusal. If the agent writes code without writing a failing test first, the agent has violated the contract and should be told to stop.
Cycle
- RED — write a test. Run it. Confirm it fails for the right reason (
message contains "Expected … but got …"). - GREEN — write the simplest code that makes the test pass. No flourishes.
- REFACTOR — clean up with the test still passing. If the test breaks during refactor, the test was coupled too tight.
Forbidden: writing the test after the code "to capture intent". That is regression-testing, not TDD.
Role-aware adaptation
The shape of "test" depends on what the role produces:
| role | "test" shape |
|---|---|
react-specialist | RTL / Vitest unit + integration |
api-designer | contract test (Pact / OpenAPI schema validation) |
backend-architect | architectural fitness function (Dependabot rules, ArchUnit, etc.) |
prompt-engineer | eval row in EvalSuite (passes/fails on judge metric) |
data-architect | data quality assertion (Great Expectations, dbt test) |
security-architect | abuse-case test (input that should be blocked) |
prd-writer | acceptance criterion in REQ schema — verifiable as boolean |
incident-commander | postmortem action-item has a verification step |
migration-planner | dual-write reconciliation count = 0 |
The role's output artifact has a corresponding test family. No exceptions.
Coverage smell-check
- 100% line coverage with low mutation kill rate = fake coverage
- Tests that mock everything = tests of mocks
- Tests that re-implement the production code = tests of nothing
- Snapshot tests as the primary mechanism = test of opinion drift
Why this skill is opinionated
- Role-aware test shape — different artifacts need different tests
- Iron law enforced per role, not per language
- Mutation testing as the coverage truth-meter
- Eval rows count as tests for AI-product roles