specdd-do
Implement Changes Under SpecDD Authority
SpecDD projects need clear governance for AI agents making code and task changes. This skill establishes bootstrap resolution, spec chain navigation, and implementation rules so agents work correctly within project authority boundaries.
Download the skill ZIP
Upload in Claude
Go to Settings → Capabilities → Skills → Upload skill
Toggle on and start using
Test it
Using "specdd-do". Fix the null pointer exception in src/services/auth.js. This is a SpecDD project.
Expected outcome:
- Resolved bootstrap chain: .specdd/bootstrap.md -> .specdd/bootstrap.project.md
- Resolved spec chain: .specdd/specs/auth.md
- Confirmed write authority: spec at .specdd/specs/auth.md section 3 grants write permission
- Implementation: Added null check at line 142 of src/services/auth.js
- Verification: All existing tests pass, one new test added for null input
- Specs used: bootstrap.md, bootstrap.project.md, specs/auth.md
- Files changed: src/services/auth.js, tests/auth.test.js
- Uncertainty: None identified
Using "specdd-do". Can I add a new utility function to the shared library? Show me the governance check first.
Expected outcome:
- Governance Check:
- Bootstrap: .specdd/bootstrap.md (version 2.1) - grants implementation authority
- Spec chain for lib/utils: bootstrap.md -> specs/shared.md -> specs/utils.md
- Write authority: specs/utils.md section 2.1 - 'Contributors may add new utility functions'
- Constraints: specs/shared.md section 5 - 'New utilities must not introduce external dependencies'
- Verdict: Change is authorized under current governance, with the constraint that no new external dependencies are added
Security Audit
SafeAll 11 static analysis findings are false positives. The 9 backtick detections are Markdown inline code formatting for file paths and keywords, not Ruby shell execution. The 2 weak cryptographic algorithm detections correspond to an Apache-2.0 license identifier and the word 'security' in a plain sentence, not actual crypto code. The skill is a SpecDD workflow instruction set with no executable code, network access, or file system manipulation.
Low Risk Issues (2)
Risk Factors
⚙️ External commands (9)
Quality Score
What You Can Build
Feature Implementation in SpecDD Projects
A developer working in a SpecDD-governed project needs an AI agent to implement a new feature while respecting all bootstrap rules, spec chains, and authority boundaries.
Automated Code Changes Under Governance
An AI agent making routine code changes needs clear rules about which specs to read, when to verify authority, and how to report results without violating project contracts.
Consistent Change Management Across Teams
A team lead wants all AI-assisted changes to follow the same governance rules, ensuring consistent spec resolution and authority checking across multiple contributors.
Try These Prompts
I need to fix a bug in src/parser.js. The project is already a SpecDD project with bootstrap files. Resolve the spec chain, confirm I have write authority, and make the smallest correct change.
I need to add a new endpoint to the API. Read the bootstrap chain for this project. Then resolve the spec chain for the routes directory. Check both the project-level and local specs for write authority before planning.
We need to refactor the authentication module. Walk the full spec chain from the project root to the auth module directory. Identify all governing constraints. Verify that write authority is granted at the nearest local spec. Do not proceed if any spec contains a Forbids rule for this change.
Implement the database migration for the new user preferences feature. Follow the SpecDD workflow: resolve bootstrap and spec chain, verify write authority, make the smallest correct change, run relevant tests and validation, then provide a report of specs used, files changed, verification results, and any remaining uncertainty.
Best Practices
- Read bootstrap files only when the active project root changes or exact text is needed for a decision. Do not reread unnecessarily.
- Make the smallest correct change inside your write authority. Avoid scope creep or opportunistic unrelated modifications.
- Verify write authority from the nearest governing spec before every edit. Never infer authority from similar filenames or conventions.
Avoid
- Editing files without first resolving the spec chain and confirming write authority from the governing spec.
- Rereading the entire spec chain when only the narrowest relevant spec is needed for the current decision.
- Completing unrelated tasks opportunistically while implementing a specified change under authority.