component-design-with-tdadlisted

# Component design with TDAD When designing a new plugin component — a skill, an agent, a command, or a backing script — the four-layer TDAD architecture has implications for the component's *shape* that are easy to miss if the design is done before the testing discipline is considered. This skill names the questions to ask at design time so the component ships test-friendly rather than acquiring (or never acquiring) its scenario afterwards. The skill is loadable by: - The `spec-writer` agent when authoring a spec that adds a new plugin component - The `tdd-agent` when operating in its agent-artefact branch (a scenario file is the RED-phase deliverable) - Human brainstorming directly, before any agent dispatch It is **not a gate**. The forcing functions live in HARNESS.md (the deterministic CI workflows shipped in v0.36.0). This skill packages the design intelligence those gates assume. --- ## Before reading this skill The skill assumes familiarity with: - The four-layer TDAD architecture — see [the TDAD docs page](../../../docs/tdad/index.md) and [`tdad_tests/README.md`](../../../tdad_tests/README.md) for the full architecture and cost-cadence trade-offs - The plugin's component conventions — see HARNESS.md Context (Naming and File structure) and CLAUDE.md - The orchestrator pipeline — see [`agents/orchestrator.agent.md`](../../agents/orchestrator.agent.md) for the spec-first ordering and the agent-artefact-scope detection step (1c) ## When to invo