Critical review and gap analysis skill that can be invoked at any workflow stage. Use to challenge decisions, identify missing specifications, verify coherence, and surface unaddressed questions in CDC, findings, plans, or any deliverable. Acts as a devil's advocate by deeply analyzing codebase, project documentation ([DOC]-* folders), and context.
npx claudepluginhub joshuarweaver/cascade-code-testing-misc --plugin laizyio-workflowskillsThis skill uses the workspace's default tool permissions.
Act as a critical reviewer and devil's advocate at any stage of the feature workflow. This skill performs deep analysis to:
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Act as a critical reviewer and devil's advocate at any stage of the feature workflow. This skill performs deep analysis to:
Key principle: Better to surface issues early than discover them during implementation or testing.
Use this skill:
Use the AskUserQuestion tool when clarification is needed on identified gaps.
After analysis, use AskUserQuestion to:
AskUserQuestion:
questions:
- question: "I found that the CDC doesn't address error handling. How should we proceed?"
header: "Gap Found"
options:
- label: "Add to CDC now"
description: "Update the specification before continuing"
- label: "Note for later"
description: "Document as known gap, address during implementation"
- label: "Not needed"
description: "This case won't occur in practice"
multiSelect: false
This ensures:
The challenger analyzes multiple sources to build comprehensive context:
Look for documentation folders at project root:
- [DOC]-{ProjectName}/
- docs/
- documentation/
- .doc/
- wiki/
Read all relevant documentation to understand:
Analyze existing code to understand:
- Current implementation patterns
- Data models and schemas
- API contracts
- Service dependencies
- Configuration patterns
Review current workflow documents:
- CDC.md (specification)
- findings.md (research)
- Plan.md (implementation plan)
- test-plan.md (test strategy)
If Obsidian MCP is available:
- Search for related notes
- Find linked concepts
- Discover historical context
Example context gathering:
1. Read CDC.md for "email notifications" feature
2. Found [DOC]-Backend/ with architecture.md
3. Found existing NotificationService in codebase
4. Found EmailTemplate component already exists
5. Mental model: Feature partially exists, CDC doesn't mention this
Systematically check for gaps in each category:
2.1 Missing Requirements
2.2 Unclear Specifications
2.3 Incoherence Detection
2.4 Missing Context
See references/gap-analysis-guide.md for detailed checklist.
For each identified issue, formulate a clear challenge:
Structure:
## Challenge: [Title]
**Type:** Gap / Ambiguity / Incoherence / Missing Context
**Severity:** Critical / Major / Minor
**Location:** [Document section or code location]
**Observation:**
[What was found or missing]
**Question:**
[Specific question to resolve the issue]
**Recommendation:**
[Suggested resolution or investigation]
Example:
## Challenge: Existing Email System Not Addressed
**Type:** Missing Context
**Severity:** Critical
**Location:** CDC.md Section 4 (Functional Requirements)
**Observation:**
The CDC specifies creating an EmailService, but the codebase already
has `src/services/NotificationService.ts` with email capabilities.
The CDC doesn't mention whether to extend, replace, or ignore it.
**Question:**
Should we extend the existing NotificationService or create a
separate EmailService? What happens to existing email functionality?
**Recommendation:**
Update CDC to explicitly address the existing NotificationService.
Consider extending it rather than creating parallel functionality.
Cross-check between documents and reality:
CDC vs Codebase:
CDC vs Project Docs:
Findings vs CDC:
Plan vs Findings:
Compile findings into a structured report:
# Challenge Report: [Deliverable Name]
**Date:** [Date]
**Stage:** [Specification / Research / Planning / etc.]
**Challenger:** Claude Code
## Summary
[Brief overview of findings]
- **Critical Issues:** X
- **Major Issues:** X
- **Minor Issues:** X
## Critical Issues
[Must be resolved before proceeding]
## Major Issues
[Should be resolved, but not blocking]
## Minor Issues
[Nice to address, low impact]
## Coherence Check
| Source A | Source B | Status | Notes |
|----------|----------|--------|-------|
| CDC | Codebase | ⚠️ | [Issue] |
| CDC | Project Docs | ✅ | Aligned |
## Questions for User
1. [Question 1]
2. [Question 2]
## Recommendations
1. [Recommendation 1]
2. [Recommendation 2]
## Conclusion
[Overall assessment and suggested next steps]
Focus on:
Key questions:
Focus on:
Key questions:
Focus on:
Key questions:
Focus on:
Key questions:
# Common documentation locations
Glob: [DOC]-*/**/*.md
Glob: docs/**/*.md
Glob: documentation/**/*.md
Glob: *.md (root level)
Glob: .github/**/*.md
# Based on feature name/domain
Grep: "feature-keyword"
Glob: **/*Service*.ts
Glob: **/*Controller*.cs
Glob: **/models/**/*
If Obsidian available:
- Search notes for feature keywords
- Find linked architecture decisions
- Discover related past implementations
The challenger can be invoked:
Phase 0: Specification → [Challenge CDC] → Phase 1: Research
Phase 1: Research → [Challenge Findings] → Phase 2: Planning
Phase 2: Planning → [Challenge Plan] → Phase 3: Implementation
...
references/challenge-checklist.md - Comprehensive checklist by stagereferences/gap-analysis-guide.md - Detailed gap analysis methodology