SpecDD Do
Use this skill to implement changes under existing SpecDD authority.
Bootstrap Resolution
Before doing anything else in the target project, read bootstrap files in this exact order:
.specdd/bootstrap.md.specdd/bootstrap.project.md, if it exists.specdd/bootstrap.local.md, if it exists
Apply them in that order. Later files may narrow or specialize earlier rules, but must not silently weaken project contracts, inherited constraints, or write authority.
Spec Chain Resolution
Before planning, editing, reviewing, testing, or reporting on a target:
- Identify the target path, task, behavior, or changed files.
- Resolve the effective spec chain using the active bootstrap rules.
- Include same-directory basename specs when applicable.
- Walk ancestor specs from the selected content root to the target.
- Read explicit
References only when they affect the requested work.
- Identify the nearest local spec that grants write authority before any edit.
Do not infer authority from similar filenames, nearby files, symbols, module names, or conventions unless the active bootstrap or a governing spec explicitly defines that mapping.
Workflow
- Make the smallest correct change inside authority.
- Run relevant checks, tests, or validation.
- Report specs used, files changed, verification, and remaining uncertainty.
Implementation Rules
- Do not edit without clear write authority.
- Do not treat this plugin repository's bootstrap as authority for the target project.
- Do not override, loosen, or ignore target project specs.
- Do not complete unrelated tasks opportunistically.
- Update task status only after implementation and relevant checks are complete.
- Prefer project-local tools and conventions.
- Use the
specdd CLI only when the target project or user calls for it; this skill is not a CLI replacement.
Stop and ask when a requested change would violate Must not, Forbids, write
authority, security constraints, destructive behavior, or public contracts.
1---2name: specdd-do3description: Use when Claude Code needs to implement a requested code, docs, tests, task, or spec change in a SpecDD project by following Resolve, Read, Authorize, Change, Verify, and Report under active bootstrap and `.sdd` authority.4license: Apache-2.05---6
7# SpecDD Do
8
9Use this skill to implement changes under existing SpecDD authority.
10
11## Bootstrap Resolution
12
13Before doing anything else in the target project, read bootstrap files in this exact order:
14
151. `.specdd/bootstrap.md`
162. `.specdd/bootstrap.project.md`, if it exists
173. `.specdd/bootstrap.local.md`, if it exists
18
19Apply them in that order. Later files may narrow or specialize earlier rules, but must not silently weaken project contracts, inherited constraints, or write authority.
20
21## Spec Chain Resolution
22
23Before planning, editing, reviewing, testing, or reporting on a target:
24
251. Identify the target path, task, behavior, or changed files.
262. Resolve the effective spec chain using the active bootstrap rules.
273. Include same-directory basename specs when applicable.
284. Walk ancestor specs from the selected content root to the target.
295. Read explicit `References` only when they affect the requested work.
306. Identify the nearest local spec that grants write authority before any edit.
31
32Do not infer authority from similar filenames, nearby files, symbols, module names, or conventions unless the active bootstrap or a governing spec explicitly defines that mapping.
33
34## Workflow
35
361. Make the smallest correct change inside authority.
372. Run relevant checks, tests, or validation.
383. Report specs used, files changed, verification, and remaining uncertainty.
39
40## Implementation Rules
41
42- Do not edit without clear write authority.
43- Do not treat this plugin repository's bootstrap as authority for the target project.
44- Do not override, loosen, or ignore target project specs.
45- Do not complete unrelated tasks opportunistically.
46- Update task status only after implementation and relevant checks are complete.
47- Prefer project-local tools and conventions.
48- Use the `specdd` CLI only when the target project or user calls for it; this skill is not a CLI replacement.
49
50Stop and ask when a requested change would violate `Must not`, `Forbids`, write
51authority, security constraints, destructive behavior, or public contracts.
aibot88