Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Evaluate-Loop Step 1: PLAN. Use this agent when starting a new track or feature to create a detailed execution plan. Reads spec.md, loads project context, and produces a phased plan.md with specific tasks, acceptance criteria, and dependencies. Triggered by: 'plan feature', 'create plan', 'start track', '/conductor implement' (planning phase).
.claude/skills/ibrahim-3d-loop-planner/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-04 | ✗→✓ | ▲ Improved | 127% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 101% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 149% | 0% |
| case-07 | ✗→✓ | ▲ Improved | 236% | 0% |
| case-09 | ✗→✓ | ▲ Improved | 90% | 0% |
Creates detailed, scoped execution plans for tracks. This is Step 1 of the Evaluate-Loop.
spec.md — what needs to be builtconductor/tracks.md — what's already been done (to avoid overlap)plan.md (if exists) — check for prior progressread_file in order:
conductor/tracks.md — completed tracks and their deliverablesspec.md — requirements for this trackplan.md (if exists) — check what's already [x] doneconductor/product.md — product scope referenceconductor/tech-stack.md — technical constraintsBefore writing any plan:
spec.md asks for (deliverables)tracks.md)write_file plan.md with this structure (now includes dependency DAG for parallel execution):
markdown# [Track Name] — Execution Plan ## Context - **Track**: [ID] - **Spec**: [one-line summary] - **Dependencies**: [list prerequisite tracks] - **Overlap Check**: [tracks checked, conflicts found/none] - **Execution Mode**: PARALLEL | SEQUENTIAL ## Dependency Graph <!-- YAML DAG for parallel execution -->
dag: nodes:
name: "Task name" type: "code" # code | ui | integration | test | docs | config files: "src/path/to/file.ts"] depends_on: ] estimated_duration: "30m" phase: 1
name: "Another task" type: "code" files: "src/another/file.ts"] depends_on: ] phase: 1
name: "Depends on 1.1 and 1.2" type: "code" files: "src/path/to/file.ts"] depends_on: "1.1", "1.2"] phase: 1
parallel_groups:
tasks: "1.1", "1.2"] conflict_free: true
tasks: "1.3", "1.4"] conflict_free: false shared_resources: "src/path/to/file.ts"] coordination_strategy: "file_lock"
## Phase 1: [Phase Name]
### Tasks
- [ ] Task 1.1: [Specific action] <!-- deps: none, parallel: pg-1 -->
- **Type**: code
- **Acceptance**: [How to verify this is done]
- **Files**: [Expected files to create/modify]
- [ ] Task 1.2: [Specific action] <!-- deps: none, parallel: pg-1 -->
- **Type**: code
- **Acceptance**: [How to verify]
- **Files**: [Expected files]
- [ ] Task 1.3: [Depends on above] <!-- deps: 1.1, 1.2 -->
- **Type**: code
- **Acceptance**: [How to verify]
- **Files**: [Expected files]
## Phase 2: [Phase Name]
...
## Discovered Work
<!-- Add items here during execution if scope expansion is needed -->When creating the plan, build the dependency graph:
pythondef generate_dag(tasks: list) -> dict: """ Generate DAG from task list. 1. Create nodes for each task 2. Analyze dependencies (explicit + file-based) 3. Identify parallel groups (tasks at same level with no conflicts) 4. Detect shared resources """ nodes = [] for task in tasks: nodes.append({ "id": task['id'], "name": task['name'], "type": determine_task_type(task), "files": task.get('files', []), "depends_on": task.get('depends_on', []), "estimated_duration": estimate_duration(task), "phase": task['phase'] }) # Build adjacency list dependents = defaultdict(list) for node in nodes: for dep in node['depends_on']: dependents[dep].append(node['id']) # Compute topological levels levels = compute_topological_levels(nodes) # Group tasks by level for parallel execution parallel_groups = [] for level_num, level_tasks in enumerate(levels): if len(level_tasks) >= 2: # Analyze file conflicts file_usage = defaultdict(list) for task_id in level_tasks: task = next(n for n in nodes if n['id'] == task_id) for f in task.get('files', []): file_usage[f].append(task_id) # Find conflict-free groups shared_files = {f: tasks for f, tasks in file_usage.items() if len(tasks) > 1} if not shared_files: parallel_groups.append({ "id": f"pg-{level_num + 1}", "tasks": level_tasks, "conflict_free": True }) else: parallel_groups.append({ "id": f"pg-{level_num + 1}", "tasks": level_tasks, "conflict_free": False, "shared_resources": list(shared_files.keys()), "coordination_strategy": "file_lock" }) return { "nodes": nodes, "parallel_groups": parallel_groups }
Each task MUST follow the TDD bite-sized format. Every task is one focused action (2-5 minutes) with exact file paths and complete code:
`markdown### Task 1.1: [Component Name] **Files:** - Create: `exact/path/to/file.ts` - Modify: `exact/path/to/existing.ts:123-145` - Test: `tests/exact/path/to/test.ts` **Step 1: Write the failing test**
test('specific behavior', () => { const result = function(input); expect(result).toBe(expected); });
**Step 2: Run test to verify it fails**
Run: `npm test -- --grep "specific behavior"`
Expected: FAIL with "function not defined"
**Step 3: Write minimal implementation**
export function specificFunction(input: string): string { return expected; }
**Step 4: Run test to verify it passes**
Run: `npm test -- --grep "specific behavior"`
Expected: PASS
**Step 5: Commit**
git add tests/path/test.ts src/path/file.ts git commit -m "feat: add specific feature"
Key rules:
Automatically detect task type from description and files:
| Indicators | Type | |------------|------| | src/components/, .tsx, ui, component | ui | | api/, integration, supabase, stripe | integration | | .test.ts, test, coverage | test | | .md, docs, documentation | docs | | config, .json, .env | config | | Default | code |
Tasks can run in parallel if:
Before finalizing, verify:
| Check | Question | |-------|----------| | Scoped | Does every task trace back to a spec.md requirement? | | No Overlap | Does any task duplicate work from completed tracks? | | Testable | Does every task have clear acceptance criteria? | | Ordered | Are tasks sequenced by dependency? | | Sized | Can each task be completed in a single session? |
Save the plan to the track's plan.md and report:
## Plan Created
**Track**: [track-id]
**Phases**: [count]
**Tasks**: [total count]
**Dependencies**: [list]
**Ready for**: Step 2 (Evaluate Plan) → hand off to loop-plan-evaluatorThe planner MUST update the track's metadata.json at key points:
json{ "loop_state": { "current_step": "PLAN", "step_status": "IN_PROGRESS", "step_started_at": "[ISO timestamp]", "checkpoints": { "PLAN": { "status": "IN_PROGRESS", "started_at": "[ISO timestamp]", "agent": "loop-planner" } } } }
json{ "loop_state": { "current_step": "EVALUATE_PLAN", "step_status": "NOT_STARTED", "checkpoints": { "PLAN": { "status": "PASSED", "started_at": "[start timestamp]", "completed_at": "[ISO timestamp]", "agent": "loop-planner", "commit_sha": "[if plan was committed]", "plan_version": 1 }, "EVALUATE_PLAN": { "status": "NOT_STARTED" } } } }
metadata.jsonloop_state.checkpoints.PLAN fieldscurrent_step to EVALUATE_PLANmetadata.jsonIf metadata.json doesn't exist or is v1 format, create v2 structure with default values.
After creating the plan, the Conductor should dispatch the loop-plan-evaluator agent to verify the plan before execution begins.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 3,829 | 12,913 | +237% | 1 | 1 | 0% | 315 | 3,028 | +861% | 0 | 0 | — |
case-02 | fail→fail | 3,837 | 4,848 | +26% | 1 | 1 | 0% | 191 | 2,957 | +1448% | 0 | 0 | — |
case-03 | fail→fail | 3,902 | 4,554 | +17% | 1 | 1 | 0% | 318 | 2,960 | +831% | 0 | 0 | — |
case-04 | fail→pass | 8,337 | 2,543 | -69% | 1 | 1 | 0% | 1,371 | 3,110 | +127% | 0 | 0 | — |
case-05 | fail→pass | 9,463 | 3,215 | -66% | 1 | 1 | 0% | 1,587 | 3,185 | +101% | 0 | 0 | — |
case-06 | fail→pass | 7,632 | 1,918 | -75% | 1 | 1 | 0% | 1,195 | 2,978 | +149% | 0 | 0 | — |
case-07 | fail→pass | 6,147 | 2,556 | -58% | 1 | 1 | 0% | 920 | 3,091 | +236% | 0 | 0 | — |
case-08 | pass→pass | 7,413 | 1,938 | -74% | 1 | 1 | 0% | 1,160 | 2,955 | +155% | 0 | 0 | — |
case-09 | fail→pass | 10,877 | 4,641 | -57% | 1 | 1 | 0% | 1,829 | 3,475 | +90% | 0 | 0 | — |
case-10 | pass→pass | 4,621 | 4,031 | -13% | 1 | 1 | 0% | 806 | 3,445 | +327% | 0 | 0 | — |
case-11 | fail→pass | 8,161 | 4,442 | -46% | 1 | 1 | 0% | 1,440 | 3,540 | +146% | 0 | 0 | — |
case-12 | fail→pass | 6,500 | 4,155 | -36% | 1 | 1 | 0% | 1,082 | 3,466 | +220% | 0 | 0 | — |
case-13 | fail→pass | 10,169 | 5,532 | -46% | 1 | 1 | 0% | 1,847 | 3,700 | +100% | 0 | 0 | — |
case-14 | pass→pass | 8,259 | 5,159 | -38% | 1 | 1 | 0% | 1,442 | 3,595 | +149% | 0 | 0 | — |
case-15 | fail→pass | 9,875 | 1,928 | -80% | 1 | 1 | 0% | 1,504 | 2,922 | +94% | 0 | 0 | — |
case-16 | pass→pass | 7,750 | 2,005 | -74% | 1 | 1 | 0% | 1,168 | 2,952 | +153% | 0 | 0 | — |
case-17 | fail→pass | 4,174 | 1,570 | -62% | 1 | 1 | 0% | 647 | 2,856 | +341% | 0 | 0 | — |
case-18 | pass→pass | 8,302 | 1,384 | -83% | 1 | 1 | 0% | 1,323 | 2,871 | +117% | 0 | 0 | — |
case-19 | fail→pass | 10,396 | 4,705 | -55% | 1 | 1 | 0% | 1,652 | 3,509 | +112% | 0 | 0 | — |
case-20 | fail→fail | 5,041 | 16,852 | +234% | 1 | 1 | 0% | 468 | 5,023 | +973% | 0 | 0 | — |
case-21 | fail→fail | 3,200 | 5,098 | +59% | 1 | 1 | 0% | 142 | 2,933 | +1965% | 0 | 0 | — |
case-22 | fail→pass | 5,629 | 5,345 | -5% | 1 | 1 | 0% | 701 | 3,497 | +399% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 17 counted toward the lift figure. The other 5 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +55 percentage points is the difference between those two pass rates over the 17 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.