| name | plan-compliance-audit |
| description | Systematic verification of implementation plan completion. Use when declaring a plan complete, when the user asks for a status check, or before creating a walkthrough/summary artifact. |
Plan Compliance Audit
When you need to verify that an implementation plan has been fully executed, follow this process BEFORE declaring completion.
Step 1: Extract Every Deliverable
Read the implementation plan line by line. For each section, extract:
- Every file mentioned by name (e.g.,
Tests/Integration/FooTests.swift)
- Every quantitative target (e.g., "30 prompts", "≥80% coverage")
- Every process step (e.g., "run controlled eval on device")
- Every artifact to produce (e.g., "coverage gap analysis")
Create a checklist of these items.
Step 2: Verify Each Deliverable Exists
For each item on the checklist:
- Files: Verify the file exists at the specified path with
view_file or list_dir
- Quantitative targets: Run the measurement (e.g., count prompts, run coverage)
- Process steps: Check for evidence they were executed (e.g., updated baselines with timestamps)
- Artifacts: Verify they exist and contain the specified content
Step 3: Check for Deviations
Compare what was delivered vs. what was planned:
- Were any items renamed? (e.g., "4B: Flow viewer" → "4B: Coverage measurement")
- Were any items folded into other items without documenting the merge?
- Were any items simply never started?
- Were estimated values used where measured values were required?
Step 4: Report Honestly
Create a table with columns: Plan Item | Status | Evidence | Notes
Use these statuses:
- ✅ DONE — delivered as specified
- ⚠️ PARTIAL — delivered but not matching spec
- 🔄 CHANGED — scope changed without flagging
- ❌ NOT DONE — never executed
- ⏭️ DEFERRED — explicitly deferred with rationale documented
Never use ✅ for items that are PARTIAL, CHANGED, or DEFERRED.
Step 5: Deviation Documentation Check
- For each task tracker item, compare the action described against the original plan item text.
- If the merge target, file location, or approach differs from what was planned, a
> [!WARNING] block MUST exist in the implementation plan artifact (not just the task tracker) explaining the change.
- Informal notes like "(core rule)" or "(merged into X)" in the task tracker are insufficient — they must be reflected in the plan artifact.
When to Use This Skill
- Before writing a walkthrough artifact
- Before telling the user a plan is "100% complete"
- When the user asks "is this aligned with the plan?"
- After subagents report task completion (spot-check their claims)
