Sdd workflow

Skill theinterneti/TTA.dev/.claude/skills/sdd-workflow

Use this skill when the user asks to build a new feature or write implementation code. Enforces the Spec-Driven Development (SDD) 4-phase workflow before any code is written.From its SKILL.md

Install

npx -y skills add theinterneti/TTA.dev --skill sdd-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 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.

SKILL.md

2.0 KB, 420 tokens by cl100k_base, as published. Nobody here has run it

Spec-Driven Development Workflow (TTA.dev)

No implementation code may be written before completing the SDD phases.

The 4 Phases

Execute these phases sequentially. No phase may be skipped.

/specify — Functional Specification (The "What")
- User journeys, edge cases, success criteria, out-of-scope
- Output: Markdown document for user review and approval
/plan — Technical Plan (The "How")
- Which packages are affected (tta-dev-primitives, tta-observability-integration, etc.)
- New modules, classes, functions to create
- How the feature composes with existing primitives (>>, |)
- External dependencies with justification
- Observability strategy (traces, metrics, logs)
/tasks — Task Breakdown
- Isolated, testable work units
- Each task includes acceptance test description
- Numbered by dependency (topological sort)
- Format: Markdown checklist
/implement — Test-Driven Implementation
- Red: Write failing test encoding acceptance criteria
- Green: Minimal implementation to pass the test
- Refactor: Clean up while tests stay green
- Run quality gate before marking task complete

Exceptions

/spike: User explicitly requests prototype code. Spike code must never be merged without going through the full SDD workflow afterward.

Enforcement

If the user asks for code without a spec, initiate /specify first and explain the SDD process.
Reference this constitution by section (e.g., "Per §2 Phase 1, I need to generate a spec first.").

Deep Reference

For the complete SDD Constitution with all tables and detailed guidance, see docs/agent-guides/sdd-constitution.md.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 1 of the 12 instructions most automation workflows skills give in 420 tokens

Counted across 745 of the 1,008 authors here whose files we hold, read 2026-08-07

Write conventional commit messagesin 36 of 745, across 35 files
Delete branches after mergein 30 of 745, across 21 files
Make atomic commitsin 25 of 745, across 15 files
Write minimal code to pass testshere, and in 22 of 745, across 10 files
Re-snapshot after navigation or DOM changesin 21 of 745, across 13 files
Use try-catch for error handlingin 20 of 745, across 8 files
Run tests before committingin 20 of 745, across 12 files
Write tests before implementationin 20 of 745, across 8 files
Configure branch protection rulesin 19 of 745, across 5 files
Explain the why in commit messagesin 19 of 745, across 9 files
Refactor code while tests remain greenin 19 of 745, across 6 files
Interact with elements using refsin 19 of 745, across 11 files

Said here and by no other author read

Complete SDD phases before writing implementation code
Initiate the specification phase first if code is requested
Explain the SDD process when initiating phases
Output a Markdown specification document for user review
Number tasks by dependency
Format the task breakdown as a Markdown checklist

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.