team-polish

Team Polish

If no argument is provided, output usage guidance and exit without spawning any agents:

Usage: /team-polish [feature or area to polish] [--review full|lean|solo] — specify the feature or area to polish (e.g., combat, main menu, inventory system, level-1). Do not use AskUserQuestion here; output the guidance directly.

When this skill is invoked with an argument, orchestrate the polish team through a structured pipeline.

Decision Points: At each phase transition, use AskUserQuestion to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. In collaborative mode, the user must approve before moving to the next phase. In guided mode the pipeline advances automatically unless a phase is BLOCKED; in autonomous mode it runs end to end, recording each phase outcome via log_decision. Decisions in automation_always_ask categories (is_always_ask_category helper) always prompt regardless of mode. See .claude/docs/automation-modes.md.

Phase 0: Resolve Config

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys review_mode,automation,team.size,workflow

Resolved above — use as-is; --review overrides review_mode. No block → defaults in .claude/docs/config-resolution.md.

review_mode sets director-gate depth, and this pipeline has no director gate: no phase below spawns CD-, TD-, PR- or AD-PHASE-GATE, at any review_mode. Its phase gates are the pipeline's own decision points (defined under team.size below), and the agents that work at them are team members, not director gates.

automation drives the Decision Points note above. See the Decision Points note above and .claude/docs/automation-modes.md for how each mode changes pipeline behavior.

team.size: which agents are active (orthogonal to review_mode gate-depth and workflow docs).

• individual (default): performance-analyst + technical-artist. Other agents consulted via these two, not spawned separately. No programmer is active, so the optimisation list's programmer items are not implemented in this run — the report names the list as handed to /dev-story (Phase 2).
• small: + sound-designer + qa-tester + engine-programmer, and tools-programmer when Phase 1 traces a cause to a content authoring tool (the full pipeline as documented).
• studio: the small set, engine-programmer included, + an adversarial review pass: Phase 5's qa-tester is told "your job is not to confirm this holds — find how it breaks", and the report says the pass ran. This pipeline has no engine specialist to widen; engine-level work stays with engine-programmer. A non-core agent needed at individual routes through the nearest active core agent with an informational note. "Phase gate" means any phase that ends in an AskUserQuestion decision point this pipeline itself lists — a transition under Decision Points above, or a Gate step written into the pipeline below — whatever the automation mode. guided and autonomous change how a gate is passed (it auto-advances, or is recorded with log_decision), not whether it is one, so bounded-exception condition (3) below holds at it in every mode. An agent restricted to "phase gates only" is spawned at those points and no others. This active-set scoping applies throughout the pipeline below: any phase that names an agent outside the active set routes through the nearest core agent rather than spawning it.