92 lines
2.7 KiB
Markdown
92 lines
2.7 KiB
Markdown
|
---
|
||
|
|
name: challenge-plan
|
||
|
|
description: "Silent audit and batch review of the implementation plan. Validates traceability, task granularity, dependency correctness, milestone quality, and scope discipline. Updates the single plan file in place."
|
||
|
|
---
|
||
|
|
|
||
|
|
Perform a silent, structured audit of the plan against the architecture and code design documents. Apply fixes directly to the plan file. Do not ask interactive questions.
|
||
|
|
|
||
|
|
**Announce at start:** "I'm using the challenge-plan skill to audit and review the implementation plan."
|
||
|
|
|
||
|
|
## Primary Input
|
||
|
|
|
||
|
|
- `docs/plan/{date}-{feature}.md`
|
||
|
|
- `docs/architecture/{date}-{feature}.md`
|
||
|
|
- `docs/code-design/{date}-{feature}.md`
|
||
|
|
|
||
|
|
## Primary Output (STRICT PATH)
|
||
|
|
|
||
|
|
- Updated `docs/plan/{date}-{feature}.md`
|
||
|
|
|
||
|
|
## Audit Phases
|
||
|
|
|
||
|
|
### Phase 1: Traceability
|
||
|
|
- Every task maps to upstream architecture or code design artifacts
|
||
|
|
- No orphan tasks exist
|
||
|
|
|
||
|
|
### Phase 2: Coverage
|
||
|
|
- All major implementation surfaces from upstream docs are represented
|
||
|
|
- Migration, integration, rollout, config, and observability tasks are included where needed
|
||
|
|
|
||
|
|
### Phase 3: Granularity
|
||
|
|
- Tasks are neither too vague nor too fine-grained
|
||
|
|
- Completion criteria are actionable
|
||
|
|
|
||
|
|
### Phase 4: Dependency Correctness
|
||
|
|
- Dependencies reflect actual implementation order
|
||
|
|
- Parallelization opportunities are valid
|
||
|
|
- No circular task graph exists
|
||
|
|
|
||
|
|
### Phase 5: Scope Discipline
|
||
|
|
- The plan does not introduce new design or product scope
|
||
|
|
- QA and Engineering duties are not mixed into planning incorrectly
|
||
|
|
|
||
|
|
### Phase 6: Structural Completeness
|
||
|
|
- All 12 required sections from the Output Format are present
|
||
|
|
- `# Open Questions` section exists (may be marked N/A with reason if no questions remain)
|
||
|
|
- Each task has defined dependencies, deliverables, and completion criteria
|
||
|
|
- The dependency graph matches the execution order text
|
||
|
|
|
||
|
|
## Review Output Format
|
||
|
|
|
||
|
|
Write the results directly into the `## Planning Review` section using this exact format:
|
||
|
|
|
||
|
|
```markdown
|
||
|
|
## Planning Review
|
||
|
|
|
||
|
|
### 1. Traceability & Coverage
|
||
|
|
- [PASS/FAIL] All required work is represented and traceable.
|
||
|
|
- Findings: ...
|
||
|
|
|
||
|
|
### 2. Task Quality
|
||
|
|
- [PASS/FAIL] Tasks are actionable and appropriately sized.
|
||
|
|
- Findings: ...
|
||
|
|
|
||
|
|
### 3. Dependency Logic
|
||
|
|
- [PASS/FAIL] Dependency order is correct and practical.
|
||
|
|
- Findings: ...
|
||
|
|
|
||
|
|
### 4. Scope Discipline
|
||
|
|
- [PASS/FAIL] No design drift or scope drift detected.
|
||
|
|
- Findings: ...
|
||
|
|
|
||
|
|
### 5. Structural Completeness
|
||
|
|
- [PASS/FAIL] All required sections present and Open Questions addressed.
|
||
|
|
- Findings: ...
|
||
|
|
|
||
|
|
### 6. Final Verdict
|
||
|
|
- [APPROVED/REJECTED]
|
||
|
|
- Reason: ...
|
||
|
|
```
|
||
|
|
|
||
|
|
## Guardrails
|
||
|
|
|
||
|
|
Do:
|
||
|
|
- Audit silently and fix issues in batch
|
||
|
|
- Keep the plan aligned to upstream design
|
||
|
|
- Use the exact review format
|
||
|
|
|
||
|
|
Do not:
|
||
|
|
- Ask interactive questions one-by-one
|
||
|
|
- Change architecture or code design
|
||
|
|
- Create new files
|