gala-team-designlisted

# gala_team designer Produce a `team.yaml` (or a focused diff against an existing one) tuned to the user's project. The output is a concrete, ready-to-run config — no placeholders, no "TODO" comments — based on what the project actually looks like. **Argument:** `$ARGUMENTS` — Either: - A path to a project directory (e.g. `~/work/auth-service`) → design a team from scratch for it. - A path to an existing `team.yaml` (e.g. `team.yaml`, `examples/skunkworks.yaml`) → review and propose optimizations. - A short project description (e.g. `"a Rust web crawler with sqlite storage"`) → design a team without a target repo. - Empty → ask the user which mode and what target. ## Output contract The skill MUST end with one of: 1. **A complete `team.yaml`** in a fenced ```yaml block, ready for `gala_team --team <path> --project <repo>`. No placeholders, no `<TODO>` markers. 2. **A focused diff** against an existing `team.yaml` (paths to read/edit + concrete replacement blocks), if optimizing. Plus a brief rationale (~5-8 bullets) explaining the key choices: roster size, why or why not QA, workspace_mode pick, hook commands picked, what each member's personality is tuned for. Rationale is for the user; the yaml is for the machine. --- ## Step 1 — Survey the target When given a project path: 1. Read `README.md` (or equivalent) for project purpose + commands. Skim, don't summarize back. 2. Read `CLAUDE.md` if present — it's the highest-signal source on conventions, gotchas, and forbi