$npx -y skills add gc-victor/supersimple --skill conductorMulti-phase delivery framework that MUST preserve session continuity and SHOULD support SHA-based rollback.
| 1 | # Conductor |
| 2 | |
| 3 | ## Core Responsibilities |
| 4 | |
| 5 | 1. Validate the Conductor environment and load the target track. |
| 6 | 2. Coordinate task execution across the right skills and agents. |
| 7 | 3. Keep task and track state current. |
| 8 | 4. Record commit SHAs in `log.md`. |
| 9 | 5. Enforce the double-review gate: review approval plus human confirmation. |
| 10 | 6. Run codebase health checks after each phase and at track completion. |
| 11 | 7. Sync documentation when needed. |
| 12 | 8. Help close, pause, or archive tracks. |
| 13 | |
| 14 | ## Orchestration Rules |
| 15 | |
| 16 | - Prefer skills over agents when possible. |
| 17 | - Do not implement code directly. |
| 18 | - Use implementation skills for code changes. |
| 19 | - Use review skills for code review. |
| 20 | - Use writing skills for documentation. |
| 21 | - Manage track state directly only in tracking files. |
| 22 | |
| 23 | ## Execution Workflow |
| 24 | |
| 25 | ### Phase 1: Setup and Track Selection |
| 26 | |
| 27 | 1. Verify `.conductor/` exists. |
| 28 | 2. Read the global context files: |
| 29 | - `meta.json` |
| 30 | - `guidelines.md` |
| 31 | - `stack.md` |
| 32 | - `style.md` |
| 33 | - `workflow.md` |
| 34 | 3. Verify that `.conductor/tracks/` exists. |
| 35 | 4. Load the target track files. |
| 36 | 5. Treat `workflow.md` as the source of truth. |
| 37 | |
| 38 | ### Phase 2: Task Execution Loop |
| 39 | |
| 40 | For each task: |
| 41 | |
| 42 | 1. Prepare |
| 43 | - Load the task details and dependencies. |
| 44 | - Read the matching Task Content entry from `spec.md`. |
| 45 | - Block execution if the Task Content entry is missing. |
| 46 | 2. Implement |
| 47 | - Follow TDD: RED, GREEN, REFACTOR. |
| 48 | 3. Verify |
| 49 | - Check atomicity. |
| 50 | - Run tests. |
| 51 | - Run diagnostics. |
| 52 | - Run review. |
| 53 | - Wait for human approval. |
| 54 | 4. Mark complete |
| 55 | - Update `plan.md`. |
| 56 | - Update progress. |
| 57 | - Record the commit SHA in `log.md`. |
| 58 | - Update `metadata.json`. |
| 59 | 5. Continue or pause |
| 60 | - Present the result and ask what to do next. |
| 61 | |
| 62 | ### Phase 3: Phase Completion |
| 63 | |
| 64 | 1. Mark the phase complete. |
| 65 | 2. Run full verification. |
| 66 | 3. Run mandatory codebase health analysis. |
| 67 | 4. Present findings and user choices. |
| 68 | 5. Document the result in `log.md`. |
| 69 | |
| 70 | After each track: update relevant docs if needed, and check whether `guidelines.md`, `stack.md`, `style.md`, or `workflow.md` need updates. |
| 71 | |
| 72 | ### Phase 4: Track Completion |
| 73 | |
| 74 | 1. Run final verification. |
| 75 | 2. Run a full codebase health check. |
| 76 | 3. Document overall health impact. |
| 77 | 4. Mark the track complete. |
| 78 | 5. Offer retrospective and archival actions. |
| 79 | |
| 80 | See `references/contracts.md` for agent contracts. |
| 81 | |
| 82 | ## Resources |
| 83 | |
| 84 | - `references/contracts.md` |
| 85 | - `references/planning-protocol.md` (canonical planning ownership) |
| 86 | - `references/state-integrity.md` |
| 87 | - `references/workflow-governance.md` |
| 88 | - `references/codebase-analysis-integration.md` |