How do I install the Doc Tdd skill?

Run npx skillmds add vladm3105/doc-tdd in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Doc Tdd skill do?

Create a Test-Driven Development guide (TDD) - Layer 7 of the SDD flow, defining test cases, BDD-to-test mapping, and quality thresholds from SPEC component contracts. Use after SPEC, before IPLAN. Single-document authoring primitive; for end-to-end or batch generation the autopilot (`doc-tdd-autopilot`) drives this skill. It is listed under Web & Frontend on SkillMD.

Is Doc Tdd safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Doc Tdd?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Doc Tdd free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Doc Tdd?

vladm3105 (@vladm3105) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Doc Tdd by vladm3105 — Agent Skill

Name: Doc Tdd
Rating: 4.666666666666667 (3 reviews)
Author: vladm3105

doc-tdd

Purpose

Create a Test-Driven Development guide (TDD) — Layer 7 of the SDD flow. A TDD defines test cases validating the SPEC component contract: maps BDD scenarios to concrete tests (inputs, expected outputs, edge cases), sets per-type quality thresholds, declares Red → Green → Refactor order. Test type (unit / integration / functional / perf / security) is a type attribute on each case — no separate artifacts.

Layer: 7 (after SPEC, before IPLAN). Downstream: IPLAN → Code.

One TDD per SPEC component.

When to Use

Use doc-tdd when:

BRD through SPEC (Layers 1–6) are complete and you are defining tests.
You need concrete test cases, a BDD→test mapping, and quality thresholds before implementation.
Following the test-first (Red → Green → Refactor) workflow.

For end-to-end generation from a SPEC, a prompt, or an IPLAN, use ../doc-tdd-autopilot/SKILL.md. To create the upstream SPEC, use ../doc-spec/SKILL.md.

Prerequisites

Before writing, verify upstream artifacts exist and read the contracts:

List upstream: ls docs/01_BRD/ docs/02_PRD/ docs/03_EARS/ docs/04_BDD/ docs/05_ADR/ docs/06_SPEC/ 2>/dev/null
Template (source of truth): ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/TDD-TEMPLATE.yaml
Layer README: ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/README.md
ID & tag standards: ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
Authoring style: ${CLAUDE_PLUGIN_ROOT}/framework/governance/AUTHORING_STYLE.md

The primary source is SPEC (the component contract); BDD is the source of truth for behavior — TDD maps BDD scenarios to tests, it does not duplicate them. Reference only documents that exist; never invent placeholders like TDD-XXX, SPEC-XXX, or TBD. Do not create missing upstream artifacts.

Layer Guidance

Required structure (7 sections)

The TDD is a single unified template — no test subtypes, no separate test artifacts. Per TDD-TEMPLATE.yaml:

Document Control — status, version, dates, author, component, SPEC ref, IPLAN-Ready score.
Test Pyramid — effort distribution (defaults: unit 70 / integration 20 / e2e 10; targets, not quotas).
BDD Scenario → Test Mapping — each @bdd: scenario maps to test types, files, and functions; declares where tests will live.
Test Case Definitions — concrete cases, each with an element ID and a type attribute.
Test Thresholds — coverage targets and pass/fail criteria per type.
TDD Execution Order — Red → Green → Refactor phases.
Traceability — required upstream tags + downstream IPLAN.

Test types (content categories, not subtypes)

Each Section 4 case carries a type attribute — not a separate ID code or document.

Type	Validates	Primary source
unit	individual functions/methods, data-model constraints	SPEC §3–4
integration	component interactions, state transitions, error handling	SPEC §5
functional	feature behavior against acceptance criteria	EARS/BDD
e2e	full workflows mapped from acceptance scenarios	BDD (Layer 4)
smoke	critical-path sanity (post-build/deploy)	BDD critical scenarios
performance	latency/throughput against `@threshold` targets	EARS quality attributes
security	optional — threat/vulnerability paths	SPEC/ADR (only if mandated)

Unit cases carry target, inputs, expected_output, edge_cases. Integration cases add contract, setup, action, expected_state, error_paths. E2E cases add a bdd_ref, numbered workflow, timeout_seconds, cleanup. Security cases add a threat ref and expected_result.

Test thresholds (Section 5)

Type	Coverage target	Fail action
unit	≥90%	block merge
integration	≥85% (contract validation passes)	block merge
e2e	≥75% of happy paths (≤300s budget)	block deploy to staging
security (optional)	all auth/authz paths; no OWASP Top 10	block deploy

TDD execution order (Section 6)

The order the AI must follow when generating code: 1) Write Tests → 2) Run Tests (Red, confirm failure) → 3) Implement → 4) Verify (Green) → 5) Refactor. Test files are generated before implementation files.

Element IDs and tags

Test-case element IDs: TDD.{doc_id}.{section_id}.{hash} (4-segment) — test cases live in Section 4, so TDD.NN.04.xxxx (e.g. TDD.01.04.a3c1). Emit a stable 4-hex-char identifier per element, distinct within its section (HASH01); extend to 8 on collision. Do not compute SHA-256 in this prompt — the hash form is the canonicalization TARGET produced by a deterministic tool pass, and byte-exact field extraction is defined for BRD §7 only (Phase 2+ for TDD). Authority: framework/governance/ID_NAMING_STANDARDS.md.
TDD is Layer 7, so it carries the required upstream tags (per the necessary-upstream contract): @ears @bdd @adr @spec. EARS/BDD use dot element form; ADR and @spec: SPEC-NN are document-level dash form. Self-tag: @tdd: TDD-NN. Upstream PRD/BRD lineage is reachable transitively via the EARS/BDD @-tag chain — do not emit @brd:/@prd: on TDD elements.
Removed patterns (do not use): TC-XXX, UT-XXX, IT-XXX, ST-XXX, FT-XXX, and the legacy 3-segment TDD.NN.xxxx.

Creation Process

Read upstream — SPEC (component contract) + BDD (behavior scenarios).
Reserve ID — next free TDD-NN (two digits: TDD-01, TDD-99); one TDD per SPEC component, docs/07_TDD/TDD-NN_{component_slug}.yaml. Per-layer independence (CLEANUP-PR-F item 18): pick the next-free number in YOUR layer's index — the upstream's number is NOT your number (doc numbers are per-layer sequential and independent; see framework/governance/ID_NAMING_STANDARDS.md §Cross-layer cardinality).
Document Control first, then complete all 7 sections from the template.
Set the test pyramid; map each BDD scenario to test types/files.
Write test cases — element ID TDD.NN.04.xxxx, type, spec_ref (and bdd_ref for e2e), inputs/outputs, edge cases/error paths.
Set thresholds; confirm Red → Green → Refactor order.
Add required upstream tags (@ears @bdd @adr @spec) + @tdd self-tag + downstream IPLAN.
Update the TDD index docs/07_TDD/TDD-00_index.md in the same change.
Validate (below) and commit the TDD and index together.

Validation

This skill is the validator (no runtime code). Apply against ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/README.md and ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md.

Document Control complete; all 7 sections present and non-empty.
Test pyramid set; BDD→test mapping complete (Section 3).
Each case has a TDD.NN.04.xxxx ID and a valid type (unit/integration/e2e/security); no removed patterns.
Inputs/expected outputs present per case; edge cases / error paths documented; e2e cases carry a bdd_ref.
Thresholds set per type (Section 5); execution order present (Section 6).
Required upstream tags @ears @bdd @adr @spec plus @tdd self-tag (per necessary-upstream contract); parent SPEC exists.
Index updated; no broken links. Diagrams via ../charts-flow/SKILL.md.

Error codes (all severity error): XDOC-006 tag format invalid · XDOC-008 broken internal link · XDOC-009 missing traceability section.

Quality gate (blocking): IPLAN-Ready score ≥ 90/100 before moving on.

Next Skill

../doc-iplan/SKILL.md — the IPLAN references this TDD (@tdd: TDD-NN), inherits the full upstream tag chain, and orchestrates the build, enforcing test files before implementation files.

Adaptation

Read .aidoc/profile.yaml; honor only this skill's knobs (section_toggles, glossary). Ignore unknown keys; absent a profile, use framework defaults. Authority: ${CLAUDE_PLUGIN_ROOT}/framework/governance/ADAPTATION.md.

Related Resources

Template / authoring rules: ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/TDD-TEMPLATE.yaml
Layer README: ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/README.md
Index template: ${CLAUDE_PLUGIN_ROOT}/framework/layers/07_TDD/TDD-00_index.TEMPLATE.md
ID & tag standards: ${CLAUDE_PLUGIN_ROOT}/framework/governance/ID_NAMING_STANDARDS.md
Quality gate: ../doc-tdd-audit/SKILL.md · Fixes: ../doc-tdd-fixer/SKILL.md
Generation pipeline: ../doc-tdd-autopilot/SKILL.md
Upstream: ../doc-spec/SKILL.md · Downstream: ../doc-iplan/SKILL.md

Quick Reference


Purpose	Define test cases from SPEC contracts
Layer	7 (after SPEC, before IPLAN)
Upstream tags	@ears @bdd @adr @spec (per necessary-upstream contract)
Element ID	`TDD.NN.04.xxxx` (test cases live in Section 4)
Test types	unit · integration · e2e · security (a `type` attribute)
Must include	Document Control (first), 7 sections, BDD→test mapping
Next	`doc-iplan`

Doc Tdd

File contents

doc-tdd

Purpose

When to Use

Prerequisites

Layer Guidance

Required structure (7 sections)

Test types (content categories, not subtypes)

Test thresholds (Section 5)

TDD execution order (Section 6)

Element IDs and tags

Creation Process

Validation

Next Skill

Adaptation

Related Resources

Quick Reference

Frequently asked questions

Doc Tdd

File contents

doc-tdd

Purpose

When to Use

Prerequisites

Layer Guidance

Required structure (7 sections)

Test types (content categories, not subtypes)

Test thresholds (Section 5)

TDD execution order (Section 6)

Element IDs and tags

Creation Process

Validation

Next Skill

Adaptation

Related Resources

Quick Reference

Related skills

Frequently asked questions

How do I install the Doc Tdd skill?

What does the Doc Tdd skill do?

Is Doc Tdd safe to use?

Which AI agents work with Doc Tdd?

Is Doc Tdd free to use?

Who published Doc Tdd?