/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/code-review/verification, read-only Codex phase reviews), runs the scoped test loop, 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. In a Codex-app host (no Claude subagent tool) check the `claude` CLI is present (`claude --version`); the Claude review pass runs through it. 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>` 6. **Skill check (fresh run only, after `init`).** Check every phase skill the resolved chain names against the skills visible in this session, once. Any that is not listed: record it now, not mid-run: `state-cli degrade --wanted "<skill>" --used "<fallback>" --reason "not in visible skill list"`. 7. **Test commands (once per repo, the first time a lane with an `implement` phase starts; never for `docs-only` or `investigation`).** If `state-cli skills-config show` has no `tests` block, ask for the commands, offering a guess from `package.json` (or the repo's CLAUDE.md): `full` (required), plus `related`, `one`, `report` (a JUnit XML path), `setup`, `build` where they exist. Record with `state-cli skills-config set-tests --full "<cmd>" [--related "<cmd with {files}>"] [--one "<cmd with {test}>"] [--report <junit.xml>] [--setup "<cmd>"] [--build "<cmd>"]`. Declined: `state-cli skills-config set-tests --none` and the repo stays on `tests-green`.

| 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, t