analysis-phase
Skill94 starsChanged 6 months agoMITView on GitHub
Validates cross-artifact consistency and detects breaking changes during feature analysis. Use when running /analyze command, validating spec-plan alignment, checking task-implementation consistency, or identifying API/database/UI breaking changes before deployment. (project)
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Check spec → plan → tasks alignment
- Distinctive: line 27
Read spec.md requirements, verify each has corresponding plan component.
- Distinctive: line 35
Read plan.md components, verify each broken into tasks in tasks.md.
- Distinctive: line 41
No orphaned tasks (tasks without plan component) </step>
- Distinctive: line 66
Verify all dependencies documented and accounted for.
- Very specific: line 72
Create specs/NNN-slug/analysis-report.md:
- Distinctive: line 102
All spec requirements have plan component coverage
- Distinctive: line 103
All plan components have task breakdown
- Distinctive: line 106
No orphaned artifacts (tasks without plan, plan without spec) </validation>
- Distinctive: line 132
❌ Don't: Write vague findings like "inconsistencies found"
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<objective>
Validates cross-artifact consistency and detects breaking changes during the /analyze phase. Ensures spec requirements align with plan components, tasks match implementation, and breaking changes are identified before deployment.
</objective><quick_start> Validate cross-artifact consistency and detect breaking changes:
- Check spec → plan → tasks alignment
- Detect breaking changes (API, database, UI, auth)
- Validate dependencies
- Generate analysis-report.md with findings
Inputs: spec.md, plan.md, tasks.md Outputs: analysis-report.md </quick_start>
<workflow>
<step number="1">
**Check spec-plan consistency**Read spec.md requirements, verify each has corresponding plan component. Flag missing mappings in analysis report.
See references/examples.md for grep commands.
</step>
<step number="2">
**Verify task-implementation alignment**Read plan.md components, verify each broken into tasks in tasks.md.
Validate:
- Each plan component has ≥1 task
- Task acceptance criteria match spec success criteria
- No orphaned tasks (tasks without plan component)
</step>
<step number="3">
**Detect breaking changes**Scan for patterns indicating breaking changes:
- API changes: Endpoint signature modifications, required parameter additions, response format changes
- Database changes: Schema modifications, required field additions, migrations affecting existing data
- UI changes: Component interface changes, prop requirement additions
- Auth changes: Permission model modifications, authentication flow changes
Flag with impact level (Low/Medium/High) using reference rubric.
</step>
<step number="4">
**Validate dependencies**Cross-reference:
- Imports and integrations mentioned in plan
- External dependencies in tasks
- Integration points in spec
Verify all dependencies documented and accounted for.
</step>
<step number="5">
**Generate analysis report**Create specs/NNN-slug/analysis-report.md:
# Analysis Report
## Consistency Check
- Spec-Plan: [✓/✗] Description
- Plan-Tasks: [✓/✗] Description
## Breaking Changes
- [High/Medium/Low] Description and impact
## Dependency Validation
- [✓/✗] Dependencies documented
## Recommendations
- Action items to fix inconsistenciesUpdate state.yaml: analysis.status = completed
</step>
</workflow>
<validation>
After analysis, verify:- All spec requirements have plan component coverage
- All plan components have task breakdown
- Breaking changes flagged with impact level (Low/Medium/High)
- Analysis report generated with actionable findings
- No orphaned artifacts (tasks without plan, plan without spec)
</validation>
<anti_patterns>
<pitfall name="missing_breaking_changes">
❌ Don't: Assume no breaking changes without scanning
✅ Do: Explicitly check API signatures, database schema, required fields, auth changes
Why: Breaking changes missed in analysis cause production issues post-deployment
</pitfall>
<pitfall name="inconsistent_artifacts">
**❌ Don't**: Assume spec and plan are aligned
**✅ Do**: Explicitly validate each spec requirement has corresponding plan componentWhy: Missing mappings lead to incomplete implementation
</pitfall>
<pitfall name="no_cross_reference">
**❌ Don't**: Skip dependency validation
**✅ Do**: Cross-reference all imports, integrations, external dependenciesWhy: Undocumented dependencies cause integration failures
</pitfall>
<pitfall name="vague_findings">
**❌ Don't**: Write vague findings like "inconsistencies found"
**✅ Do**: Specify exact artifacts, line numbers, and recommended fixesWhy: Actionable findings enable quick remediation
</pitfall>
</anti_patterns>
<success_criteria>
- All spec requirements mapped to plan components (no gaps)
- All plan components broken into tasks (no orphans)
- Breaking changes documented with impact level (High/Medium/Low)
- Dependencies validated and documented
- analysis-report.md generated with actionable findings
- state.yaml updated (analysis.status = completed) </success_criteria>
<references>
See references/ for:
- Cross-artifact consistency matrix
- Breaking change detection patterns
- Impact assessment rubric
- Real-world analysis examples
</references>In this repository48 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/Agents.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- anti-duplicationSkill
- audit-claude-mdSkill
- breaking-change-detectorSkill
- caching-strategySkill
- clarification-phaseSkill
- create-agent-skillsSkill
- create-hooksSkill
- create-meta-promptsSkill
- create-slash-commandsSkill
- create-subagentsSkill
- debug-phaseSkill
- dependency-conflict-resolverSkill
- design-tokensSkill
- domain-memorySkill
- dry-runSkill
- epic-meta-promptingSkill
- epic-scopingSkill
- epic-sprintsSkill
- epic-walkthroughSkill
- error-recoverySkill
- finalize-phaseSkill
- git-workflow-enforcerSkill
- hallucination-detectorSkill
- implementation-phaseSkill
- mockup-extractionSkill
- multi-agent-votingSkill
- optimization-phaseSkill
- parallel-execution-optimizerSkill
- planning-phaseSkill
- production-deployment-phaseSkill
- project-initialization-phaseSkill
- regression-test-generatorSkill
- roadmap-integrationSkill
- session-boundarySkill
- shadcn-integrationSkill
- specification-phaseSkill
- staging-deployment-phaseSkill
- staging-validation-phaseSkill
- task-breakdown-phaseSkill
- task-status-syncSkill
- theme-consistencySkill
- ultrathinkSkill
- workflow-detectionSkill
- worktree-contextSkill
- x-announcementSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.