Conductor (fcoury) — Prompts
Excerpt 1: commands/setup.md — Sequential resume protocol
## 1.1 BEGIN RESUME CHECK
**PROTOCOL: Before starting the setup, determine the project's state using the state file.**
1. **Read State File:** Check for the existence of `conductor/setup_state.json`.
- If it does not exist, this is a new project setup. Proceed directly to Step 1.2.
- If it exists, read its content.
2. **Resume Based on State:**
- If `STEP` is "2.1_product_guide", announce "Resuming setup: The Product Guide is already complete." and proceed to **Section 2.2**.
- If `STEP` is "3.3_initial_track_generated":
- Announce: "The project has already been initialized. You can create a new track..."
- Halt the `setup` process.
Technique: State-machine resume protocol — each step has a named state; setup can resume exactly from the last successful step. Announcement-then-proceed pattern for user transparency.
Excerpt 2: GEMINI.md — Minimal ambient context for Gemini
# Conductor Context
If a user mentions a "plan" or asks about the plan, and they have used the conductor extension in the current session, they are likely referring to the `conductor/tracks.md` file or one of the track plans (`conductor/tracks/<track_id>/plan.md`).
Technique: Minimal context disambiguation file injected at session start. Resolves the ambiguity of "plan" (could mean anything) in the Gemini context. This is the entire Gemini context file — radical brevity.
# Conductor for Codex CLI
## Commands
After installing the prompt files, invoke commands using `/prompts:` prefix:
| Command | Description |
|---------|-------------|
| `/prompts:conductor-setup` | Set up Conductor environment for a project |
| `/prompts:conductor-new-track` | Create a new track (feature or bug fix) |
| `/prompts:conductor-implement` | Execute tasks from the current track's plan |
| `/prompts:conductor-status` | Display progress of all tracks |
| `/prompts:conductor-revert` | Revert a track, phase, or task |
Technique: Tool-specific documentation as separate .md files. Each tool gets its own documentation contract. The prompt content itself is shared (same methodology), only the invocation prefix changes.
Prompting techniques observed
- State-machine resume —
setup_state.json with named step keys enables exact resume
- Minimal ambient injection (GEMINI.md) — single-paragraph disambiguation vs. full context dump
- Tool-agnostic prompt files —
prompts/ directory mirrors commands/ with same content but different invocation prefix
- Auto-skill trigger conditions — skill activates on directory presence OR keyword mention OR task context
- Sequential section labels —
1.1 BEGIN RESUME CHECK, 2.0 PHASE 1, 3.0 PHASE 2 for clear agent navigation