/track-manager
Manage Conductor tracks, phases, and tasks. Use when working with track status, updating task markers, or navigating between tracks. Enforces the Evaluate-Loop workflow.
$ npx -y skills add Ibrahim-3d/orchestrator-supaconductor --skill track-manager --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/track-manager
Context preview
The summary Claude sees to decide when to auto-load this skill.
Manage Conductor tracks, phases, and tasks. Use when working with track status, updating task markers, or navigating between tracks. Enforces the Evaluate-Loop workflow.
SKILL.md
track-manager.SKILL.mdname: track-manager
description: Manage Conductor tracks, phases, and tasks. Use when working with track status, updating task markers, or navigating between tracks. Enforces the Evaluate-Loop workflow.
Track Manager Skill
Manage the lifecycle of Conductor tracks including status updates, task completion, and phase transitions. All operations follow the **Evaluate-Loop** process defined in `conductor/workflow.md`.
MANDATORY: Evaluate-Loop Integration
Every track operation must follow the Evaluate-Loop:
PLAN → EVALUATE PLAN → EXECUTE → EVALUATE EXECUTION → COMPLETE/FIX
**Key rules:** 1. **ALWAYS update `plan.md`** after completing any task (prevents duplicate work across sessions) 2. **ALWAYS evaluate** before marking anything complete 3. **NEVER skip** the pre-execution plan evaluation
Trigger Conditions
Use this skill when:
- Checking track status or progress
- Marking tasks as complete
- Transitioning between phases
- Running pre/post execution evaluations
- User mentions: "track status", "mark complete", "next task", "update plan", "evaluate"
Track Structure
conductor/
├── tracks.md # Master track list
├── authority-matrix.md # Lead Engineer decision boundaries
├── schemas/
│ └── track-metadata.v2.json # Metadata schema definition
└── tracks/
└── <track_id>/
├── spec.md # Requirements
├── plan.md # Phased tasks (MUST be kept updated)
└── metadata.json # v2 status with loop_stateMetadata v2 Protocol
All tracks use the v2 metadata schema with explicit loop state tracking.
Creating a New Track
Initialize `metadata.json` with v2 structure:
{
"version": 2,
"track_id": "feature-name_20260131",
"type": "feature",
"status": "new",
"created_at": "2026-01-31T00:00:00Z",
"updated_at": "2026-01-31T00:00:00Z",
"loop_state": {
"current_step": "PLAN",
"step_status": "NOT_STARTED",
"fix_cycle_count": 0,
"max_fix_cycles": 5,
"plan_revision_count": 0,
"max_plan_revisions": 3,
"checkpoints": {
"PLAN": { "status": "NOT_STARTED" },
"EVALUATE_PLAN": { "status": "NOT_STARTED" },
"EXECUTE": { "status": "NOT_STARTED" },
"EVALUATE_EXECUTION": { "status": "NOT_STARTED" },
"FIX": { "status": "NOT_STARTED" },
"BUSINESS_SYNC": { "status": "NOT_STARTED", "required": false }
}
},
"lead_consultations": [],
"discovered_work": [],
"blockers": []
}Updating Loop State
When a step completes, update the checkpoint:
{
"loop_state": {
"current_step": "EXECUTE",
"step_status": "IN_PROGRESS",
"checkpoints": {
"PLAN": {
"status": "PASSED",
"completed_at": "2026-01-31T10:00:00Z",
"agent": "loop-planner"
},
"EVALUATE_PLAN": {
"status": "PASSED",
"completed_at": "2026-01-31T10:30:00Z",
"verdict": "PASS"
},
"EXECUTE": {
"status": "IN_PROGRESS",
"started_at": "2026-01-31T11:00:00Z",
"tasks_completed": 3,
"tasks_total": 10,
"last_task": "Task 1.3"
}
}
}
}Migrating v1 to v2
If a track has v1 metadata (no `version` field or `loop_state`):
1. read_file current metadata fields 2. Infer loop state from plan.md content 3. Add v2 structure with inferred values 4. write_file back to metadata.json
Task Status Markers
| Marker | Status | Description | | ------ | ----------- | --------------------- | | `[ ]` | Pending | Not started | | `[~]` | In Progress | Currently working | | `[x]` | Completed | Done (add commit SHA + summary) | | `[!]` | Blocked | Add note explaining why |
Workflow Operations
Before Starting ANY Work
1. read_file `tracks.md` to see what's already complete 2. read_file the track's `plan.md` to see what tasks are done vs pending 3. read_file `spec.md` to understand requirements 4. **Evaluate the plan** — verify scope matches spec, no overlap with completed tracks
Start a Task
# Before
- [ ] Implement user authentication
# After (mark in progress)
- [~] Implement user authentication
Complete a Task (MANDATORY: update plan.md immediately)
# After completion (add commit SHA + summary of what was done)
- [x] Implement user authentication <!-- abc1234 -->
- Created src/components/auth/signup-form.tsx
- Added email/password validation
- Integrated with mock API client
Update tracks.md
When completing a phase, update `conductor/tracks.md`:
## Active Tracks
| Track ID | Type | Status | Progress |
| -------- | ------- | ----------- | --------- |
| auth-001 | feature | in_progress | Phase 2/3 |
Phase Transition Rules
1. All tasks in phase must be `[x]` before moving to next phase 2. **Run post-execution evaluation** (see Evaluate-Loop in `conductor/workflow.md`) 3. If evaluation fails → create fix tasks → execute → re-evaluate (loop) 4. If evaluation passes → update `metadata.json` with completion timestamp 5. Create commit for phase completion 6. Update `tracks.md` progress column 7. Update `conductor/index.md` current status
Post-Execution Evaluation Checklist
Before marking a track complete, verify:
| Check | Question | |-------|----------| | **Deliverables** | Every deliverable in `spec.md` exists and is functional? | | **Alignment** | Implementation matches what was planned (no scope drift)? | | **No Regressions** | Build passes? No console errors? Existing features work? | | **Quality** | Usability check passes on all user-facing copy? | | **plan.md Updated** | All tasks marked `[x]` with summaries? | | **No Leftover** | No tasks skipped or left incomplete? |
Response Format
After track operations:
## Track Update
**Track**: [track_id]
**Operation**: [started/completed/updated/evaluated]
**Phase**: [phase number] - [phase name]
**Progress**: [completed]/[total] tasks
**Evaluation**:
Read more
name: track-manager description: Manage Conductor tracks, phases, and tasks. Use when working with track status, updating task markers, or navigating between tracks. Enforces the Evaluate-Loop workflow.
Track Manager Skill
Manage the lifecycle of Conductor tracks including status updates, task completion, and phase transitions. All operations follow the **Evaluate-Loop** process defined in `conductor/workflow.md`.
MANDATORY: Evaluate-Loop Integration
Every track operation must follow the Evaluate-Loop:
PLAN → EVALUATE PLAN → EXECUTE → EVALUATE EXECUTION → COMPLETE/FIX
**Key rules:** 1. **ALWAYS update `plan.md`** after completing any task (prevents duplicate work across sessions) 2. **ALWAYS evaluate** before marking anything complete 3. **NEVER skip** the pre-execution plan evaluation
Trigger Conditions
Use this skill when:
- Checking track status or progress
- Marking tasks as complete
- Transitioning between phases
- Running pre/post execution evaluations
- User mentions: "track status", "mark complete", "next task", "update plan", "evaluate"
Track Structure
conductor/
├── tracks.md # Master track list
├── authority-matrix.md # Lead Engineer decision boundaries
├── schemas/
│ └── track-metadata.v2.json # Metadata schema definition
└── tracks/
└── <track_id>/
├── spec.md # Requirements
├── plan.md # Phased tasks (MUST be kept updated)
└── metadata.json # v2 status with loop_stateMetadata v2 Protocol
All tracks use the v2 metadata schema with explicit loop state tracking.
Creating a New Track
Initialize `metadata.json` with v2 structure:
{
"version": 2,
"track_id": "feature-name_20260131",
"type": "feature",
"status": "new",
"created_at": "2026-01-31T00:00:00Z",
"updated_at": "2026-01-31T00:00:00Z",
"loop_state": {
"current_step": "PLAN",
"step_status": "NOT_STARTED",
"fix_cycle_count": 0,
"max_fix_cycles": 5,
"plan_revision_count": 0,
"max_plan_revisions": 3,
"checkpoints": {
"PLAN": { "status": "NOT_STARTED" },
"EVALUATE_PLAN": { "status": "NOT_STARTED" },
"EXECUTE": { "status": "NOT_STARTED" },
"EVALUATE_EXECUTION": { "status": "NOT_STARTED" },
"FIX": { "status": "NOT_STARTED" },
"BUSINESS_SYNC": { "status": "NOT_STARTED", "required": false }
}
},
"lead_consultations": [],
"discovered_work": [],
"blockers": []
}Updating Loop State
When a step completes, update the checkpoint:
{
"loop_state": {
"current_step": "EXECUTE",
"step_status": "IN_PROGRESS",
"checkpoints": {
"PLAN": {
"status": "PASSED",
"completed_at": "2026-01-31T10:00:00Z",
"agent": "loop-planner"
},
"EVALUATE_PLAN": {
"status": "PASSED",
"completed_at": "2026-01-31T10:30:00Z",
"verdict": "PASS"
},
"EXECUTE": {
"status": "IN_PROGRESS",
"started_at": "2026-01-31T11:00:00Z",
"tasks_completed": 3,
"tasks_total": 10,
"last_task": "Task 1.3"
}
}
}
}Migrating v1 to v2
If a track has v1 metadata (no `version` field or `loop_state`):
1. read_file current metadata fields 2. Infer loop state from plan.md content 3. Add v2 structure with inferred values 4. write_file back to metadata.json
Task Status Markers
| Marker | Status | Description | | ------ | ----------- | --------------------- | | `[ ]` | Pending | Not started | | `[~]` | In Progress | Currently working | | `[x]` | Completed | Done (add commit SHA + summary) | | `[!]` | Blocked | Add note explaining why |
Workflow Operations
Before Starting ANY Work
1. read_file `tracks.md` to see what's already complete 2. read_file the track's `plan.md` to see what tasks are done vs pending 3. read_file `spec.md` to understand requirements 4. **Evaluate the plan** — verify scope matches spec, no overlap with completed tracks
Start a Task
# Before - [ ] Implement user authentication # After (mark in progress) - [~] Implement user authentication
Complete a Task (MANDATORY: update plan.md immediately)
# After completion (add commit SHA + summary of what was done) - [x] Implement user authentication <!-- abc1234 --> - Created src/components/auth/signup-form.tsx - Added email/password validation - Integrated with mock API client
Update tracks.md
When completing a phase, update `conductor/tracks.md`:
## Active Tracks | Track ID | Type | Status | Progress | | -------- | ------- | ----------- | --------- | | auth-001 | feature | in_progress | Phase 2/3 |
Phase Transition Rules
1. All tasks in phase must be `[x]` before moving to next phase 2. **Run post-execution evaluation** (see Evaluate-Loop in `conductor/workflow.md`) 3. If evaluation fails → create fix tasks → execute → re-evaluate (loop) 4. If evaluation passes → update `metadata.json` with completion timestamp 5. Create commit for phase completion 6. Update `tracks.md` progress column 7. Update `conductor/index.md` current status
Post-Execution Evaluation Checklist
Before marking a track complete, verify:
| Check | Question | |-------|----------| | **Deliverables** | Every deliverable in `spec.md` exists and is functional? | | **Alignment** | Implementation matches what was planned (no scope drift)? | | **No Regressions** | Build passes? No console errors? Existing features work? | | **Quality** | Usability check passes on all user-facing copy? | | **plan.md Updated** | All tasks marked `[x]` with summaries? | | **No Leftover** | No tasks skipped or left incomplete? |
Response Format
After track operations:
## Track Update **Track**: [track_id] **Operation**: [started/completed/updated/evaluated] **Phase**: [phase number] - [phase name] **Progress**: [completed]/[total] tasks **Evaluation**:
Multi-agent orchestration system for Claude Code with parallel execution, automated quality gates, Board of Directors, and bundled Superpowers skills
Repo: Ibrahim-3d/orchestrator-supaconductor
Other skills on orchestrator-supaconductor.
- /agent-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.
Open skill - /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
Open skill - /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /business-docs-sync
Ensures all business strategy, pricing, and product documents stay synchronized when product decisions change during any track execution or evaluation.
Open skill - /conductor-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
Open skill - /context-driven-development
Use this skill when working with Conductor's context-driven development methodology, managing project context artifacts, or understanding the relationship between product.md, tech-stack.md, and workflow.md files.
Open skill

