Hire your crew

Interactive setup. Re-runnable: hiring, renaming, and firing are all this one flow.

Step 1 — Read any existing config

If sous.config.yaml exists, read it and present the current settings as defaults. Say what you found: "You currently have 4 roles staffed and a GitHub Issues backend." Never silently overwrite someone's configuration.

Step 2 — Choose the backends

Ask two questions:

1. Where do your tasks live? github-issues or jira.
2. Where does your code live? github (the only option today).

If they pick Jira, tell them plainly: Jira has no pull requests, so code review still happens on GitHub. Both get configured. That is expected, not a misconfiguration.

Collect what the chosen backends need:

• GitHub: owner/repo.
• Jira: the site URL and project key, plus a reminder to set JIRA_EMAIL and JIRA_API_TOKEN in their environment. Mention that Jira labels cannot contain spaces.

Step 3 — Staff the roles

Present the eight roles. For each, ask whether to staff it and what to call them. Offer the suggestions; accept anything they type.

Every role is optional. A solo backend developer might staff only reviewer and security. Skills for unstaffed roles self-skip rather than erroring. Say this out loud, so nobody staffs a role defensively just to avoid breaking something.

Names are cosmetic — they change how each agent signs its work, nothing else. The role is the interface.

Step 4 — Labels, branches, commands

Offer the defaults from sous.config.example.yaml. Most people accept them. If they already have a label scheme, map to it now — this is the moment it is cheap, and every later skill reads these names from config.

Ask for their test, typecheck, and build commands. Blank is fine and means "skip that check."

Step 5 — Gates

The default required gates are [reviewer, merge-risk, security, qa], with a human required to merge at medium risk and above.

Explain the tradeoff once: fewer gates is faster, and the gates are precisely what make it safe for an agent to merge anything at all. Recommend keeping all four.

Note honestly which gate skills are actually installed in this version. Requiring a gate whose skill does not exist will block every merge.

Step 6 — Write the config

Write sous.config.yaml. Show them the full file. Confirm it is gitignored — it holds their repo and project identifiers.

Two formatting rules the config reader depends on:

• Two-space indentation.
• Nested blocks, not inline maps. Write pm: then name: Paul on the next line, never pm: { name: Paul }.

Step 7 — Provision the labels

Call task.ensure_label once for every label in the config: task, ready, in_progress, blocked, and the three priority labels.

Do not skip this on the assumption that the labels already exist. On GitHub a label must exist before it can be applied, so without this step the user's very first /sous:file fails with could not add label — a bad first five minutes, and a confusing one, because the error names the label rather than the missing setup step.

task.ensure_label is idempotent, and is a no-op on backends with free-form labels, so it is always safe to run — including on a re-run of /sous:hire after renaming a label.

Report what you provisioned, briefly.

Step 8 — Close out

Crew hired. Try: /sous:file <one line describing something to build or fix>

Sous commands are namespaced by the plugin, so they are /sous:file, /sous:pm, /sous:reviewer — not bare /file. This matters beyond tidiness: /file is a common skill name, and an unprefixed call can silently resolve to a different plugin's skill.