plan（计划）

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

1. Search Sibyl for related tasks, decisions, prior plans: sibyl search "<feature keywords>" sibyl task list -s todo
2. Define success criteria — what does "done" look like?

- Measurable outcomes (tests pass, endpoint returns X, UI renders Y) - NOT vague goals ("improve performance" → "p95 latency < 200ms")

1. Identify constraints:

- Files/modules that CAN'T change - Dependencies that must be respected - Timeline or budget considerations

1. Classify complexity: Scale Description Planning Depth Quick fix < 3 files, clear solution Skip to implementation Feature 3-10 files, known patterns Light plan (this skill) Epic 10+ files, new patterns Full plan + orchestration Redesign Architecture change Full plan + research first

Gate

If this is a quick fix, stop planning and go build. Planning a 5-minute fix is waste.

Phase 2: EXPLORE

Understand the codebase surface area before decomposing.

Actions

1. Map the impact surface — which files/modules will this touch?

- Spawn an Explore agent if the scope is uncertain - Read the actual code, don't guess from file names

1. Identify existing patterns:

- How does similar functionality work in this codebase? - What conventions exist? (naming, file structure, test patterns)

1. Find the dependencies:

- What must exist before this can work? - What will break if we change X?

Output

A mental model of the change surface:

"This touches: [module A] (new endpoint), [module B] (type changes), [module C] (tests). Pattern follows [existing feature X]. Depends on [infrastructure Y] being available."

Phase 3: DECOMPOSE

Break work into verifiable steps. Every step must have a check.

The Verification Rule

A step without a verification method is not a step — it's a hope.

For each task, define:

Verification Methods

Decomposition Heuristics

• 2-5 minute tasks are the sweet spot. If a task takes > 15 minutes, break it further.
• One concern per task. "Add endpoint AND write tests" is two tasks.
• Order by dependency, not difficulty. Foundation first.
• Mark parallelizable tasks. Tasks with no shared files can run simultaneously.

Task Format

## 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

1. Create a Sibyl task for the feature: sibyl task create --title "[Feature]" -d "[success criteria]" --complexity epic
2. Create sub-tasks for each plan step: sibyl task create --title "Task 1: [title]" -e [epic-id] -d "[implementation + verify]"
3. 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:

1. Don't force through. Pause and reassess.
2. Update the plan — add/remove/modify tasks.
3. Update Sibyl — keep the tracking current.
4. Communicate — "Task 3 revealed [X]. Adjusting plan: [changes]."

Execution Handoff

Once the plan is approved, hand off to the right tool:

Trust Gradient for Execution

This is earned confidence, not cutting corners.

Anti-Patterns

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.