Back to skills
SkillHub ClubResearch & OpsFull Stack

loop-planner

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).

Packaged view

This page reorganizes the original catalog entry around fit, installability, and workflow context first. The original raw source lives below.

Stars
281
Hot score
99
Updated
March 20, 2026
Overall rating
C3.3
Composite score
3.3
Best-practice grade
B81.2

Install command

npx @skill-hub/cli install ibrahim-3d-conductor-orchestrator-superpowers-loop-planner

Repository

Ibrahim-3d/conductor-orchestrator-superpowers

Skill path: skills/loop-planner

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).

Open repository

Best for

Primary workflow: Research & Ops.

Technical facets: Full Stack.

Target audience: everyone.

License: Unknown.

Original source

Catalog source: SkillHub Club.

Repository owner: Ibrahim-3d.

This is still a mirrored public skill entry. Review the repository before installing into production workflows.

What it helps with

  • Install loop-planner into Claude Code, Codex CLI, Gemini CLI, or OpenCode workflows
  • Review https://github.com/Ibrahim-3d/conductor-orchestrator-superpowers before adding loop-planner to shared team environments
  • Use loop-planner for development workflows

Works across

Claude CodeCodex CLIGemini CLIOpenCode

Favorites: 0.

Sub-skills: 0.

Aggregator: No.

Original source / Raw SKILL.md

---
name: loop-planner
description: "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)."
---

# Loop Planner Agent — Step 1: PLAN

Creates detailed, scoped execution plans for tracks. This is Step 1 of the Evaluate-Loop.

## Inputs Required

1. Track `spec.md` — what needs to be built
2. `conductor/tracks.md` — what's already been done (to avoid overlap)
3. Track `plan.md` (if exists) — check for prior progress

## Workflow

### 1. Load Context

read_file in order:
1. `conductor/tracks.md` — completed tracks and their deliverables
2. Track's `spec.md` — requirements for this track
3. Track's `plan.md` (if exists) — check what's already `[x]` done
4. `conductor/product.md` — product scope reference
5. `conductor/tech-stack.md` — technical constraints

### 2. Identify Scope Boundaries

Before writing any plan:
- List what `spec.md` asks 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):

```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 -->
```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] <!-- 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 -->
```

### 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 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.3 Parallel Group Identification

Tasks can run in parallel if:
1. No dependency relationship (neither depends on the other)
2. At the same topological level
3. Either:
   - No shared files (conflict_free: true)
   - Shared files with coordination strategy (conflict_free: false)

### 4. 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? |

### 5. 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
```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"
      }
    }
  }
}
```

### On Completion
```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"
      }
    }
  }
}
```

### Update Protocol
1. read_file current `metadata.json`
2. Update `loop_state.checkpoints.PLAN` fields
3. Advance `current_step` to `EVALUATE_PLAN`
4. 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.

loop-planner | SkillHub