Get the FREE Ultimate OpenClaw Setup Guide →

loop-planner

npx machina-cli add skill Ibrahim-3d/conductor-orchestrator-superpowers/loop-planner --openclaw
Files (1)
SKILL.md
8.0 KB

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

IndicatorsType
src/components/, .tsx, ui, componentui
api/, integration, supabase, stripeintegration
.test.ts, test, coveragetest
.md, docs, documentationdocs
config, .json, .envconfig
Defaultcode

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:

CheckQuestion
ScopedDoes every task trace back to a spec.md requirement?
No OverlapDoes any task duplicate work from completed tracks?
TestableDoes every task have clear acceptance criteria?
OrderedAre tasks sequenced by dependency?
SizedCan 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

{
  "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

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

Source

git clone https://github.com/Ibrahim-3d/conductor-orchestrator-superpowers/blob/master/skills/loop-planner/SKILL.mdView on GitHub

Overview

Loop Planner — Step 1: PLAN creates a detailed execution plan for a new track or feature. It reads spec.md and the project context, then outputs a phased plan.md containing specific tasks, acceptance criteria, and dependencies. This planning step is the initial phase of the Evaluate-Loop process and is triggered by commands like plan feature, create plan, start track, or /conductor implement.

How This Skill Works

Technically, the agent loads context in a defined order (conductor/tracks.md, spec.md, plan.md if present, conductor/product.md, conductor/tech-stack.md), identifies scope boundaries and possible overlaps, and then generates a phased plan with a dependency DAG. The output plan.md includes context, dependencies, overlap notes, and a Phase-based task list with parallel and sequential execution details.

When to Use It

  • Starting a new track or feature and needing a detailed, scoped execution plan
  • When spec.md defines deliverables that require explicit task breakdown and acceptance criteria
  • To identify overlaps with existing tracks and flag items already completed elsewhere
  • During the planning phase triggered by: plan feature, create plan, start track, or /conductor implement
  • When you need a DAG-based view of tasks and dependencies for parallel execution

Quick Start

  1. Step 1: Load spec.md, conductor/tracks.md, and product/tech constraints to establish context
  2. Step 2: Identify scope boundaries and overlaps, marking SKIP items where appropriate
  3. Step 3: Generate plan.md with phased tasks, acceptance criteria, and a YAML-based DAG for parallel execution

Best Practices

  • Always load and compare spec.md, conductor/tracks.md, and product/tech constraints before drafting the plan
  • Flag any overlap items as SKIP — already done in [TRACK-ID] to avoid rework
  • Define clear acceptance criteria for each task to simplify verification
  • Use the Dependency Graph (DAG) to identify safe parallelization and resource conflicts
  • Document dependencies and prerequisites so future phases can reference the plan with minimal contact

Example Use Cases

  • Plan a new feature launch by wiring tasks for UI, API, and tests with clear acceptance checks
  • Create a track plan for migrating a monolith module to microservices while noting overlap with existing tracks
  • Prepare a plan.md for a data pipeline rewrite, detailing data source integrations and validation tasks
  • Define a feature rollout plan with parallel tasks for frontend, backend, and docs
  • Draft planning artifacts for a security feature, including code, tests, and compliance documentation

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers