Validates project implementation against scope and tasks documents using parallel subagents, producing validation_gaps.md with actionable remediation tasks.
From spectrenpx claudepluginhub codename-inc/spectre --plugin spectrevalidation_gaps.md with actionable tasks ready for immediate implementation."Definition β Connection β Reachability"
Three levels of implementation completeness:
Validation must verify all three levels. A feature with Level 1 but not Level 2 or 3 is NOT completeβit's dead code that happens to match the requirement description.
When verifying any implementation:
REQUIRED: User must provide scope documents to validate against.
<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
Action β CheckArguments: Verify user provided scope documents.
If ARGUMENTS contains file paths or "use thread context" β proceed
Else β Immediately reply:
"What should I validate against? Please provide:
- Path to scope document (e.g.,
docs/tasks/main/scope.md)- Path to tasks document (e.g.,
docs/tasks/main/tasks.md)- Or say 'use thread context' to validate against our conversation"
Wait β User provides validation inputs
Action β ReadScopeDocs: Read provided documents completely (no limits).
Action β ChunkIntoValidationAreas: Break scope into discrete validation areas.
Action β CreateValidationManifest: Document chunks before dispatch.
Validation Areas:
1. {Area Name} β {What to validate}
- Source: {requirement text from scope doc}
- Expected: {what should exist}
2. ...
CRITICAL: Dispatch ALL validation agents in parallel in a SINGLE message with multiple Task tool calls. Do NOT dispatch sequentially.
Action β DispatchValidators: Launch one @analyst per validation area IN PARALLEL.
Subagent Prompt Template:
You are validating scope delivery for ONE specific area.
## Context Documents
- Scope: {path or "thread context"}
- Tasks: {path if provided}
- Branch: {branch_name}
## Your Validation Area
**Area**: {area_name}
**Source Requirement**: {exact text from scope/tasks doc}
**Expected Deliverables**: {what should exist}
## Your Task
1. Investigate YOUR SPECIFIC AREA only
2. For each requirement, determine:
- **Status**: β
Delivered | β οΈ Partial | π Dead Code | β Missing
- β
**Delivered**: Defined AND connected AND reachable from user action
- β οΈ **Partial**: Code exists but has broken/missing connections
- π **Dead Code**: Code exists but has zero usage sites
- β **Missing**: Code does not exist
- **Evidence**: Must include BOTH:
1. Definition site: `file:line` where code is defined
2. Usage site: `file:line` where code is called/rendered
- If you can only cite definition without usage β status is β οΈ or π
- **Gap**: What's missing (if any)
3. **CRITICAL - Reachability Verification**:
- Trace the COMPLETE chain from user action to implementation:
- Entry point: What user action triggers this? (click, route, event)
- Call chain: How does execution flow to the implementation?
- Terminal point: What side effect/UI change occurs?
- A broken link at ANY point = β οΈ NOT FULLY DELIVERED
- For every function/component, grep for USAGE not just DEFINITION:
- Functions: Search for `functionName(` to find invocations
- Components: Search for `<ComponentName` to find render sites
- Hooks: Search for `useHookName(` to find consumers
- Props: Search for `propName={` to find where passed
- Zero usage sites = π Dead Code
4. **CRITICAL - Consumer-First Validation (Render-Backward Trace)**:
For UI features, start from the FINAL RENDER and trace BACKWARDS:
- What component renders the feature output? (exact JSX location)
- What variable does that JSX use? (exact variable name)
- Where does that variable come from? (hook, prop, computed value)
- Trace back to the user action. Is every link connected?
Example (filter feature):
- Renders: `BoardColumn` receives `tasks` prop at line 45
- Variable: `tasks` comes from `getFilteredTasksForBoard(board.id)`
- Source: `getFilteredTasksForBoard` uses... `getTasksForBoard` from drag hook
- β BROKEN: This bypasses `displayTasks` from filter hook!
If you can only trace forward (definition β usage) but NOT backward
(render β source), you haven't verified the last mile.
5. **CRITICAL - Dead Computation Detection**:
List every computed value that is NOT directly consumed by a render:
- For each hook return value, grep for where it's destructured/used
- For each computed const, grep for where it's referenced
- A value that's computed but never reaches JSX = π Dead Code
Example:
- `displayTasks` from `useKanbanFilters` β used where?
- Passed to `TasksHeroHeader` β
- Used in `getFilteredTasksForBoard`? β NO β uses different source
- Computed but not in render chain = BUG
6. **Old Code Path Audit**:
When new functionality replaces old patterns:
- What OLD code handled this before? (imports, hooks, functions)
- Is the old code still being called anywhere?
- Are there duplicate data sources for the same concern?
- If old path still active β β οΈ Partial (new code bypassed)
7. Check for scope creep: anything beyond the requirement
## Output Format
AREA: {area_name} STATUS: {overall: Delivered | Partial | Dead Code | Missing}
REQUIREMENTS:
DEAD COMPUTATIONS:
OLD CODE PATHS:
SCOPE CREEP: {any features beyond scope}
SUMMARY: {1-2 sentences}
Verification Patterns for Subagents:
| Checking | Search Pattern | Meaning |
|---|---|---|
| Function called | functionName\( | Invocation exists |
| Component renders | <ComponentName | JSX usage exists |
| Hook consumed | useHookName\( | Hook is used |
| Prop passed | propName={ | Parent passes prop |
| Export imported | import.*Name | Module consumed |
Common broken link patterns to check:
Last-Mile Anti-Patterns (these cause "works in code, broken in UI"):
displayTasks computed but getTasksForBoard called in render
Handler created but onClick still points to old handler
New hook created but component still imports old hook
State updated correctly but wrong variable passed to child component
Wait β All validation agents complete
Action β ConsolidateFindings: Merge all subagent outputs.
Action β FinalWiringChecklist: Before marking any area complete, verify:
| Check | Question |
|---|---|
| Consumer connected? | Does every new function/hook have a consumer that uses its output? |
| Render chain complete? | Can you trace from JSX β variable β hook β user action without breaks? |
| Old paths removed? | If replacing old code, is the old path dead or redirected? |
| No orphaned computation? | Is every computed value actually used in a render path? |
| No duplicate sources? | Is there only ONE data source for each concern (not old + new)? |
CRITICAL: If any check fails for an area marked β , downgrade to β οΈ and add gap task.
Action β DetermineOutputDir:
branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)OUT_DIR={that value}OUT_DIR=docs/tasks/{branch_name}mkdir -p "${OUT_DIR}/validation"Action β CreateValidationGapsDoc: Generate {OUT_DIR}/validation/validation_gaps.md.
Document Structure:
# Validation Gaps: {task_name}
*Generated: {timestamp}*
## Summary
- **Overall Status**: {Complete | Needs Work | Significant Gaps}
- **Requirements**: {X of Y} delivered
- **Gaps Found**: {count} requiring remediation
- **Scope Creep**: {count} items (document or remove)
---
## Gap Remediation Tasks
### π¦ Phase 1: Critical Gaps
#### π [1.1] {Gap Title - e.g., "Connect auth flow to login page"}
**Requirement**: {original requirement text}
**Current State**: {what exists now β definition site if code exists}
**Gap**: {what's missing β broken link in the chain}
- [ ] **1.1.1** {Specific action - e.g., "Wire LoginButton onClick to auth handler"}
- **Produces**: {output this creates β e.g., "onClick handler calling authService.login()"}
- **Consumed by**: {what uses this β e.g., "LoginButton component render"}
- **Replaces**: {old code path β e.g., "inline console.log in onClick" or "N/A"}
- [ ] {Verifiable outcome 1}
- [ ] {Verifiable outcome 2}
- [ ] **1.1.2** {Specific action - e.g., "Add login route to app router"}
- **Produces**: {output β e.g., "/login route rendering LoginPage"}
- **Consumed by**: {consumer β e.g., "App router, navigated via authService redirect"}
- [ ] {Verifiable outcome 1}
- [ ] {Verifiable outcome 2}
#### π [1.2] {Next Gap Title}
...
### π¦ Phase 2: Medium Priority Gaps
...
### π¦ Phase 3: Low Priority / Polish
...
---
## Scope Creep Review
Items implemented beyond original scope:
- [ ] **{Feature}**: {Keep and document | Remove | Discuss}
- Evidence: {file:line}
- Recommendation: {action}
---
## Validation Coverage
| Area | Status | Definition | Usage | Render Chain |
|------|--------|------------|-------|--------------|
| {area 1} | β
| {file:line} | {file:line} | JSX β var β source β |
| {area 2} | β οΈ | {file:line} | {file:line} | Broken at {link} |
| {area 3} | π | {file:line} | NONE | Dead computation |
| {area 4} | β | β | β | β |
## Dead Computations Found
| Variable | File | Computed By | Should Be Consumed By |
|----------|------|-------------|----------------------|
| {displayTasks} | {useKanbanFilters.ts} | {applyTaskFilters} | {KanbanBoard render} |
## Old Code Paths Still Active
| Old Path | Location | Should Be Replaced By | Impact |
|----------|----------|----------------------|--------|
| {getTasksForBoard} | {useKanbanDrag:45} | {displayTasks from useKanbanFilters} | Bypasses new filter |
Action β PresentResults: Show validation summary.
Validation Complete
**> Status: {Complete | Needs Work | Significant Gaps}
- {X of Y} requirements delivered
- {N} gaps requiring remediation
- {N} scope creep items to review **> Gap Remediation Doc:
{OUT_DIR}/validation/validation_gaps.md{1-2 sentence summary of key findings}
Action β RenderFooter: Render Next Steps footer using @skill-spectre:spectre-guide skill
See /skill-spectre:spectre skill for footer format and command options.
/validateValidates CLI harness for software at given path or GitHub repo against HARNESS.md standards: directory structure, files, Click CLI, core modules, tests, and docs.
/validateValidates project structure, configurations, and best practices across git, build, code quality, CI/CD, producing detailed report with issues, score, and recommendations. Supports --path and --verbose.
/validateValidates plans, roadmaps, or proposals as ruthless CTO mentor, producing 8-section report with verdict, strengths, flaws, blindspots, and next steps.