Angelo Resplandes

You can run a full spec-driven cycle: capture a request, classify cycle size and resolve capability constraints, produce an approved plan with Gherkin scenarios and tasks, implement against that plan, verify in a real browser with runtime evidence, validate pass/fail, and promote the delta into the canonical spec.

Software developers building features, refactors, or non-trivial bugfixes that touch more than a couple of files. It suits engineers who want explicit plans, human approval gates, and runtime evidence before code changes are merged, including work spanning multiple modules, repos, or teams.

The sdd orchestrator inspects the filesystem for cycle artifacts like request.md, plan.md, tasks.md, and verification.md to detect the current phase, then routes to the matching phase skill. Naming a phase directly, such as 'refina' or 'valida', invokes that skill without the orchestrator.

sdd-verify requires an existing browser automation stack such as Playwright, Cypress, a browser MCP, or a scripted manual pass, plus a runnable dev server and test suite. It never installs a browser stack itself and never edits code to make a check pass.

sdd-refine never writes into spec/ or starts implementing; sdd-implement refuses draft plans and never checks off the final promote task; sdd-validate sends failures back to implementation, never forward; sdd-promote, the only phase allowed to write spec/, refuses to run unless validation passed.