SpecDDTeams and process
Team and process guides for adopting SpecDD across engineering work: explain the practice, roll it out gradually, use it with tickets and agile teams, handle handoffs, assign ownership, and keep spec review lightweight.
- How to explain SpecDD to your team
Explain SpecDD as local contracts in Git that make intent, ownership, constraints, tasks, and done criteria visible during implementation and review.
Read guide - How to roll out SpecDD across an engineering team
Adopt SpecDD across a team without slowing delivery: start small, use one active area, keep conventions in bootstrap.project.md, review specs, and expand around real work.
Read guide - How to use SpecDD for onboarding
Onboard developers and agents with SpecDD by starting from the root spec, reading the local spec for one first change, and reviewing implementation against clear local contracts.
Read guide - How to run a spec-first development process
Use SpecDD as a repeatable team development loop: specify, review, implement, verify, update tasks, and review the diff against the local contract.
Read guide - How to assign ownership for specs
Use SpecDD ownership safely: .sdd Owns describes what the spec governs, while human review ownership belongs in team process, CODEOWNERS, or project docs.
Read guide - How to use SpecDD in agile teams
Fit SpecDD into agile work by using tickets for planning and prioritization, specs for durable local contracts, and reviews to keep code, tests, and specs aligned.
Read guide - How to decide what belongs in a ticket vs a spec
Use tickets for coordination and SpecDD specs for durable implementation contracts so requirements do not disappear when tickets close.
Read guide - How to keep specs and tickets aligned
Use tickets for coordination and specs for contracts, then keep them aligned through refinement, implementation, review, and ticket closure.
Read guide - How to create team conventions for .sdd files
Standardize .sdd conventions for a team without hiding them in root specs: put shared naming, placement, suffix, path style, section-use, task-status, and spec review rules in bootstrap.project.md.
Read guide - How to handle handoffs between teams with specs
Use SpecDD handoffs to transfer durable implementation context: local contracts, ownership, Must and Must not rules, tasks, decisions, checks, and read-only references.
Read guide - How to standardize SpecDD across multiple repos
Use a shared SpecDD baseline across repos while keeping each repo's bootstrap.project.md responsible for its own commands, naming, checks, and local conventions.
Read guide - How to keep specs reviewed but lightweight
Review specs like code, but keep the review focused: authority, behavior, boundaries, tasks, done criteria, and the checks needed for the change.
Read guide - How to use SpecDD in RFC or design-review workflows
Connect RFCs and design reviews to SpecDD: discuss alternatives in the RFC, then turn accepted decisions into reviewed local specs before implementation.
Read guide
More How-To categories
- Getting started
Start with spec-driven development, write your first local SpecDD spec, and run a small end-to-end change with human-and-agent-friendly guardrails.
11 guides - Install and setup
Install the SpecDD CLI, prepare Node.js when needed, initialize or update projects, and verify the framework files are wired correctly.
9 guides - Set up your agent
Set up Claude Code, Codex, GitHub Copilot, Cursor, Windsurf, Gemini CLI, OpenCode, Junie, Cline, Antigravity, and universal Agent Skills for SpecDD.
15 guides - Editor setup
Install SpecDD editor support, validate .sdd files, resolve path warnings, and use completions and section hints while writing specs.
4 guides - Agent workflows
Use SpecDD with agents by keeping prompts short, plans spec-bound, file changes authorized, context durable, and reviews tied to local .sdd contracts.
15 guides - Write specs by level
Write SpecDD specs at the right level: root specs for project context, module specs for area boundaries, and focused specs for local behavior and contracts.
14 guides - Use spec sections
Use SpecDD sections correctly: write only sections that add local value, keep authority clear, and express behavior, boundaries, tasks, scenarios, paths, and examples.
25 guides - Spec-writing technique
Improve SpecDD craft with techniques for small specs, right-level placement, naming, splitting, explicit rules, draft review, edge cases, and compatibility.
16 guides - Spec-driven workflows
Use SpecDD workflows to draft, review, implement, synchronize, and evolve local specs without losing source-of-truth context.
11 guides - Work with SpecDD skills
Use SpecDD skills deliberately: choose the right skill for the phase, keep authority clear, chain skills safely, and verify each result against local specs.
17 guides - Software design practices
Use SpecDD to make software design decisions operational: responsibility, boundaries, layers, cohesion, debt prevention, public APIs, and dependency direction.
20 guides - Adopt SpecDD on existing projects
Adopt SpecDD gradually in live codebases by starting with active areas, reviewing generated specs, expanding folder by folder, and measuring practical review and delivery signals.
10 guides - Testing and quality
Turn SpecDD specs into practical quality work: TDD and BDD loops, acceptance criteria, coverage tracing, CI checks, regression tests, and testability review.
11 guides - Code review and governance
Use SpecDD in code review and governance by checking local authority, behavior, boundaries, spec updates, agent output, and high-risk contract changes.
9 guides - Refactoring and maintenance
Use SpecDD to keep maintenance safe: preserve specified behavior, maintain authority while moving code, keep specs current, and delete obsolete contracts carefully.
9 guides - Security and risk
Use SpecDD to make security and risk constraints local, explicit, reviewable, and hard for humans or agents to weaken accidentally.
13 guides - Troubleshooting
Fix common SpecDD problems: agent setup, .sdd highlighting, CLI and Node errors, ambiguous specs, unresolved paths, vague specs, stale criteria, and skill installs.
12 guides