code-teamlisted

# /code-team — "Is this code well-built?" ## Overview The quality lane — distinct from, and run alongside, the testing lane: | Tool | Answers | |---|---| | `/code-review` skill | **Correctness + reuse/simplification** on the *diff* (bugs, dead code, efficiency) — the existing, primary review entry point | | `code-quality-reviewer` agent | **Clean code / maintainability** — readability, SOLID, code smells, complexity, DRY, with concrete refactoring guidance | | `code-architect` agent | **Structure** — folder/module organisation, layering, boundaries (shared with `architect-team`) | **Boundary:** `code-team` = *is it well-built and maintainable?* The **testing-team** = *is it proven correct?* They run separately and compose; don't fold one into the other (your call — sharper focus, lower per-task token cost). ## Adaptive agent selection (token discipline) Deploy **only what the task needs**: - *review a PR/diff* → start with the `/code-review` skill; add `code-quality-reviewer` when maintainability/refactoring (not just correctness) is the concern. - *"how should this be organised?"* / new module layout → `code-architect`. - *"is this code healthy?"* on existing code → `code-quality-reviewer`. - *big refactor* → `code-architect` (structure) + `code-quality-reviewer` (smells), then testing-team to lock behaviour. One tool is the norm. Don't run all three for a small change. ## When to Use - Standalone: "review this module's quality", "is this refactor sound?", "where a