.claude/skills/speckit-sync-analyze/SKILL.md
Analyze drift between specs and implementation. Compares requirements against code to find divergence.
npx skillsauth add pradeepmouli/lspeasy speckit-sync-analyzeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Analyze drift between specifications and implementation. This command compares your spec requirements (FR-, SC-, acceptance scenarios) against the actual codebase to identify where they've diverged.
$ARGUMENTS
Read the project structure to understand the codebase:
specs/*/spec.md filesFind all spec files in the project:
find specs -name "spec.md" -type f 2>/dev/null | sort
For each spec, extract:
For each spec, determine:
Use these heuristics:
Find code that doesn't match any spec:
Output a structured report in this format:
# Spec Drift Report
Generated: [timestamp]
Project: [project name]
## Summary
| Category | Count |
|----------|-------|
| Specs Analyzed | X |
| Requirements Checked | X |
| ✓ Aligned | X (Y%) |
| ⚠️ Drifted | X (Y%) |
| ✗ Not Implemented | X (Y%) |
| 🆕 Unspecced Code | X |
## Detailed Findings
### Spec: [spec-id] - [title]
#### Aligned ✓
- FR-001: [description] → [implementation location]
#### Drifted ⚠️
- FR-002: Spec says "[spec text]" but code does "[actual behavior]"
- Location: [file:line]
- Severity: [minor|moderate|major]
#### Not Implemented ✗
- FR-003: [description]
### Unspecced Code 🆕
| Feature | Location | Lines | Suggested Spec |
|---------|----------|-------|----------------|
| [feature] | [path] | [count] | [spec-XXX] |
## Inter-Spec Conflicts
[List any contradictions between specs]
## Recommendations
1. [First recommendation]
2. [Second recommendation]
Save the report to:
.specify/sync/drift-report.md (human-readable).specify/sync/drift-report.json (machine-readable)The JSON report should follow this schema:
{
"generated": "ISO-8601 timestamp",
"project": "project name",
"summary": {
"specs_analyzed": 0,
"requirements_checked": 0,
"aligned": 0,
"drifted": 0,
"not_implemented": 0,
"unspecced_features": 0
},
"specs": [
{
"id": "spec-id",
"title": "Spec Title",
"aligned": ["FR-001", "FR-002"],
"drifted": [
{
"requirement": "FR-003",
"spec_text": "what spec says",
"actual": "what code does",
"location": "path/to/file.cs:123",
"severity": "moderate"
}
],
"not_implemented": ["FR-004"]
}
],
"unspecced": [
{
"feature": "FeatureName",
"location": "path/to/file",
"lines": 150,
"suggested_spec": "spec-013"
}
],
"conflicts": []
}
/speckit.sync.analyze
/speckit.sync.analyze --spec 011-register-write
/speckit.sync.analyze --json
--spec <id> to analyze a single spec--json for machine-readable output onlytools
Use for ANY rename, file-move, or move-symbol refactor — especially rename-heavy work across multiple files. Claude Code's built-in LSP tool is READ-ONLY (find references, but no rename / file-move / move-symbol). Hand-editing those refactors silently misses re-exports, aliased imports, type-only imports, and {@link} doc references. This skill drives a real language server via the `lspeasy` CLI to apply a correct WorkspaceEdit that catches every reference. Trigger when the user asks to rename a function/class/variable/type project-wide, move a file and fix its importers, or pull a symbol out into another module.
tools
Documentation site for lspeasy Use when: You are building a browser-based LSP client, a WebSocket-backed language....
tools
Documentation site for lspeasy Use when: You are implementing a custom client layer and need the same validation....
tools
Use when working with lspeasy (client, core, server). Covers: lsp, language-server-protocol, lsp-client, language-client, jsonrpc, transport, lsp-server, language-server.