Skill 1: SDD-Extract-Specs
What SDD-Extract-Specs Does
Sdd-extract-specs reverse-engineers the application’s business behavior into OpenSpec specifications, one artifact set per vFunction domain. The skill has three stages that all read from and write to the same specs root. It runs one stage per request: it stops after each stage, reports, and asks before continuing.
| Stage | Produces |
|---|---|
| 1. Extract the specifications | One OpenSpec artifact set per domain |
| 2. Consolidate the ubiquitous language | One cross-domain glossary at the specs root |
| 3. Document the technology stack | technology-decisions.md and technology-decisions-modern.md |
Stage 1 runs in one of three modes:
- All domains. One clean-context sub-agent per domain, in parallel. This includes the domain named Application, which is the application-level domain and is extracted like any other
- One domain. A single named domain. Safe to run against a tree that already holds others
- Codebase only. No runtime data and no domains. The skill discovers endpoints, crawls from them, and files flows into code-derived areas. Use this when the application has no vFunction analysis
Example Prompts
Extract the specs for this application into ../specs/
Reverse-engineer the spec for the Billing domain into ../specs/
Extract specs from the codebase alone into ../specs/ (there's no vFunction analysis for this app)
Consolidate the ubiquitous language in ../specs/
Extract and modernize the tech stack for ../specs/
What You Get
../specs/
ubiquitous-language.md # after stage 2: the aggregated, cross-domain glossary
technology-decisions.md # after stage 3: the current stack
technology-decisions-modern.md # after stage 3: the recommended target stack
<domain-slug>/
overview.md # domain overview
ubiquitous-language.md # this domain's glossary
domain-data-model.md
external-contracts.md # handoffs to and from other domains
traceability.md # where each claim came from
open-questions.md
specs/<capability-slug>/spec.md # one per business flow
specs/quality-attributes/spec.md
features/<capability-slug>.feature
features/<capability-slug>.evidence.md
changes/establish-baseline/ # the baseline scaffold, always emitted
changes/proposed/ # suggestions this analysis seeded, if any
Model Selection
Domain spec extraction needs a large amount of code and information in a single context window. Use a model with a large context window (around 1M tokens), regardless of how strong its reasoning is. This matters even though each sub-agent is told where its domain is bounded. In customer deployments, smaller-context models have produced unreliable results on whole-codebase extraction.
Before Moving On
- Stage 2 needs at least two domains in the tree, and works best when applied to all domains together. It consolidates only what is present, so check which domains it reports covering
- Stage 2 does not apply after a codebase-only extraction. That mode writes its own consolidated glossary
- Read the open questions the run reports. Every later step inherits them
Next SDD Pipeline Skill
The next SDD Pipeline Skill is: