npx claudepluginhub ibrahim-3d/conductor-orchestrator-superpowersWant just this skill?
Then install: npx claudepluginhub u/[userId]/[slug]
Manage Conductor tracks, phases, and tasks. Use when working with track status, updating task markers, or navigating between tracks. Enforces the Evaluate-Loop workflow.
This skill uses the workspace's default tool permissions.
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:
- ALWAYS update
plan.mdafter completing any task (prevents duplicate work across sessions) - ALWAYS evaluate before marking anything complete
- 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_state
Metadata 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": 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):
- read_file current metadata fields
- Infer loop state from plan.md content
- Add v2 structure with inferred values
- 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
- read_file
tracks.mdto see what's already complete - read_file the track's
plan.mdto see what tasks are done vs pending - read_file
spec.mdto understand requirements - 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
- All tasks in phase must be
[x]before moving to next phase - Run post-execution evaluation (see Evaluate-Loop in
conductor/workflow.md) - If evaluation fails → create fix tasks → execute → re-evaluate (loop)
- If evaluation passes → update
metadata.jsonwith completion timestamp - Create commit for phase completion
- Update
tracks.mdprogress column - Update
conductor/index.mdcurrent 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**: [PASS / FAIL - describe issues]
**Next**: [next task description]
Similar Skills
Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.