Structured Planning
Verification-driven task decomposition with Sibyl-native tracking. Mined from 200+ real planning sessions — the plans that actually survived contact with code.
Core insight:
Plans fail when steps can't be verified. Decompose until every step has a concrete check. Track in Sibyl so plans survive context windows.
The Process
digraph
planning
{
rankdir
=
TB
;
node
[
shape
=
box
]
;
"1. SCOPE"
[
style
=
filled
,
fillcolor
=
"#e8e8ff"
]
;
"2. EXPLORE"
[
style
=
filled
,
fillcolor
=
"#ffe8e8"
]
;
"3. DECOMPOSE"
[
style
=
filled
,
fillcolor
=
"#e8ffe8"
]
;
"4. VERIFY & APPROVE"
[
style
=
filled
,
fillcolor
=
"#fff8e0"
]
;
"5. TRACK"
[
style
=
filled
,
fillcolor
=
"#e8e8ff"
]
;
"1. SCOPE"
->
"2. EXPLORE"
;
"2. EXPLORE"
->
"3. DECOMPOSE"
;
"3. DECOMPOSE"
->
"4. VERIFY & APPROVE"
;
"4. VERIFY & APPROVE"
->
"5. TRACK"
;
"4. VERIFY & APPROVE"
->
"3. DECOMPOSE"
[
label
=
"gaps found"
,
style
=
dashed
]
;
}
Phase 1: SCOPE
Bound the work before exploring it.
Actions
Search Sibyl
for related tasks, decisions, prior plans:
sibyl search "
Task [N]: [Imperative title]
**
Files:
**
src/path/file.ts
,
tests/path/file.test.ts
**
Depends on:
**
Task [M]
**
Parallel:
**
Yes/No (can run alongside Task [X])
Implementation [2-4 bullet points of what to do]
Verify
[ ]
pnpm typecheck
passes
-
[ ]
pnpm test -- file.test.ts
passes
-
[
] [
specific assertion about behavior
]
Parallelizability Markers
Mark tasks that can run simultaneously for orchestration:
Wave 1 (foundation): Task 1, Task 2 [parallel]
Wave 2 (core): Task 3, Task 4 [parallel, depends on Wave 1]
Wave 3 (integration): Task 5 [sequential, depends on Wave 2]
Wave 4 (polish): Task 6, Task 7 [parallel, depends on Wave 3]
Phase 4: VERIFY & APPROVE
Review the plan before executing it.
Self-Check
Before presenting to the user, verify:
Every task has a verification method
Dependencies form a DAG (no cycles)
No two parallel tasks modify the same files
Total scope matches the original success criteria
Nothing is over-engineered (YAGNI check)
Present for Approval
Show the plan as a structured list with waves:
Plan: [Feature Name] ** Success criteria: ** [measurable outcome] ** Estimated tasks: ** [N] across [M] waves ** Parallelizable: ** [X]% of tasks can run in parallel
Wave 1: Foundation
[ ] Task 1: [title] → verify: [method]
[ ] Task 2: [title] → verify: [method]
Wave 2: Core Implementation
[ ] Task 3: [title] → verify: [method] (depends: 1)
[ ] Task 4: [title] → verify: [method] (depends: 2)
Wave 3: Integration
[ ] Task 5: [title] → verify: [method] (depends: 3, 4) Gap Analysis After presenting, explicitly check: "Is there anything missing from this plan?" "Should any of these tasks be combined or split further?" "Are the success criteria right?" Phase 5: TRACK Register the plan in Sibyl for persistence. Actions Create a Sibyl task for the feature: sibyl task create --title "[Feature]" -d "[success criteria]" --complexity epic Create sub-tasks for each plan step: sibyl task create --title "Task 1: [title]" -e [epic-id] -d "[implementation + verify]" Record the plan decision: sibyl add "Plan: [feature]" "[N] tasks across [M] waves. Key decisions: [architectural choices]. Dependencies: [critical path]." Adaptive Replanning Plans change when they meet reality. When a task reveals unexpected complexity: Don't force through. Pause and reassess. Update the plan — add/remove/modify tasks. Update Sibyl — keep the tracking current. Communicate — "Task 3 revealed [X]. Adjusting plan: [changes]." Execution Handoff Once the plan is approved, hand off to the right tool: Situation Handoff 3-5 simple tasks, user present Execute directly with verification gates 5-15 tasks, mixed parallel /hyperskills:orchestrate with wave strategy Large epic, 15+ tasks Orchestrate with Epic Parallel Build strategy Needs more research first /hyperskills:research before executing Trust Gradient for Execution Phase Review Level When Full ceremony Implement + spec review + code review First 3-4 tasks Standard Implement + spec review Tasks 5-8, patterns stabilized Light Implement + quick verify Late tasks, established patterns This is earned confidence, not cutting corners. What This Skill is NOT Not required for simple tasks. If the solution is obvious, just build it. Not a design doc generator. Plans are action lists, not architecture documents. Not a blocker. If the user says "just start building," start building. You can plan in parallel. Not rigid. Plans adapt. The first plan is a hypothesis.