Use when Claude Code needs to diagnose or fix a bug in a SpecDD project by reproducing or inspecting failure, comparing observed behavior to active `.sdd` contracts, and applying the smallest authorized fix.
Installs into .claude/skills of the current project.
Are you the author of Specdd Debug?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/aibot88-specdd-debug)
---
name: specdd-debug
description: Use when Claude Code needs to diagnose or fix a bug in a SpecDD project by reproducing or inspecting failure, comparing observed behavior to active `.sdd` contracts, and applying the smallest authorized fix.
license: Apache-2.0
---
# SpecDD Debug
Use this skill to diagnose failures against the specified contract.
## Bootstrap Resolution
Before doing anything else in the target project, read bootstrap files in this exact order:
1. `.specdd/bootstrap.md`
2. `.specdd/bootstrap.project.md`, if it exists
3. `.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:
1. Identify the target path, task, behavior, or changed files.
2. Resolve the effective spec chain using the active bootstrap rules.
3. Include same-directory basename specs when applicable.
4. Walk ancestor specs from the selected content root to the target.
5. Read explicit `References` only when they affect the requested work.
6. 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
1. Reproduce or inspect the failure before changing code when practical.
2. Compare observed behavior with applicable `Must`, `Must not`, `Scenario`, `Handles`, `Returns`, and `Raises` entries.
3. Identify whether the issue is implementation drift, test drift, spec ambiguity, or missing spec coverage.
4. Fix the smallest root cause inside write authority.
5. Add or update focused regression verification when appropriate.
## Debug Rules
- Do not change specs to match broken behavior unless the user asks for a spec change.
- Do not hide ambiguous public behavior behind implementation assumptions.
- Do not broaden error handling or dependencies beyond the governing specs.
- If the spec and observed desired behavior conflict, ask before editing.
Report the contract used, root cause, files changed, and verification result.
