loop-planner
Loop Planner Agent — Step 1: PLAN
Creates detailed, scoped execution plans for tracks. This is Step 1 of the Evaluate-Loop.
Inputs Required
- Track
spec.md— what needs to be built conductor/tracks.md— what's already been done (to avoid overlap)- Track
plan.md(if exists) — check for prior progress
Workflow
1. Load Context
read_file in order:
conductor/tracks.md— completed tracks and their deliverables- Track's
spec.md— requirements for this track - Track's
plan.md(if exists) — check what's already[x]done conductor/product.md— product scope referenceconductor/tech-stack.md— technical constraints
2. Identify Scope Boundaries
Before writing any plan:
- List what
spec.mdasks for (deliverables) - List what's already done in other tracks (from
tracks.md) - Identify overlap — anything in spec that was already delivered elsewhere
- Flag overlap items as "SKIP — already done in [TRACK-ID]"
3. Create Phased Plan with DAG
write_file plan.md with this structure (now includes dependency DAG for parallel execution):
# [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 -->
```yaml
dag:
nodes:
- id: "1.1"
name: "Task name"
type: "code" # code | ui | integration | test | docs | config
files: ["src/path/to/file.ts"]
depends_on: []
estimated_duration: "30m"
phase: 1
- id: "1.2"
name: "Another task"
type: "code"
files: ["src/another/file.ts"]
depends_on: []
phase: 1
- id: "1.3"
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:
- id: "pg-1"
tasks: ["1.1", "1.2"]
conflict_free: true
- id: "pg-2"
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]
- Type: code
- Acceptance: [How to verify this is done]
- Files: [Expected files to create/modify]
- Task 1.2: [Specific action]
- Type: code
- Acceptance: [How to verify]
- Files: [Expected files]
- Task 1.3: [Depends on above]
- Type: code
- Acceptance: [How to verify]
- Files: [Expected files]
Phase 2: [Phase Name]
...
Discovered Work
### 3.1 DAG Generation Algorithm
When creating the plan, build the dependency graph:
```python
def 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
}
3.2 Bite-Sized Task Format
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:
### 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**
```typescript
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**
```typescript
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**
```bash
git add tests/path/test.ts src/path/file.ts
git commit -m "feat: add specific feature"
```
Key rules:
- Exact file paths always — no "add to the appropriate file"
- Complete code in plan — not "add validation" or "implement logic"
- Exact commands with expected output
- DRY, YAGNI, TDD, frequent commits
3.3 Task Type Detection
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 |
3.4 Parallel Group Identification
Tasks can run in parallel if:
- No dependency relationship (neither depends on the other)
- At the same topological level
- Either:
- No shared files (conflict_free: true)
- Shared files with coordination strategy (conflict_free: false)
3.5 Plan Quality Checklist
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? |
4. Output
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-evaluator
Metadata Checkpoint Updates
The planner MUST update the track's metadata.json at key points:
On Start
{
"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"
}
}
}
}
On Completion
{
"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"
}
}
}
}
Update Protocol
- read_file current
metadata.json - Update
loop_state.checkpoints.PLANfields - Advance
current_steptoEVALUATE_PLAN - write_file back to
metadata.json
If metadata.json doesn't exist or is v1 format, create v2 structure with default values.
Handoff
After creating the plan, the Conductor should dispatch the loop-plan-evaluator agent to verify the plan before execution begins.
More from ibrahim-3d/conductor-orchestrator-superpowers
board-of-directors
Simulate a 5-member expert board deliberation for major decisions. Use when evaluating plans, architecture choices, feature designs, or any decision requiring multi-perspective expert analysis. Triggers: 'board review', 'get expert opinions', 'board meeting', 'director evaluation', 'consensus review'.
9conductor-orchestrator
Master coordinator for the Evaluate-Loop workflow v3. Supports GOAL-DRIVEN entry, PARALLEL execution via worker agents, BOARD OF DIRECTORS deliberation, and message bus coordination. Dispatches specialized workers dynamically, monitors via message bus, aggregates results. Uses metadata.json v3 for parallel state tracking. Use when: '/go <goal>', '/conductor implement', 'start track', 'run the loop', 'orchestrate', 'automate track'.
8eval-business-logic
Specialized business logic evaluator for the Evaluate-Loop. Use this for evaluating tracks that implement core product logic — pipelines, dependency resolution, state machines, pricing/tier enforcement, packaging. Checks feature correctness against product rules, edge cases, state transitions, data flow, and user journey completeness. Dispatched by loop-execution-evaluator when track type is 'business-logic', 'generator', or 'core-feature'. Triggered by: 'evaluate logic', 'test business rules', 'verify business rules', 'check feature'.
8executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
7eval-integration
Specialized integration evaluator for the Evaluate-Loop. Use this for evaluating tracks that integrate external services — Supabase auth/DB, Stripe payments, Gemini API, third-party APIs. Checks API contracts, auth flows, data persistence, error recovery, environment config, and end-to-end flow integrity. Dispatched by loop-execution-evaluator when track type is 'integration', 'auth', 'payments', or 'api'. Triggered by: 'evaluate integration', 'test auth flow', 'check API', 'verify payments'.
7agent-factory
Creates specialized worker agents dynamically from templates. Use when orchestrator needs to spawn task-specific workers for parallel execution. Handles agent lifecycle: create -> execute -> cleanup.
7