doc-tdd
doc-tdd generates Layer 7 TDD artifacts that translate component contracts into concrete test cases with quality thresholds. It maps BDD scenarios to unit, integration, functional, and end-to-end tests, establishes coverage targets per type, and sequences the Red-Green-Refactor workflow before implementation begins.
doc-tdd creates a Test-Driven Development guide that maps BDD scenarios to test cases and sets quality thresholds for SPEC components.
AI-generated summary based on this skill's SKILL.md
Decision gist · record as of 2026-07-27
doc-tdd creates a Test-Driven Development guide that maps BDD scenarios to test cases and sets quality thresholds for SPEC components. doc-tdd generates Layer 7 TDD artifacts that translate component contracts into concrete test cases with quality thresholds. It maps BDD scenarios to unit, integration, functional, and end-to-end tests, establishes coverage targets per type, and sequences the Red-Green-Refactor workflow before implementation begins.
Use it when
- doc-tdd maps BDD scenarios directly to concrete test cases by extracting inputs, outputs, and edge cases from each scenario.
- doc-tdd establishes a complete test pyramid structure with coverage targets and pass/fail criteria for each layer: unit tests (fastest.
Verify before relying
Read SKILL.md below before installing (1 file). Open directory: indexed for reading, not audited.
Install
vladm3105/aidoc-flow-framework/doc-tdd · repository language: Python
Open directory. Skills are indexed for reading, not audited. Review a skill's body before installing it.
Frequently asked questions
AI-generated answers based on this skill's SKILL.md and metadata
How do I create a test-driven development guide from a SPEC component contract?
doc-tdd generates Layer 7 TDD artifacts by translating your SPEC component contract into concrete test cases with defined quality thresholds. The skill maps each contract requirement to specific test scenarios, establishes coverage targets by test type (unit, integration, functional, end-to-end), and sequences the Red-Green-Refactor workflow so you define tests before implementation begins.
How to write TDD test cases from BDD scenarios using doc-tdd?
doc-tdd maps BDD scenarios directly to concrete test cases by extracting inputs, outputs, and edge cases from each scenario. It assigns test cases to appropriate pyramid layers, defines pass/fail criteria for each, and links them back to upstream BDD artifacts for full traceability. This ensures your test-first workflow stays aligned with behavior specifications.
What does doc-tdd include for test pyramid and quality thresholds setup?
doc-tdd establishes a complete test pyramid structure with coverage targets and pass/fail criteria for each layer: unit tests (fastest, highest volume), integration tests (component interaction), functional tests (feature validation), and end-to-end tests (full workflow). It defines quality gates and threshold scores so you know exactly when tests pass and what coverage each type must achieve.
How does doc-tdd validate test traceability before implementation?
doc-tdd generates TDD documentation following Red-Green-Refactor execution order and validates that every test case links back to its upstream SPEC component contract or BDD scenario. It checks artifact element IDs, tagging standards, and traceability chains so you can confirm all requirements are covered before you write a single line of code.
What test types does doc-tdd help define for component testing?
doc-tdd defines unit, integration, functional, and end-to-end test cases tailored to your component contract. It also supports security and performance test types where applicable, assigns each to the correct pyramid layer, and establishes specific pass/fail criteria and coverage targets so your quality gates are measurable and IPLAN-ready.
Can doc-tdd map BDD scenarios to concrete test cases with edge cases?
Yes. doc-tdd extracts inputs, outputs, and edge cases from each BDD scenario and maps them to concrete test cases. It structures test cases with element IDs and tagging standards, defines expected results and failure modes, and links everything back to the originating scenario so your test suite remains fully traceable and comprehensive.
SKILL.md
Rendered from the published skill. Quoted content, verbatim.
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).
(truncated - see the full file via the links below)
File tree — 1 file
platforms/claude-code-plugin/skills/doc-tdd/SKILL.md
Let your AI agent find skills like this
Example. Real query, live index.
You found this page by searching. An agent finds it by wishing: SkillFed indexes 56,283 agent skills by what they can do, searchable in plain language.
wish › “Create a test-driven development guide defining test cases and quality thresholds from a SPEC component contract”
Give your agent the search over MCP, or paste the wish link into any chat. No install? Search from any chat →
Related skills
verify is a quality assurance auditor that gates feature work at three checkpoints: proposal readiness, dev doc completeness, and implementation verification. It searches for placeholder content, traceability gaps, missing acceptance criteria, and specification drift, then either passes the gate or blocks with exact findings. Designed to be adversarial—assuming work is incomplete until proven otherwise.
doc-adr captures a single architectural decision using the Context-Decision-Consequences pattern, positioned as Layer 5 in the specification-driven development flow. It records the rationale, chosen approach, evaluated alternatives, and accepted trade-offs for decisions that bridge container and component design.
doc-bdd translates EARS requirements into Layer 4 acceptance scenarios using structured YAML (not Gherkin), each with Given-When-Then phases, element-level trace links to upstream EARS, and forward mapping to SPEC sections. Use this after EARS is complete and before ADR/SPEC authoring; for batch generation across multiple documents, the autopilot skill handles orchestration.
doc-prd generates a Product Requirements Document as Layer 2 of the SDD workflow, converting business requirements into product capabilities, user personas, and measurable success criteria. It structures features and acceptance criteria at the container level, sitting between upstream BRD and downstream EARS artifacts.
project-adopt brings an established codebase into the Specification-Driven Development workflow by detecting existing code and documentation, inferring the domain, and scaffolding the 8-layer artifact structure. It reverse-engineers baseline artifacts from your running system at draft status, seeding the SDD backbone in one setup pass. Hand off to doc-flow and per-layer audits to close gaps and promote drafts to ready.
Quality-advisor gives live feedback while you create or review SDD documents, catching completion gaps, documentation anti-patterns, tag compliance, and naming issues before submission. It scores sections, detects common problems like missing traceability or broken links, validates cumulative tagging across layers, and returns actionable recommendations to fix issues.
More skills doc-adr-autopilot (MIT) · Test Driven Development (unlicensed) · tdd (MIT)