/conductor

name: conductor
description: Use at the start of ANY coding task in a git repo - implement, add, build, fix, debug, or refactor a feature, bug fix, refactor, quick fix, docs change, or investigation - and when resuming a senior-dev session. Classifies the task, routes it through the mandatory installed-skill chain (superpowers brainstorming/worktrees/plans/TDD/systematic-debugging, built-in code-review and verify, read-only Codex phase reviews), records every phase in .senior-dev/state.json via the state CLI, and drives the docs gate and zero-leftovers hygiene sweep. Also use when the user runs /senior-dev:start, asks what phase the session is in, or asks to finish/close the session.

senior-dev conductor

You are running a senior-dev session. You do not write code casually: every task goes through classification, the mandatory skill chain, recorded phases, review gates, and a clean close. The state CLI is the only way you record progress — never hand-edit `.senior-dev/state.json`, never claim a phase is done without recording it at that moment.

State CLI (all commands run from inside the target repo):

node "${CLAUDE_PLUGIN_ROOT}/scripts/state-cli.mjs" <subcommand> [flags]

1. Engage

1. Run `node <plugin>/scripts/state-cli.mjs status` (the session bootstrap gives the exact path). If it reports an active session, resume at the reported phase — its skill source and guard answer are already recorded, so skip the rest of §1; do not restart completed phases. On resume also run `state-cli guard status`; if it prints `stale`, run `state-cli guard install` (consent already given) so the hooks carry the current gate logic. If it prints a `codex:` update line, offer `codex update` before the first Codex pass — the review lanes use whatever CLI is on PATH. 2. **Skill source (fresh run only, before classifying).** Decide which skills fill the process phases this run. Run `node <plugin>/scripts/state-cli.mjs skills-config show`.

• **Config present:** state its `source` as the project default and ask a

one-beat confirm — "Project default: **<source>** (with this repo's `<mapped phases>`). Use it, or choose another?" A bare "yes"/"use it" proceeds; naming another source switches.

• **No config:** ask the four-way question, `superpowers` marked default:

1. **own** — this project's own skills fill each phase. 2. **superpowers** (default) — the canonical chain. 3. **combo** — superpowers base, this project's skills layered on where they exist. 4. **suggest** — search for skills with `find-skills` and pick.

• Record the operator's answer for next time:

`state-cli skills-config set --source <s> [--steps 'plan=<skill>,review=<skill>']`, and on first creation ask once: keep this config **private** (default) or **share** it with the team? On "share" run `state-cli skills-config share` and tell them to `git add .senior-dev/skills.json`.

• Record the run's choice once the session exists (after `init`):

`state-cli skill-source --source <s> --map '<phase→skill json>' [--suggestions '<json array of candidates the operator took>']` (add `--suggestions` when the source is `suggest`). 3. **Universal guard (fresh run only, once per repo).** Run `state-cli guard status`.

• `absent` and no recorded answer: ask once — "Install the universal

enforcement hooks? They make the gates hold in Cowork, Codex, and plain terminals too — written to this repo's git hooks; existing hooks are preserved and chained." Yes → `state-cli guard install`. No → run `state-cli guard uninstall` (records the decline; safe no-op when nothing is installed); never re-ask.

• `installed`: proceed silently. `stale`: run `state-cli guard install`

again (silent refresh; consent already given).

• `absent` but the config says installed (hooks went missing): mention it

once and re-offer (tell them apart via the `guard` key in step 2's `skills-config show` output — `guard status` prints bare `absent` in both cases).

• `declined`: stay silent; `/senior-dev:guard` remains available.

4. Classify the task as exactly one of the types below. If genuinely ambiguous, ask the operator ONE multiple-choice question. 5. Initialise: `state-cli init --task "<one-line task>" --type <type>`

| Type | When | |---|---| | `feature` | New behaviour or capability | | `bug-fix` | Existing behaviour is wrong | | `refactor` | Behaviour preserved, structure improved | | `quick-fix` | ≤3 files, ≤~30 min, obvious change | | `docs-only` | Prose/docs only, no code | | `investigation` | Read-only question answering |

**Escalation rule:** a `quick-fix` that grows past 3 files or ~30 minutes is no longer a quick fix. Tell the operator you are escalating, then close the mini-session with `state-cli finish --force-open "escalating quick-fix to <type>"` and immediately re-init at the stricter lane in the same turn (its gates are still open mid-escalation - that's expected; the logged bypass entry is the audit trail).

Skill source resolution

The phase spine never changes; the source decides which skill fills each phase.

• **own** — each phase resolves to a project skill: `skills.json` `steps`

mapping first, then a project skill you can see (project `CLAUDE.md` / installed project skills). A phase with neither is a gap (below).

• **superpowers** — each phase resolves to its canonical `superpowers:*` /

built-in skill (the chains in §2). This is the default.

• **combo** — superpowers base; a project `steps` mapping or visible project

skill overrides that phase; phases the project doesn't cover stay on superpowers.

• **suggest** — invoke `find-skills` to search skills.sh, present ranked

candidates, let the operator pick; fold chosen skills into the chain. Install only on an explicit yes.

**Per-phase picker.** When the operator chooses `own` or `combo` — or asks to customise ski