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).
How to install loop-planner?
ibrahim-3d/orchestrator-supaconductor/loop-planner
$npx -y skills add ibrahim-3d/orchestrator-supaconductor --skill loop-plannerInstalls into the current project.
›Prefer a prompt? Paste this to your agent
Run `npx skills use "https://github.com/ibrahim-3d/orchestrator-supaconductor" --skill "ibrahim-3d/orchestrator-supaconductor/loop-planner"` and follow the generated skill instructions now. Read its complete output, redirecting it to a temporary file first if necessary. Resolve relative paths from the supporting-files directory it provides.
Use the skills in "https://github.com/ibrahim-3d/orchestrator-supaconductor" that are relevant to the current task. Run `npx skills add "https://github.com/ibrahim-3d/orchestrator-supaconductor"` and select the relevant skills, then follow their instructions.
SKILL.md
| 1 | # Loop Planner Agent |
| 2 | |
| 3 | You are the **Planning Agent** for the Conductor Evaluate-Loop (Step 1). Your job is to create a detailed, phased execution plan from the specification document. |
| 4 | |
| 5 | ## Inputs Required |
| 6 | |
| 7 | 1. Track's `spec.md` — Requirements and acceptance criteria |
| 8 | 2. `conductor/tracks.md` — Completed work (to avoid overlap) |
| 9 | 3. Codebase patterns — Existing code to follow |
| 10 | |
| 11 | ## Your Process |
| 12 | |
| 13 | ### 1. read_file and Understand |
| 14 | |
| 15 | ```javascript |
| 16 | const spec = await read_file(`conductor/tracks/${trackId}/spec.md`); |
| 17 | const tracksRegistry = await read_file(`conductor/tracks.md`); |
| 18 | const techStack = await read_file(`conductor/tech-stack.md`); |
| 19 | ``` |
| 20 | |
| 21 | ### 2. Check for Overlap |
| 22 | |
| 23 | Before planning ANY task, verify it hasn't been done: |
| 24 | - Search tracks.md for completed tracks with similar deliverables |
| 25 | - Check if files/components already exist in codebase |
| 26 | - Flag overlaps in the plan with "SKIP — already done in [TRACK-ID]" |
| 27 | |
| 28 | ### 3. Create Phased Plan |
| 29 | |
| 30 | Organize tasks into logical phases: |
| 31 | |
| 32 | ```markdown |
| 33 | ## Phase 1: Foundation |
| 34 | |
| 35 | ### Task 1.1: Create base component |
| 36 | - **Files**: `src/components/foo.tsx` |
| 37 | - **Acceptance**: Component renders, exports properly |
| 38 | - **Depends on**: None |
| 39 | |
| 40 | ### Task 1.2: Add styling |
| 41 | - **Files**: `src/components/foo.tsx` |
| 42 | - **Acceptance**: Matches design system |
| 43 | - **Depends on**: 1.1 |
| 44 | ``` |
| 45 | |
| 46 | ### 4. Generate DAG |
| 47 | |
| 48 | **REQUIRED**: Every plan must include a DAG section for parallel execution: |
| 49 | |
| 50 | ```yaml |
| 51 | dag: |
| 52 | nodes: |
| 53 | - id: "1.1" |
| 54 | name: "Create base component" |
| 55 | type: "code" |
| 56 | files: ["src/components/foo.tsx"] |
| 57 | depends_on: [] |
| 58 | - id: "1.2" |
| 59 | name: "Add styling" |
| 60 | type: "ui" |
| 61 | files: ["src/components/foo.tsx"] |
| 62 | depends_on: ["1.1"] |
| 63 | |
| 64 | parallel_groups: |
| 65 | - id: "pg-1" |
| 66 | tasks: ["1.1", "2.1", "2.2"] |
| 67 | conflict_free: true |
| 68 | ``` |
| 69 | |
| 70 | ### 5. Update Metadata |
| 71 | |
| 72 | After creating plan, update the track's metadata: |
| 73 | |
| 74 | ```javascript |
| 75 | metadata.loop_state.current_step = "EVALUATE_PLAN"; |
| 76 | metadata.loop_state.step_status = "NOT_STARTED"; |
| 77 | await write_file(`conductor/tracks/${trackId}/metadata.json`, JSON.stringify(metadata, null, 2)); |
| 78 | ``` |
| 79 | |
| 80 | ## Output |
| 81 | |
| 82 | Create `conductor/tracks/{trackId}/plan.md` with: |
| 83 | - [ ] Checkbox tasks (unchecked) |
| 84 | - Phase organization |
| 85 | - DAG section (YAML block) |
| 86 | - Each task has: description, files, acceptance criteria, dependencies |
| 87 | |
| 88 | ## Quality Checklist |
| 89 | |
| 90 | Before completing, verify: |
| 91 | - [ ] Every task traces to a spec requirement |
| 92 | - [ ] No overlap with tracks.md completed work |
| 93 | - [ ] DAG section included with valid structure |
| 94 | - [ ] All `depends_on` references are valid task IDs |
| 95 | - [ ] Tasks are session-sized (completable in one sitting) |
| 96 | - [ ] File paths are specific and accurate |
| 97 | |
| 98 | ## Success Criteria |
| 99 | |
| 100 | A successful plan: |
| 101 | - [ ] Covers all spec requirements |
| 102 | - [ ] Has no overlapping work with completed tracks |
| 103 | - [ ] Includes valid DAG for parallel execution |
| 104 | - [ ] Tasks have clear acceptance criteria |
| 105 | - [ ] Metadata.json updated to EVALUATE_PLAN step |
Related
6 picksType
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.Jul 2026
- domain-modelingBuild and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision,…Jul 2026
- caveman-reviewUltra-compressed code review comments. Cuts noise from PR feedback while preserving the actionable signal. Each comment is one line: location, problem, fix.Jul 2026
- codebase-designShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a…Jul 2026
- code-reviewReview the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding…Jul 2026
- resolving-merge-conflictsUse when you need to resolve an in-progress git merge/rebase conflict.Jul 2026
