Agent skill

Conductor Orchestrator

by Ibrahim-3d in Ibrahim-3d/orchestrator-supaconductor

Master coordinator for the Evaluate-Loop workflow v3. An agent skill from Ibrahim-3d/orchestrator-supaconductor.

AGPL-3.0Auto-check passedAgent Workflows

Install Conductor Orchestrator

skills CLI
$ npx skills add Ibrahim-3d/orchestrator-supaconductor --skill conductor-orchestrator -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install Ibrahim-3d/orchestrator-supaconductor conductor-orchestrator --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/Ibrahim-3d/orchestrator-supaconductor.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/conductor-orchestrator .claude/skills/conductor-orchestrator && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
conductor-orchestrator
GitHub stars
381
Token cost
~12k tokens
SKILL.md length
1,368 words
Files
1
Skills in repo
27
Repo updated
First seen
Licence
AGPL-3.0

At a glance

Master coordinator for the Evaluate-Loop workflow v3. An agent skill from Ibrahim-3d/orchestrator-supaconductor.

  • Works in 5 steps: Metadata-based state detection — Reads… → Lead Engineer consultation — Consults… → Resumption support — Exact state… → …
  • /conductor implement
  • SKILL.md covers Mode Configuration Protocol, Goal-Driven Entry (/go), Key Changes in v3 and State Detection (New v2…, plus 4 more sections
  • Calls go and claude

What it does

Conductor Orchestrator is an agent skill from Ibrahim-3d/orchestrator-supaconductor. 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'.

Its SKILL.md is about 12k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows, covering Multi-agent orchestration. The repository describes itself as: Multi-agent orchestration system for Claude Code with parallel execution, automated quality gates, Board of Directors, and bundled Superpowers skills. The licence is AGPL-3.0.

When your agent uses it

  • /conductor implement
  • Tasks that involve Multi-agent orchestration

Example prompts

  • “/go <goal”
  • “/conductor implement”
  • “start track”
  • “/conductor-orchestrator”

Workflow steps

5 steps, taken from the first numbered list in SKILL.md.

  1. Metadata-based state detection — Reads loop_state.current_step from metadata.json
  2. Lead Engineer consultation — Consults specialized leads for decisions
  3. Resumption support — Exact state recovery if interrupted
  4. Explicit checkpoints — Each step writes state to metadata.json
  5. Learning Layer — Knowledge Manager + Retrospective Agent

What it can do on your machine

Read from SKILL.md and the folder at commit 76c9b10. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • go
    • claude

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Conductor Orchestrator loads about 12k tokens when it runs. Until then it costs about 115 tokens; SKILL.md has 1,368 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~115
When it runs · the whole SKILL.md, loaded when a task matches
~12k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from Ibrahim-3d/orchestrator-supaconductor at commit 76c9b10, republished under its AGPL-3.0 licence (© Ibrahim-3d). 1,368 words, ~12,319 tokens.

Download SKILL.mdSave it as .claude/skills/conductor-orchestrator/SKILL.md (or your agent's skills folder).
name
conductor-orchestrator
description
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'.

Conductor Orchestrator — Parallel Multi-Agent Coordinator (v3)

The master coordinator that runs the Evaluate-Loop for any track. Version 3 adds goal-driven entry, parallel execution via worker agents, Board of Directors deliberation, and message bus coordination.


Mode Configuration Protocol

FIRST ACTION: Read conductor/config.json to determine operating mode.

typescript
const config = await readJSON('conductor/config.json').catch(() => ({ mode: 'agentic' }));
const MODE = config.mode; // "agentic" | "human-in-the-loop"
const MAX_FIX_CYCLES = config.max_fix_cycles || 5;
ModeBehavior
"agentic"Fully autonomous. Resolve all decisions via leads, board, or best-judgment. Never ask user.
"human-in-the-loop"Pause at key decision points. Ask user for ambiguity, blockers, fix limits, HIGH_IMPACT decisions.

All decision points below check MODE before acting. If config.json doesn't exist, default to "agentic".


Goal-Driven Entry (/go)

The simplest entry point. User states their goal, the system handles everything.

Usage
bash
/go Add Stripe payment integration
/go Fix the login bug
/go Build an admin dashboard
Goal Processing Flow
typescript
async function processGoal(userGoal: string) {
  // 1. GOAL ANALYSIS
  const analysis = await analyzeGoal(userGoal);
  /*
    Returns:
    - intent: "feature" | "bugfix" | "refactor" | "research"
    - keywords: ["stripe", "payment", "checkout"]
    - complexity: "minor" | "moderate" | "major"
    - technical: boolean
  */

  // 2. CHECK EXISTING TRACKS
  const existingTrack = await findMatchingTrack(analysis.keywords);

  if (existingTrack) {
    // Resume existing track
    console.log(`Found existing track: ${existingTrack.id}`);
    return resumeOrchestration(existingTrack.id);
  }

  // 3. CREATE NEW TRACK
  const trackId = await createTrackFromGoal(userGoal, analysis);
  /*
    Creates:
    - conductor/tracks/{trackId}/
    - conductor/tracks/{trackId}/spec.md (generated from goal)
    - conductor/tracks/{trackId}/metadata.json (v3)
  */

  // 4. RUN FULL LOOP
  return runOrchestrationLoop(trackId);
}
Goal Analysis
typescript
async function analyzeGoal(goal: string) {
  // Use context-explorer to understand codebase
  const codebaseContext = await Task({
    subagent_type: "Explore",
    description: "Understand codebase for goal",
    prompt: `Analyze codebase to understand context for: "${goal}"

      Return:
      1. Related files/components
      2. Existing patterns to follow
      3. Dependencies needed
      4. Potential conflicts with existing code`
  });

  // Classify goal
  const intent = classifyIntent(goal);
  const keywords = extractKeywords(goal);
  const complexity = estimateComplexity(goal, codebaseContext);
  const technical = isTechnicalGoal(goal);

  return { intent, keywords, complexity, technical, codebaseContext };
}

function classifyIntent(goal: string): string {
  const lowerGoal = goal.toLowerCase();

  if (lowerGoal.match(/fix|bug|error|broken|crash|issue/)) return "bugfix";
  if (lowerGoal.match(/refactor|clean|optimize|improve|simplify/)) return "refactor";
  if (lowerGoal.match(/research|investigate|analyze|understand/)) return "research";
  return "feature";
}
Track Matching
typescript
async function findMatchingTrack(keywords: string[]): Track | null {
  const tracks = await readTracksFile();

  // Check in-progress tracks first
  const inProgress = tracks.filter(t =>
    t.status === 'IN_PROGRESS' || t.status === 'in_progress'
  );

  for (const track of inProgress) {
    const trackKeywords = extractKeywords(track.name + ' ' + track.description);
    const overlap = keywords.filter(k => trackKeywords.includes(k));

    if (overlap.length >= 2) {
      return track; // Good match
    }
  }

  // Check planned tracks
  const planned = tracks.filter(t =>
    t.status === 'NOT_STARTED' || t.status === 'planned'
  );

  for (const track of planned) {
    const trackKeywords = extractKeywords(track.name + ' ' + track.description);
    const overlap = keywords.filter(k => trackKeywords.includes(k));

    if (overlap.length >= 2) {
      return track;
    }
  }

  return null; // No match, create new track
}
Spec Generation from Goal
typescript
async function generateSpecFromGoal(goal: string, analysis: GoalAnalysis): string {
  const spec = await Task({
    subagent_type: "Plan",
    description: "Generate spec from goal",
    prompt: `Generate a specification document for this goal:

      GOAL: "${goal}"

      CODEBASE CONTEXT:
      ${analysis.codebaseContext}

      Create spec.md with:
      1. Overview - what we're building/fixing
      2. Requirements - specific deliverables
      3. Acceptance Criteria - how to verify it works
      4. Dependencies - what this needs
      5. Out of Scope - what we're NOT doing

      Be specific and actionable. Use the codebase context to identify:
      - Existing patterns to follow
      - Files that will be modified
      - Tests that need to pass

      Format as markdown.`
  });

  return spec.output;
}
Goal Resolution (Mode-Dependent)
typescript
// If goal is ambiguous, check mode
if (analysis.ambiguous) {
  if (MODE === 'human-in-the-loop') {
    // HUMAN MODE: Ask user to pick interpretation
    return ask_user({
      questions: [{
        question: "I need clarification on your goal. Which do you mean?",
        header: "Clarify",
        options: analysis.interpretations.map(i => ({
          label: i.summary, description: i.detail
        })),
        multiSelect: false
      }]
    });
  }
  // AGENTIC MODE: Resolve autonomously — NEVER ask the user
  // Spawn a Plan subagent to pick the best interpretation
  const resolution = await Task({
    subagent_type: "Plan",
    description: "Resolve ambiguous goal",
    prompt: `The user's goal "${userGoal}" has multiple interpretations:
      ${analysis.interpretations.map(i => `- ${i.summary}: ${i.detail}`).join('\n')}

      Analyze the codebase context and pick the BEST interpretation.
      Consider: existing code patterns, project structure, recent git history.
      Return JSON: {"chosen": "<interpretation summary>", "reasoning": "<why>"}`
  });
  // Use the resolved interpretation and continue
  analysis = { ...analysis, ambiguous: false, resolvedGoal: resolution.chosen };
}

// If multiple tracks match, check mode
if (matchingTracks.length > 1) {
  if (MODE === 'human-in-the-loop') {
    // HUMAN MODE: Ask user which track
    return ask_user({
      questions: [{
        question: "This goal matches multiple existing tracks. Which one?",
        header: "Track",
        options: matchingTracks.map(t => ({
          label: t.name, description: `Status: ${t.status}`
        })),
        multiSelect: false
      }]
    });
  }
  // AGENTIC MODE: Pick the most relevant one — NEVER ask the user
  // Pick the track with the highest keyword overlap and most recent activity
  const bestMatch = matchingTracks.sort((a, b) => {
    const aOverlap = keywords.filter(k => a.name.toLowerCase().includes(k)).length;
    const bOverlap = keywords.filter(k => b.name.toLowerCase().includes(k)).length;
    if (bOverlap !== aOverlap) return bOverlap - aOverlap;
    return new Date(b.updated_at) - new Date(a.updated_at); // Most recent
  })[0];
  console.log(`Auto-selected track: ${bestMatch.id} (best keyword match)`);
  return resumeOrchestration(bestMatch.id);
}

Key Changes in v3

From v2
  1. Metadata-based state detection — Reads loop_state.current_step from metadata.json
  2. Lead Engineer consultation — Consults specialized leads for decisions
  3. Resumption support — Exact state recovery if interrupted
  4. Explicit checkpoints — Each step writes state to metadata.json
  5. Learning Layer — Knowledge Manager + Retrospective Agent
New in v3
  1. Parallel Execution — Multiple workers execute DAG tasks simultaneously
  2. Board of Directors — 5-member expert deliberation at checkpoints
  3. Message Bus — Inter-agent coordination via file-based queue
  4. Worker Pool — Dynamic worker creation/cleanup via agent-factory
  5. DAG-Aware Planning — Plans include explicit dependency graphs
  6. Failure Isolation — One worker failure doesn't block independent tasks

State Detection (New v2 Protocol)

Primary: read_file metadata.json
typescript
async function detectCurrentStep(trackId: string) {
  const metadataPath = `conductor/tracks/${trackId}/metadata.json`;
  const metadata = await readJSON(metadataPath);

  // Migrate v1 to v2 if needed
  if (!metadata.version || metadata.version < 2) {
    metadata = await migrateToV2(trackId, metadata);
    await writeJSON(metadataPath, metadata);
  }

  const { current_step, step_status } = metadata.loop_state;

  return { current_step, step_status, metadata };
}
State Machine Logic (v3)
Current StepStep StatusNext Action
PLANNOT_STARTEDDispatch loop-planner (with DAG generation)
PLANIN_PROGRESSResume loop-planner
PLANPASSEDAdvance to EVALUATE_PLAN
EVALUATE_PLANNOT_STARTEDDispatch loop-plan-evaluator + DAG validation
EVALUATE_PLANBOARD_REVIEWInvoke Board (full or collapsed)
EVALUATE_PLANPASSEDAdvance to PARALLEL_EXECUTE
EVALUATE_PLANFAILEDIncrement plan_revision_count; if ≥ max (3) → completeWithWarnings; else back to PLAN
PARALLEL_EXECUTENOT_STARTEDNEW: Initialize message bus, dispatch parallel workers
PARALLEL_EXECUTEIN_PROGRESSMonitor workers via message bus
PARALLEL_EXECUTEPASSEDAdvance to EVALUATE_EXECUTION
PARALLEL_EXECUTEPARTIAL_FAILHandle failures, continue independent tasks
EVALUATE_EXECUTIONNOT_STARTEDDispatch evaluators + quick board review
EVALUATE_EXECUTIONPASSEDCheck business_sync_required → BUSINESS_SYNC or COMPLETE
EVALUATE_EXECUTIONFAILEDAdvance to FIX
FIXNOT_STARTEDCheck fix_cycle_count → dispatch loop-fixer or escalate
FIXIN_PROGRESSResume loop-fixer
FIXPASSEDGo back to EVALUATE_EXECUTION
BUSINESS_SYNCNOT_STARTEDDispatch business-docs-sync
BUSINESS_SYNCPASSEDAdvance to COMPLETE
COMPLETE—Run retrospective, cleanup workers, report success
AnyBLOCKEDLog blockers, skip blocked tasks, continue with unblocked work
AnyESCALATERoute to Board of Directors for autonomous resolution

Lead Engineer Consultation System

When to Consult Leads

Before escalating a decision to user, consult the appropriate Lead Engineer:

Question CategoryLead to ConsultSkill Path
Architecture, patterns, component organizationArchitecture Lead${CLAUDE_PLUGIN_ROOT}/skills/leads/architecture-lead/SKILL.md
Scope interpretation, requirements, copyProduct Lead${CLAUDE_PLUGIN_ROOT}/skills/leads/product-lead/SKILL.md
Implementation, dependencies, toolingTech Lead${CLAUDE_PLUGIN_ROOT}/skills/leads/tech-lead/SKILL.md
Testing, coverage, quality gatesQA Lead${CLAUDE_PLUGIN_ROOT}/skills/leads/qa-lead/SKILL.md
Consultation Flow
typescript
async function handleDecision(question: Question) {
  // 1. Check Authority Matrix
  const authority = lookupAuthority(question.category);

  // 2. HIGH_IMPACT decisions: check mode
  if (authority === 'HIGH_IMPACT') {
    if (MODE === 'human-in-the-loop') {
      return escalateToUser(question); // HUMAN MODE: ask user
    }
    return escalateToBoard(question); // AGENTIC MODE: board decides
  }

  // 3. LEAD_CONSULT decisions go to appropriate lead
  if (authority === 'LEAD_CONSULT') {
    const lead = getLeadForCategory(question.category);

    // Dispatch lead agent via Task tool
    const response = await Task({
      subagent_type: "general-purpose",
      description: `Consult ${lead} lead`,
      prompt: `You are the ${lead}-lead agent.

        Question: ${question.text}
        Context: ${question.context}

        Follow the ${lead}-lead skill instructions.

        Output your decision in JSON format:
        {
          "lead": "${lead}",
          "decision_made": true/false,
          "decision": "...",
          "reasoning": "...",
          "authority_used": "...",
          "escalate_to": null | "board" | "cto-advisor",
          "escalation_reason": "..."
        }`
    });

    const result = parseLeadResponse(response.output);

    // Log consultation to metadata
    await logConsultation(trackId, result);

    if (result.decision_made) {
      return result.decision;
    }

    // Lead escalated - route to Board of Directors for autonomous resolution (NEVER to user)
    return escalateToBoard({ question: question.text, context: result.escalation_reason });
  }

  // 4. ORCHESTRATOR decisions are made autonomously
  return makeAutonomousDecision(question);
}
Authority Matrix Reference

See conductor/authority-matrix.md for the complete decision matrix.

Quick Reference — High-Impact (Board Decides Autonomously):

  • Budget changes >$50/month → Board evaluates cost/benefit
  • Add/remove features from spec → Board assesses scope impact
  • Breaking API changes → Board reviews migration path
  • Dependencies >50KB → Board evaluates alternatives
  • Coverage below 70% → Board decides acceptable threshold
  • Security/production data changes → Board reviews risk

Quick Reference — Lead Can Decide:

  • Architecture: Patterns (existing), component org, schema (additive)
  • Product: Spec interpretation, copy, task order
  • Tech: Dependencies <50KB, implementation approach
  • QA: Coverage 70-90%, test types, mocks

Agent Dispatch Protocol

Dispatch with Metadata Updates

Each agent dispatch includes instructions to update metadata.json:

typescript
// Example: Dispatching executor with resumption
Task({
  subagent_type: "general-purpose",
  description: "Execute track tasks",
  prompt: `You are the loop-executor agent for track ${trackId}.

    METADATA STATE:
    - Current step: EXECUTE
    - Tasks completed: ${metadata.loop_state.checkpoints.EXECUTE.tasks_completed}
    - Last task: ${metadata.loop_state.checkpoints.EXECUTE.last_task}
    - Resume from: Next [ ] task after "${lastTask}"

    Your task:
    1. read_file conductor/tracks/${trackId}/plan.md
    2. Skip all [x] tasks - they are already done
    3. Find first [ ] task after "${lastTask}"
    4. Implement following loop-executor skill
    5. After EACH task completion:
       - Mark [x] in plan.md with commit SHA
       - Update metadata.json checkpoints.EXECUTE:
         - tasks_completed++
         - last_task = "Task X.Y"
         - last_commit = "sha"
    6. Continue until all tasks complete

    MANDATORY: Update metadata.json after every task for resumption support.`
})
Agent Roster (v3) — with Model Allocation

Use Opus for planning/strategy, Sonnet for execution/implementation. This saves tokens while maintaining quality.

StepAgentSkillModelRationale
PRE-PLANKnowledge Managerknowledge-managersonnetData retrieval
PLANPlannerloop-planneropusStrategic planning requires deep thinking
EVALUATE_PLANPlan Evaluatorloop-plan-evaluatoropusArchitectural judgment
EVALUATE_PLANBoardboard-of-directorsopusNuanced deliberation
PARALLEL_EXECUTEWorkersworker-templates/*sonnetProcedural code execution
EVALUATE_EXECUTIONExec Evaluatorloop-execution-evaluatorsonnetChecklist-based evaluation
FIXFixerloop-fixersonnetFollows evaluation report
BUSINESS_SYNCBiz Doc Syncbusiness-docs-syncsonnetDocument updates
POST-COMPLETERetrospectiveretrospective-agentsonnetPattern extraction

Parallel Execution Engine (v3)

When to Use Parallel Execution

Parallel execution is used when:

  • Plan contains dag: block with parallel_groups
  • DAG validation passed in EVALUATE_PLAN
  • Track has 3+ tasks that can run concurrently
PARALLEL_EXECUTE Step
typescript
async function stepParallelExecute(trackId: string, metadata: dict) {
  // 1. Initialize message bus
  const busPath = await initMessageBus(`conductor/tracks/${trackId}`);

  // 2. Parse DAG from plan.md
  const dag = await parseDagFromPlan(trackId);

  // 3. Import parallel dispatch utilities
  const { execute_parallel_phase } = require('parallel-dispatch');

  // 4. Execute all parallel groups
  const result = await execute_parallel_phase(dag, trackId, busPath, metadata);

  // 5. Update metadata with results
  metadata.loop_state.parallel_state = {
    total_workers_spawned: result.workers_spawned,
    completed_workers: result.all_tasks_completed.length,
    failed_workers: Object.keys(result.failed_tasks).length,
    parallel_groups_completed: result.parallel_groups_executed
  };

  // 6. Determine next step
  if (result.success) {
    return { next_step: 'EVALUATE_EXECUTION', status: 'PASSED' };
  } else if (result.escalate) {
    return { next_step: 'ESCALATE', reason: result.escalate_reason };
  } else {
    return { next_step: 'FIX', failures: result.failed_tasks };
  }
}
Worker Dispatch via Task Tool

Workers are dispatched using parallel Task calls:

typescript
// Dispatch 3 workers in parallel (single message, multiple tool calls)
await Promise.all([
  Task({
    subagent_type: "general-purpose",
    description: "Execute Task 1.1: Create store",
    prompt: workerPrompts["1.1"],
    run_in_background: true
  }),
  Task({
    subagent_type: "general-purpose",
    description: "Execute Task 1.2: Build resolver",
    prompt: workerPrompts["1.2"],
    run_in_background: true
  }),
  Task({
    subagent_type: "general-purpose",
    description: "Execute Task 1.3: Add validation",
    prompt: workerPrompts["1.3"],
    run_in_background: true
  })
]);
Worker Monitoring

Monitor workers via message bus polling:

typescript
async function monitorWorkers(busPath: string, taskIds: string[]) {
  const pending = new Set(taskIds);
  const completed = new Set();
  const failed = {};

  while (pending.size > 0) {
    // Check for completions
    for (const taskId of pending) {
      const eventFile = `${busPath}/events/TASK_COMPLETE_${taskId}.event`;
      if (await exists(eventFile)) {
        pending.delete(taskId);
        completed.add(taskId);
      }

      const failFile = `${busPath}/events/TASK_FAILED_${taskId}.event`;
      if (await exists(failFile)) {
        pending.delete(taskId);
        failed[taskId] = await getFailureReason(busPath, taskId);
      }
    }

    // Check for stale workers
    const stale = await checkStaleWorkers(busPath, thresholdMinutes=10);
    for (const worker of stale) {
      if (pending.has(worker.task_id)) {
        failed[worker.task_id] = `Stale: no heartbeat for ${worker.minutes_stale}m`;
        pending.delete(worker.task_id);
      }
    }

    await sleep(5000);
  }

  return { completed: [...completed], failed };
}

Board of Directors Integration (v3)

When to Invoke the Board

The full multi-agent Board (5 parallel Opus calls + discussion rounds) is reserved for genuinely high-stakes decisions. Routine evaluation uses a single structured Opus call ("collapsed board") that delivers comparable depth at ~1/10th the cost.

CheckpointConditionReview Type
EVALUATE_PLANProduction deploy, security architecture change, breaking API, data-loss migrationFull meeting (5 agents)
EVALUATE_PLANAll other tracksCollapsed board (1 Opus call)
EVALUATE_EXECUTIONboard_conditions exist from EVALUATE_PLANVerify conditions only
CONFLICTEvaluators disagree with no clear resolutionFull meeting (5 agents)
typescript
function isHighStakesTrack(metadata: dict, planContent: string): boolean {
  const highStakesSignals = [
    /production.deploy|prod\s+release/i,
    /security\s+architect|auth\s+overhaul|oauth\s+migration/i,
    /breaking\s+(api|change)|remove.*endpoint|rename.*field/i,
    /data.*migration|schema.*drop|column.*drop|irreversible/i,
  ];
  const combined = `${metadata.spec_summary || ''} ${planContent}`;
  return highStakesSignals.some(re => re.test(combined));
}
Invoking Board at EVALUATE_PLAN
typescript
async function evaluatePlanWithBoard(trackId: string, metadata: dict) {
  // 1. Run standard plan evaluation
  const evalResult = await dispatchPlanEvaluator(trackId);
  const planContent = await readFile(`conductor/tracks/${trackId}/plan.md`);

  // 2. Choose review type based on stakes
  let boardResult: dict;
  if (isHighStakesTrack(metadata, planContent)) {
    // Full multi-agent deliberation for genuinely high-stakes decisions
    boardResult = await invokeBoardMeeting(
      busPath: `conductor/tracks/${trackId}/.message-bus`,
      checkpoint: "EVALUATE_PLAN",
      proposal: planContent,
      context: { spec: metadata.spec_summary, dag: evalResult.dag }
    );
  } else {
    // Collapsed board: single structured Opus call (routine tracks)
    boardResult = await collapsedBoardEval(planContent, metadata.spec_summary);
  }

  // 3. Store session record
  metadata.loop_state.board_sessions = metadata.loop_state.board_sessions || [];
  metadata.loop_state.board_sessions.push({
    checkpoint: "EVALUATE_PLAN",
    review_type: isHighStakesTrack(metadata, planContent) ? "full" : "collapsed",
    verdict: boardResult.verdict,
    conditions: boardResult.conditions,
    timestamp: new Date().toISOString()
  });

  // 4. Handle verdict
  if (boardResult.verdict === "REJECTED") {
    return {
      next_step: "PLAN",
      status: "FAILED",
      reason: "Board rejected plan",
      conditions: boardResult.conditions
    };
  }

  // Carry forward conditions for EVALUATE_EXECUTION
  metadata.board_conditions = boardResult.conditions;
  return { next_step: "PARALLEL_EXECUTE", status: "PASSED" };
}
Collapsed Board Evaluation (Single Opus Call)

For all non-high-stakes tracks, replace the 10+ Opus call board with one structured call:

typescript
async function collapsedBoardEval(planContent: string, specSummary: string): Promise<dict> {
  const result = await Task({
    subagent_type: "general-purpose",
    model: "opus",
    description: "Multi-lens plan evaluation",
    prompt: `Evaluate this implementation plan from 5 perspectives.
For each lens give: verdict (APPROVE/REJECT/CONCERN), score 1-10, up to 3 conditions.

SPEC: ${specSummary}

PLAN:
${planContent}

Lenses: technical_architecture | product_value | security_risk | operational_feasibility | ux_impact

Output strictly as JSON:
{
  "lenses": {
    "technical_architecture": {"verdict": "APPROVE|REJECT|CONCERN", "score": 0, "conditions": []},
    "product_value":          {"verdict": "APPROVE|REJECT|CONCERN", "score": 0, "conditions": []},
    "security_risk":          {"verdict": "APPROVE|REJECT|CONCERN", "score": 0, "conditions": []},
    "operational_feasibility":{"verdict": "APPROVE|REJECT|CONCERN", "score": 0, "conditions": []},
    "ux_impact":              {"verdict": "APPROVE|REJECT|CONCERN", "score": 0, "conditions": []}
  },
  "verdict": "APPROVED|REJECTED|CONDITIONS",
  "blocking_conditions": [],
  "advisory_conditions": []
}`
  });

  const parsed = JSON.parse(result.output);
  const rejectCount = Object.values(parsed.lenses).filter((l: any) => l.verdict === "REJECT").length;

  return {
    verdict: rejectCount >= 2 ? "REJECTED" : (parsed.blocking_conditions.length > 0 ? "CONDITIONS" : "APPROVED"),
    conditions: [...parsed.blocking_conditions, ...parsed.advisory_conditions]
  };
}
Board Condition Verification at EVALUATE_EXECUTION
typescript
async function evaluateExecutionWithBoard(trackId: string, metadata: dict) {
  // 1. Run specialized evaluators
  const evalResults = await dispatchSpecializedEvaluators(trackId);

  // 2. Verify board conditions from EVALUATE_PLAN (if any)
  if (metadata.board_conditions?.length > 0) {
    const conditionsMet = await verifyBoardConditions(
      metadata.board_conditions,
      evalResults
    );
    if (!conditionsMet.all_met) {
      return {
        next_step: "FIX",
        status: "FAILED",
        reason: `Board conditions not met: ${conditionsMet.unmet.join(", ")}`
      };
    }
  }

  return evalResults.all_passed
    ? { next_step: "BUSINESS_SYNC", status: "PASSED" }
    : { next_step: "FIX", status: "FAILED" };
}

V3 State Machine Diagram

                              TRACK START
                                   │
                                   ▼
                    ┌──────────────────────────┐
                    │    KNOWLEDGE MANAGER     │
                    │    (Load patterns)       │
                    └────────────┬─────────────┘
                                 │
                                 ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                              PLAN (with DAG)                                 │
│  loop-planner generates plan.md with explicit dependency graph              │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                    EVALUATE_PLAN + BOARD MEETING                             │
│                                                                              │
│  1. DAG Validation (cycles, conflicts)                                       │
│  2. Standard checks (scope, overlap, deps, quality)                          │
│  3. For MAJOR tracks → invoke /board-meeting                                │
│     ┌──────────────────────────────────────────────────────────────────┐    │
│     │  BOARD DELIBERATION                                               │    │
│     │  Phase 1: All 5 directors ASSESS in parallel                      │    │
│     │  Phase 2: Directors DISCUSS via message bus                       │    │
│     │  Phase 3: Directors VOTE                                          │    │
│     │  Phase 4: RESOLVE → APPROVED / REJECTED / CONDITIONS              │    │
│     └──────────────────────────────────────────────────────────────────┘    │
│                                                                              │
│  PASS → Continue   |   FAIL → Back to PLAN with conditions                  │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                         PARALLEL_EXECUTE                                     │
│                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐    │
│  │                        MESSAGE BUS                                   │    │
│  │  queue.jsonl | locks.json | worker-status.json | events/            │    │
│  └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
│  For each parallel_group in DAG:                                            │
│    1. agent-factory creates specialized workers                             │
│    2. Dispatch via parallel Task(run_in_background=true)                   │
│    3. Workers coordinate via message bus:                                    │
│       - FILE_LOCK / FILE_UNLOCK for shared files                           │
│       - PROGRESS updates every 5 min                                        │
│       - TASK_COMPLETE / TASK_FAILED when done                              │
│    4. Monitor for completion, handle failures                               │
│    5. Cleanup ephemeral workers                                              │
│                                                                              │
│  ┌──────┐ ┌──────┐ ┌──────┐                                                 │
│  │Worker│ │Worker│ │Worker│  (max 5 concurrent)                            │
│  │ 1.1  │ │ 1.2  │ │ 1.3  │                                                 │
│  └──┬───┘ └──┬───┘ └──┬───┘                                                 │
│     └────────┴────────┘                                                      │
│              │                                                               │
│  PASS → Continue   |   PARTIAL_FAIL → Isolate + Continue                    │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                                   ▼
┌─────────────────────────────────────────────────────────────────────────────┐
│                 EVALUATE_EXECUTION + BOARD REVIEW                            │
│                                                                              │
│  1. Specialized evaluators (UI, Code, Integration, Business)                │
│  2. Quick board review (no discussion)                                       │
│  3. Verify board conditions from EVALUATE_PLAN                              │
│                                                                              │
│  PASS → BUSINESS_SYNC? → COMPLETE                                           │
│  FAIL → FIX (with specific failures)                                        │
└──────────────────────────────────┬──────────────────────────────────────────┘
                                   │
                              ┌────┴────┐
                              │         │
                         PASS ▼    FAIL ▼
                    ┌──────────┐  ┌──────────┐
                    │BUSINESS  │  │   FIX    │
                    │  SYNC    │  │ (max 3x) │
                    └────┬─────┘  └────┬─────┘
                         │             │
                         ▼             │
                    ┌──────────┐       │
                    │ COMPLETE │◄──────┘
                    │          │   (after fix passes)
                    └────┬─────┘
                         │
                         ▼
                    ┌──────────────────────────┐
                    │   RETROSPECTIVE AGENT    │
                    │   + Cleanup workers      │
                    └──────────────────────────┘

Resumption Protocol

When orchestrator starts, it resumes from exact state:

typescript
async function resumeOrchestration(trackId: string) {
  const { current_step, step_status, metadata } = await detectCurrentStep(trackId);

  // Reconcile plan.md checkboxes with metadata before resuming EXECUTE
  if (current_step === 'PARALLEL_EXECUTE' || current_step === 'EXECUTE') {
    await reconcileProgress(trackId);
  }

  switch (step_status) {
    case 'NOT_STARTED':
      // Start the step fresh
      return dispatchAgent(current_step, metadata);

    case 'IN_PROGRESS':
      // Resume the step with checkpoint data
      const checkpoint = metadata.loop_state.checkpoints[current_step];
      return resumeAgent(current_step, checkpoint);

    case 'PASSED':
      // Move to next step
      const nextStep = getNextStep(current_step, 'PASS');
      await updateMetadata(trackId, { current_step: nextStep, step_status: 'NOT_STARTED' });
      return dispatchAgent(nextStep, metadata);

    case 'FAILED':
      // Handle based on which step failed
      if (current_step === 'EVALUATE_PLAN') {
        // Guard against infinite PLAN→EVALUATE_PLAN loops
        const revisionCount = (metadata.loop_state.plan_revision_count || 0) + 1;
        const maxRevisions = config.max_plan_revisions || 3;
        if (revisionCount >= maxRevisions) {
          await logAutonomousDecision(trackId, 'plan_revision_limit',
            `Plan revision limit (${maxRevisions}) reached — completing with warnings`);
          return completeWithWarnings(trackId);
        }
        await updateMetadata(trackId, {
          current_step: 'PLAN',
          step_status: 'NOT_STARTED',
          loop_state: {
            ...metadata.loop_state,
            plan_revision_count: revisionCount
          }
        });
        return dispatchAgent('PLAN', metadata);
      }
      if (current_step === 'EVALUATE_EXECUTION') {
        // Check fix cycle limit
        if (metadata.loop_state.fix_cycle_count >= 5) {
          // NEVER escalate to user — complete with warnings
          await logAutonomousDecision(trackId, 'fix_limit_reached', 'Completed with unresolved issues after 5 fix cycles');
          return completeWithWarnings(trackId);
        }
        await updateMetadata(trackId, {
          current_step: 'FIX',
          step_status: 'NOT_STARTED',
          fix_cycle_count: metadata.loop_state.fix_cycle_count + 1
        });
        return dispatchAgent('FIX', metadata);
      }

    case 'BLOCKED':
      // Check if blocker is resolved
      const activeBlockers = metadata.blockers.filter(b => b.status === 'ACTIVE');
      if (activeBlockers.length > 0) {
        // NEVER escalate to user — log blocker and skip blocked tasks
        await logAutonomousDecision(trackId, 'blocker_skipped', `Skipped blocked tasks: ${activeBlockers[0].description}`);
        await skipBlockedTasks(trackId, activeBlockers);
      }
      // Blocker resolved, continue
      await updateMetadata(trackId, { step_status: 'NOT_STARTED' });
      return dispatchAgent(current_step, metadata);
  }
}
Show full SKILL.md (549 more words)Show less
Resumption by Step
StepResumption DataAction
PLANcheckpoints.PLAN.plan_versionRe-run planner if revising
EXECUTEcheckpoints.EXECUTE.last_taskSkip completed tasks, continue from next
FIXcheckpoints.FIX.fixes_remainingContinue with remaining fixes

The Full Loop (Automated)

┌─────────────────────────────────────────────────────────────────┐
│                        ORCHESTRATOR                             │
│                                                                 │
│  1. read_file metadata.json → detect current_step + step_status      │
│  2. Dispatch appropriate agent via Task tool                    │
│  3. Agent updates metadata.json checkpoints                     │
│  4. Agent returns → orchestrator reads new state                │
│  5. Continue to next step or handle failure                     │
│  6. Loop until COMPLETE or escalation needed                    │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

PLAN ──► EVALUATE_PLAN ──► EXECUTE ──► EVALUATE_EXECUTION
  ▲            │                              │
  │        FAIL → back                   PASS → BUSINESS_SYNC? → COMPLETE
  │                                      FAIL → FIX
  │                                             │
  └─────────────────────────────────────────────┘
                    (after fix, re-evaluate)

Resolution Triggers (Mode-Dependent)

Behavior depends on conductor/config.json → mode:

  • "agentic": All situations resolved autonomously. Never stops.
  • "human-in-the-loop": Pauses at each trigger below and asks the user.
  1. Fix cycle limit (5 cycles) → Complete track with warnings, log unresolved issues
  2. Plan revision limit (3 revisions) → Complete track with warnings, log board conditions
  3. HIGH_IMPACT decision → Route to Board of Directors for autonomous deliberation
  4. Lead escalated → Lead returned escalate_to: "board" → route to Board of Directors
  5. Blocker detected → Log blocker, skip blocked tasks, continue with unblocked work
  6. Max iterations (50) → Complete track with warnings, log all progress
Progress Logging Format
json
{
  "autonomous_decisions": [
    {
      "timestamp": "...",
      "type": "fix_limit_reached|blocker_skipped|board_decided|ambiguity_resolved",
      "context": "What was happening",
      "decision": "What was decided",
      "reasoning": "Why this was chosen"
    }
  ]
}

Autonomous Resolution Utility Functions

These utility functions implement the autonomous resolution patterns. They operate on metadata.json:

logAutonomousDecision(trackId, type, reasoning)

Append a decision record to the autonomous_decisions array in metadata.json:

json
{
  "timestamp": "{ISO timestamp}",
  "type": "ambiguity_resolved|blocker_skipped|board_decided|fix_limit_reached|completed_with_warnings",
  "context": "{current_step at time of decision}",
  "decision": "{what was decided}",
  "reasoning": "{why this was chosen}"
}
escalateToBoard(question)

Dispatch a board meeting for autonomous resolution:

  1. Spawn: claude --print --model opus "/orchestrator-supaconductor:board-meeting {question}"
  2. Parse board verdict (APPROVED / REJECTED)
  3. If APPROVED → continue with board conditions as constraints
  4. If REJECTED → re-plan incorporating all board feedback
  5. Log board decision via logAutonomousDecision()
skipBlockedTasks(trackId, activeBlockers)

Skip blocked tasks and continue with unblocked work:

  1. Read plan.md and mark blocked tasks as [~] SKIPPED
  2. Add each blocker to metadata.json "blockers" array with description and timestamp
  3. Continue executing the next unblocked task in DAG order
completeWithWarnings(trackId)

Complete the track with warnings instead of blocking:

  1. Update metadata.json: current_step = "COMPLETE", step_status = "PASSED_WITH_WARNINGS"
  2. Add "warnings" array to metadata with unresolved issues
  3. Update tracks.md — mark track as "Done (with warnings)"
  4. Log via logAutonomousDecision("completed_with_warnings", ...)
  5. Output summary report listing all warnings
reconcileProgress(trackId)

Reconcile plan.md checkbox markers with metadata.json task count on resumption. plan.md is the ground truth — if the counts diverge, update metadata to match:

typescript
async function reconcileProgress(trackId: string) {
  const planPath = `conductor/tracks/${trackId}/plan.md`;
  const metaPath = `conductor/tracks/${trackId}/metadata.json`;
  const metadata = await readJSON(metaPath);

  const completedInMeta = metadata.loop_state.checkpoints?.EXECUTE?.tasks_completed || 0;
  const planMtime = await getFileMtime(planPath);
  const metaMtime = await getFileMtime(metaPath);

  // Skip reconciliation if metadata was written after plan.md (already in sync)
  if (metaMtime >= planMtime && completedInMeta > 0) {
    return;
  }

  const plan = await readFile(planPath);
  // Match both '- [x]' and '* [x]' (case-insensitive) to handle markdown variants
  const completedInPlan = (plan.match(/^[*-] \[[xX]\]/gm) || []).length;

  if (completedInPlan !== completedInMeta) {
    metadata.loop_state.checkpoints = metadata.loop_state.checkpoints || {};
    metadata.loop_state.checkpoints.EXECUTE = metadata.loop_state.checkpoints.EXECUTE || {};
    metadata.loop_state.checkpoints.EXECUTE.tasks_completed = completedInPlan;
    await writeJSON(metaPath, metadata);
    console.warn(`[reconcile] plan.md=${completedInPlan} vs metadata=${completedInMeta} — metadata updated`);
  }
}

Track Completion Protocol

When current_step reaches COMPLETE:

  1. Update metadata.json
json
{
  "status": "complete",
  "completed_at": "[timestamp]",
  "loop_state": {
    "current_step": "COMPLETE",
    "step_status": "PASSED"
  }
}
  1. Update tracks.md — Move track to "Done" table with date

  2. Update conductor/index.md — Update current status

  3. Commit — docs: complete [track-id] - evaluation passed

  4. Report to user

  5. Run Retrospective (after completion commit): Dispatch agent: "read_file conductor/tracks/{trackId}/plan.md and git log. Extract reusable patterns → append to conductor/knowledge/patterns.md Extract error fixes → append to conductor/knowledge/errors.json Create files if they don't exist."

markdown
## Track Complete

**Track**: [track-id]
**Phases**: [count] completed
**Tasks**: [count] completed
**Evaluation**: PASS — all checks passed
**Lead Consultations**: [count] decisions made autonomously
**Commits**: [list of key commits]

**Next track**: [suggest from tracks.md]

CTO Advisor Integration

For technical tracks, automatically include CTO review during EVALUATE_PLAN:

typescript
// Detect if track is technical
const technicalKeywords = [
  'architecture', 'system design', 'integration', 'API', 'database',
  'schema', 'migration', 'infrastructure', 'scalability', 'performance',
  'security', 'authentication', 'authorization', 'deployment'
];

const isTechnical = technicalKeywords.some(keyword =>
  spec.toLowerCase().includes(keyword) || plan.toLowerCase().includes(keyword)
);

if (isTechnical) {
  // Include CTO review in plan evaluation
  dispatchPrompt += `
    This is a TECHNICAL track. Your evaluation must include:
    1. Standard plan checks (scope, overlap, dependencies, clarity)
    2. CTO technical review using cto-plan-reviewer skill

    Both must PASS for plan evaluation to pass.`;
}

Learning Layer Integration

The orchestrator integrates the Knowledge Layer for continuous learning:

Pre-Planning: Knowledge Manager

BEFORE dispatching the planner, run Knowledge Manager to load relevant patterns. The brief is capped at 500 tokens (top-3 most relevant patterns) to prevent unbounded growth as the knowledge base accumulates:

typescript
async function dispatchPlannerWithKnowledge(trackId: string) {
  // 1. Run Knowledge Manager with bounded retrieval
  const knowledgeBrief = await Task({
    subagent_type: "general-purpose",
    description: "Load knowledge for track",
    prompt: `You are the knowledge-manager agent.

      Track: ${trackId}
      Spec: ${await readFile(`conductor/tracks/${trackId}/spec.md`)}

      1. Extract the top 5 keywords from the spec
      2. Score each pattern in conductor/knowledge/patterns.md by keyword overlap count
      3. Return ONLY the top 3 highest-scoring patterns (skip patterns with score 0)
      4. Score each entry in conductor/knowledge/errors.json by keyword overlap
      5. Return ONLY the top 3 highest-scoring errors (skip score-0 entries)
      6. Cap total output at 500 tokens — truncate lower-priority entries if needed

      Follow ${CLAUDE_PLUGIN_ROOT}/skills/knowledge/knowledge-manager/SKILL.md`
  });

  // 2. Dispatch planner WITH bounded knowledge brief
  await Task({
    subagent_type: "general-purpose",
    description: "Create track plan",
    prompt: `You are the loop-planner agent for track ${trackId}.

      ## KNOWLEDGE BRIEF (top-3 relevant patterns/errors, max 500 tokens)
      ${knowledgeBrief.output}

      ## YOUR TASK
      Create plan.md using the patterns above where applicable.
      Avoid the known errors listed.

      Follow ${CLAUDE_PLUGIN_ROOT}/skills/loop-planner/SKILL.md`
  });
}
Post-Completion: Retrospective Agent

AFTER a track reaches COMPLETE, run Retrospective Agent to extract learnings:

typescript
async function runPostCompletionRetrospective(trackId: string) {
  await Task({
    subagent_type: "general-purpose",
    description: "Run track retrospective",
    prompt: `You are the retrospective-agent.

      Track: ${trackId}

      1. read_file conductor/tracks/${trackId}/plan.md (all tasks and fix cycles)
      2. read_file conductor/tracks/${trackId}/metadata.json (fix counts, consultations)
      3. Analyze: What worked? What failed? What patterns emerged?
      4. Update conductor/knowledge/patterns.md with new reusable solutions
      5. Update conductor/knowledge/errors.json with new error patterns
      6. write_file retrospective to conductor/tracks/${trackId}/retrospective.md
      7. Propose skill improvements if workflow issues found

      Follow ${CLAUDE_PLUGIN_ROOT}/skills/knowledge/retrospective-agent/SKILL.md`
  });
}
Updated State Machine with Learning
                              TRACK START
                                   │
                                   ▼
                    ┌──────────────────────────┐
                    │    KNOWLEDGE MANAGER     │  ◄── NEW: Load patterns & errors
                    │    (Pre-planning intel)  │
                    └────────────┬─────────────┘
                                 │
                                 ▼
PLAN ──► EVALUATE_PLAN ──► EXECUTE ──► EVALUATE_EXECUTION
  ▲            │                              │
  │        FAIL → back                   PASS → BUSINESS_SYNC? → COMPLETE
  │                                      FAIL → FIX                  │
  │                                             │                    │
  └─────────────────────────────────────────────┘                    │
                                                                     ▼
                                                    ┌──────────────────────────┐
                                                    │   RETROSPECTIVE AGENT    │  ◄── NEW
                                                    │   (Extract learnings)    │
                                                    └────────────┬─────────────┘
                                                                 │
                                                                 ▼
                                                    ┌──────────────────────────┐
                                                    │    KNOWLEDGE BASE        │
                                                    │  patterns.md + errors.json│
                                                    └──────────────────────────┘
                                                                 │
                                                                 ▼
                                                          NEXT TRACK
                                                    (now smarter than before)
Knowledge Layer Files
FilePurposeUpdated By
conductor/knowledge/patterns.mdReusable solutionsRetrospective Agent
conductor/knowledge/errors.jsonError → Fix registryRetrospective Agent, Fixer
conductor/tracks/[id]/retrospective.mdTrack-specific learningsRetrospective Agent
Fixer Integration with Error Registry

The loop-fixer also uses the error registry:

typescript
// In loop-fixer, before attempting a fix
async function findKnownSolution(errorMessage: string) {
  const errors = JSON.parse(await readFile('conductor/knowledge/errors.json'));

  for (const error of errors.errors) {
    if (new RegExp(error.pattern, 'i').test(errorMessage)) {
      return {
        found: true,
        solution: error.solution,
        code_fix: error.code_fix
      };
    }
  }

  return { found: false };
}

// After fixing a new error, log it
async function logNewError(pattern, solution, trackId) {
  const errors = JSON.parse(await readFile('conductor/knowledge/errors.json'));
  errors.errors.push({
    id: `err-${String(errors.errors.length + 1).padStart(3, '0')}`,
    pattern,
    solution,
    discovered_in: trackId,
    last_seen: new Date().toISOString().split('T')[0]
  });
  await writeFile('conductor/knowledge/errors.json', JSON.stringify(errors, null, 2));
}

Quick Reference

Starting a Track
User: /conductor implement

Orchestrator:
1. read_file conductor/tracks.md → get active track
2. read_file conductor/tracks/[track]/metadata.json → get loop_state
3. Determine current step and status
4. Dispatch appropriate agent
5. Loop until complete
State Locations
DataLocationPurpose
Loop statemetadata.json → loop_statePrimary state machine
Task progressplan.md markersHuman-readable progress
Lead decisionsmetadata.json → lead_consultationsDecision audit trail
Blockersmetadata.json → blockersEscalation tracking
Authority rulesconductor/authority-matrix.mdDecision boundaries
Files Modified by Orchestrator
  • conductor/tracks/[track]/metadata.json — State updates
  • conductor/tracks.md — Completion tracking
  • conductor/index.md — Current status

© Ibrahim-3d, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/conductor-orchestrator of Ibrahim-3d/orchestrator-supaconductor.

Open the folder on GitHubat commit 76c9b10

Compare with similar skills

Conductor Orchestrator next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Conductor Orchestrator compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Conductor Orchestrator this skillIbrahim-3d/orchestrator-supaconductor381—~12kAutomated safety check: PassAGPL-3.0
Orca CLIstablyai/orca88k2 repos~593Automated safety check: PassMIT
Paseo Advisor Second Opiniongetpaseo/paseo20k1 repos~756Automated safety check: PassCustom licence
O2 Review Loopopenobserve/openobserve22k—~3.7kAutomated safety check: PassAGPL-3.0
Paseo Committeegetpaseo/paseo20k1 repos~496Automated safety check: PassCustom licence
Mission Control Agent APIbuilderz-labs/mission-control6.3k—~2.1kAutomated safety check: PassMIT

Similar skills

  • Orca CLI

    stablyai/orca

    Operate Orca-managed worktrees, folder contexts, terminals, repos, automations, artifacts, skill sharing, worktree comments, and Orca's embedded browser…

    88k GitHub starsUsed in 2 repos~593 tokens
    Agent WorkflowsAuto-check passed
  • Launches one separate agent through Paseo to give a second opinion on the current task, with a self-contained briefing and no permission to edit files.

    20k GitHub starsUsed in 1 repo~756 tokens
    Agent WorkflowsAuto-check passed
  • O2 Review Loop

    openobserve/openobserve

    Splits a change into planner, coder and independent reviewer roles: you confirm a spec, a subagent implements it, and a separate reviewer checks each round's local WIP commit.

    22k GitHub stars~3.7k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Paseo Committee

    getpaseo/paseo

    Forms a two-agent committee with contrasting profiles to analyze a stuck problem in parallel, reconcile their views and return a consensus plan without editing files.

    20k GitHub starsUsed in 1 repo~496 tokens
    Agent WorkflowsAuto-check passed
  • Mission Control Agent API

    builderz-labs/mission-control

    Teaches an agent to use the Mission Control dashboard API: register, send heartbeats, fetch assigned tasks, report progress and disconnect, with API key auth.

    6.3k GitHub stars~2.1k tokensUpdated 11 days ago
    Agent WorkflowsAuto-check passed
  • Paseo Agent Handoff

    getpaseo/paseo

    Hands off the current task, including context, decisions and failed attempts, to a fresh agent through Paseo by writing a self-contained briefing prompt and launching that agent.

    20k GitHub starsUsed in 1 repo~606 tokens
    Agent WorkflowsAuto-check passed

More from Ibrahim-3d/orchestrator-supaconductor

All 27 skills in this repo
  • Cto Advisor

    Ibrahim-3d/orchestrator-supaconductor

    Technical leadership guidance for engineering teams, architecture decisions, and technology strategy.

    381 GitHub starsUsed in 4 repos~2.4k tokens
    Auto-check passed
  • Context Driven Development

    Ibrahim-3d/orchestrator-supaconductor

    A skill your agent uses when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md…

    381 GitHub starsUsed in 9 repos~2.9k tokens
    Auto-check passed
  • Agent Factory

    Ibrahim-3d/orchestrator-supaconductor

    Creates specialized worker agents dynamically from templates.

    381 GitHub stars~2.9k tokensUpdated 12 days ago
    Auto-check passed
  • Board Of Directors

    Ibrahim-3d/orchestrator-supaconductor

    Simulate a 5-member expert board deliberation for major decisions.

    381 GitHub stars~1.9k tokensUpdated 12 days ago
    Auto-check passed
  • Business Docs Sync

    Ibrahim-3d/orchestrator-supaconductor

    A skill your agent uses when completing a track that changes pricing, AI models, product features, or asset pipelines — syncs business context documents across all tiers.

    381 GitHub stars~2.1k tokensUpdated 12 days ago
    Auto-check passed
  • Context Loader

    Ibrahim-3d/orchestrator-supaconductor

    Load project context efficiently for Conductor workflows. An agent skill from Ibrahim-3d/orchestrator-supaconductor.

    381 GitHub stars~830 tokensUpdated 12 days ago
    Auto-check passed

Categories

Questions about Conductor Orchestrator

What does Conductor Orchestrator do?

Master coordinator for the Evaluate-Loop workflow v3. An agent skill from Ibrahim-3d/orchestrator-supaconductor. Conductor Orchestrator is an agent skill from Ibrahim-3d/orchestrator-supaconductor. Master coordinator for the Evaluate-Loop workflow v3.

When should I use Conductor Orchestrator?

Conductor Orchestrator fits situations like: /conductor implement; tasks that involve Multi-agent orchestration.

How do I install Conductor Orchestrator in Claude Code?

Run `npx skills add Ibrahim-3d/orchestrator-supaconductor --skill conductor-orchestrator -a claude-code`. Or copy the skill folder (skills/conductor-orchestrator in Ibrahim-3d/orchestrator-supaconductor) into .claude/skills/conductor-orchestrator in your project. Claude Code loads it when a task matches its description.

How do I install Conductor Orchestrator in Codex?

Run `npx skills add Ibrahim-3d/orchestrator-supaconductor --skill conductor-orchestrator -a codex`. Or copy the skill folder (skills/conductor-orchestrator in Ibrahim-3d/orchestrator-supaconductor) into .agents/skills/conductor-orchestrator in your project. Codex loads it when a task matches its description.

Can I use Conductor Orchestrator in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add Ibrahim-3d/orchestrator-supaconductor --skill conductor-orchestrator -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/conductor-orchestrator, .gemini/skills/conductor-orchestrator, .github/skills/conductor-orchestrator and .opencode/skills/conductor-orchestrator in your project.

What does Conductor Orchestrator need to run?

Going by SKILL.md and its folder, Conductor Orchestrator needs the command-line tools its instructions call (go and claude).

Does Conductor Orchestrator access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Conductor Orchestrator safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Conductor Orchestrator use?

Conductor Orchestrator is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Conductor Orchestrator use?

About 12k tokens (SKILL.md is roughly 49k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Conductor Orchestrator?

Skills that share tags, products or a category with Conductor Orchestrator: Orca CLI (stablyai/orca, 88k stars), Paseo Advisor Second Opinion (getpaseo/paseo, 20k stars), O2 Review Loop (openobserve/openobserve, 22k stars) and Paseo Committee (getpaseo/paseo, 20k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Conductor Orchestrator?

Ibrahim-3d (a GitHub user) maintains it in Ibrahim-3d/orchestrator-supaconductor, which has 381 GitHub stars. The repository holds 27 skills in this directory. The repository was last updated on September 27, 2026.

Source: Ibrahim-3d/orchestrator-supaconductor on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.