team-polish

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
If no argument is provided, output usage guidance and exit without spawning any agents:
Usage:
/team-polish [feature or area]
— 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. The user must approve before moving to the next phase.
如果未提供参数,输出使用指南并退出,不启动任何代理:
使用方法:
/team-polish [功能或区域]
— 指定需要打磨的功能或区域(例如:
combat
main menu
inventory system
level-1
)。请勿在此处使用
AskUserQuestion
;直接输出指南。
当传入参数调用该技能时,通过结构化流程协调打磨团队。
决策节点: 在每个阶段过渡时,使用
AskUserQuestion
向用户展示子代理的提案作为可选选项。在对话中写入代理的完整分析,然后用简洁标签记录决策。用户必须批准后才能进入下一阶段。

Phase 0: Resolve Review Mode

阶段0:确定评审模式

  1. If
    --review [mode]
    was passed as an argument, use that mode.
  2. Else read
    production/review-mode.txt
    — use whatever is written there.
  3. Else default to
    lean
    .
Modes:
  • full
    — spawn all director and lead gates as described
  • lean
    — skip director gates unless they are PHASE-GATE type (CD-PHASE-GATE, TD-PHASE-GATE, PR-PHASE-GATE, AD-PHASE-GATE)
  • solo
    — skip all director gate spawning entirely; run the skill without any agent gates
Store the resolved mode for use in all subsequent phases.
Director gate skip rule: Before spawning any Tier 1 director or lead for review (outside of PHASE-GATE triggers), apply the resolved mode: skip if solo mode; skip if lean mode and this is not a PHASE-GATE.
  1. 如果参数中包含
    --review [mode]
    ,则使用该模式。
  2. 否则读取
    production/review-mode.txt
    文件 — 使用其中记录的模式。
  3. 否则默认使用
    lean
    模式。
模式说明:
  • full
    — 按照描述启动所有主管和负责人关卡
  • lean
    — 跳过主管关卡,除非是PHASE-GATE类型(CD-PHASE-GATE、TD-PHASE-GATE、PR-PHASE-GATE、AD-PHASE-GATE)
  • solo
    — 完全跳过所有主管关卡的启动;无需任何代理关卡即可运行该技能
保存确定后的模式,供后续所有阶段使用。
主管关卡跳过规则:在启动任何一级主管或负责人进行评审之前(PHASE-GATE触发的情况除外),应用已确定的模式:若为solo模式则跳过;若为lean模式且该关卡非PHASE-GATE类型则跳过。

Team Composition

团队组成

  • performance-analyst — Profiling, optimization, memory analysis, frame budget
  • engine-programmer — Engine-level bottlenecks: rendering pipeline, memory, resource loading (invoke when performance-analyst identifies low-level root causes)
  • technical-artist — VFX polish, shader optimization, visual quality
  • sound-designer — Audio polish, mixing, ambient layers, feedback sounds
  • tools-programmer — Content pipeline tool verification, editor tool stability, automation fixes (invoke when content authoring tools are involved in the polished area)
  • qa-tester — Edge case testing, regression testing, soak testing
  • performance-analyst — 性能分析、优化、内存分析、帧预算管理
  • engine-programmer — 引擎级瓶颈处理:渲染管线、内存、资源加载(当性能分析师定位到底层根因时调用)
  • technical-artist — 视觉特效打磨、着色器优化、视觉品质提升
  • sound-designer — 音频打磨、混音、环境音层、反馈音效
  • tools-programmer — 内容管线工具验证、编辑器工具稳定性、自动化修复(当打磨区域涉及内容创作工具时调用)
  • qa-tester — 边缘用例测试、回归测试、压力测试

How to Delegate

委派方式

Use the Task tool to spawn each team member as a subagent:
  • subagent_type: performance-analyst
    — Profiling, optimization, memory analysis
  • subagent_type: engine-programmer
    — Engine-level fixes for rendering, memory, resource loading
  • subagent_type: technical-artist
    — VFX polish, shader optimization, visual quality
  • subagent_type: sound-designer
    — Audio polish, mixing, ambient layers
  • subagent_type: tools-programmer
    — Content pipeline and editor tool verification
  • subagent_type: qa-tester
    — Edge case testing, regression testing, soak testing
Always provide full context in each agent's prompt (target feature/area, performance budgets, known issues). Launch independent agents in parallel where the pipeline allows it (e.g., Phases 3 and 4 can run simultaneously).
使用Task工具将每个团队成员作为子代理启动:
  • subagent_type: performance-analyst
    — 性能分析、优化、内存分析
  • subagent_type: engine-programmer
    — 针对渲染、内存、资源加载的引擎级修复
  • subagent_type: technical-artist
    — 视觉特效打磨、着色器优化、视觉品质提升
  • subagent_type: sound-designer
    — 音频打磨、混音、环境音层
  • subagent_type: tools-programmer
    — 内容管线与编辑器工具验证
  • subagent_type: qa-tester
    — 边缘用例测试、回归测试、压力测试
务必在每个代理的提示中提供完整上下文(目标功能/区域、性能预算、已知问题)。在流程允许的情况下并行启动独立代理(例如,阶段3和阶段4可同时进行)。

Pipeline

流程

Phase 1: Assessment

阶段1:评估

Delegate to performance-analyst:
  • Profile the target feature/area using
    /perf-profile
  • Identify performance bottlenecks and frame budget violations
  • Measure memory usage and check for leaks
  • Benchmark against target hardware specs
  • Output: performance report with prioritized optimization list
委派给performance-analyst
  • 使用
    /perf-profile
    对目标功能/区域进行性能分析
  • 识别性能瓶颈和帧预算违规情况
  • 测量内存使用情况并检查内存泄漏
  • 针对目标硬件规格进行基准测试
  • 输出:包含优先级优化列表的性能报告

Phase 2: Optimization

阶段2:优化

Delegate to performance-analyst (with relevant programmers as needed):
  • Fix performance hotspots identified in Phase 1
  • Optimize draw calls, reduce overdraw
  • Fix memory leaks and reduce allocation pressure
  • Verify optimizations don't change gameplay behavior
  • Output: optimized code with before/after metrics
If Phase 1 identified engine-level root causes (rendering pipeline, resource loading, memory allocator), delegate those fixes to engine-programmer in parallel:
  • Optimize hot paths in engine systems
  • Fix allocation pressure in core loops
  • Output: engine-level fixes with profiler validation
委派给performance-analyst(必要时联合相关程序员):
  • 修复阶段1中识别的性能热点
  • 优化绘制调用,减少过度绘制
  • 修复内存泄漏并降低内存分配压力
  • 验证优化不会改变游戏玩法
  • 输出:包含优化前后指标的优化代码
如果阶段1识别出引擎级根因(渲染管线、资源加载、内存分配器),则并行委派给engine-programmer进行修复:
  • 优化引擎系统中的热点路径
  • 修复核心循环中的内存分配压力
  • 输出:带有性能分析器验证的引擎级修复方案

Phase 3: Visual Polish (parallel with Phase 2)

阶段3:视觉打磨(与阶段2并行)

Delegate to technical-artist:
  • Review VFX for quality and consistency with art bible
  • Optimize particle systems and shader effects
  • Add screen shake, camera effects, and visual juice where appropriate
  • Ensure effects degrade gracefully on lower settings
  • Output: polished visual effects
委派给technical-artist
  • 根据美术手册评审视觉特效的质量和一致性
  • 优化粒子系统和着色器效果
  • 适当添加屏幕震动、相机效果和视觉冲击力
  • 确保特效在低配置下能优雅降级
  • 输出:打磨后的视觉特效

Phase 4: Audio Polish (parallel with Phase 2)

阶段4:音频打磨(与阶段2并行)

Delegate to sound-designer:
  • Review audio events for completeness (are any actions missing sound feedback?)
  • Check audio mix levels — nothing too loud or too quiet relative to the mix
  • Add ambient audio layers for atmosphere
  • Verify audio plays correctly with spatial positioning
  • Output: audio polish list and mixing notes
委派给sound-designer
  • 评审音频事件的完整性(是否有操作缺少音效反馈?)
  • 检查音频混音电平 — 确保没有相对于整体混音过响或过轻的内容
  • 添加环境音层以营造氛围
  • 验证音频空间定位播放是否正确
  • 输出:音频打磨列表和混音说明

Phase 5: Hardening

阶段5:强化测试

Delegate to qa-tester:
  • Test all edge cases: boundary conditions, rapid inputs, unusual sequences
  • Soak test: run the feature for extended periods checking for degradation
  • Stress test: maximum entities, worst-case scenarios
  • Regression test: verify polish changes haven't broken existing functionality
  • Test on minimum spec hardware (if available)
  • Output: test results with any remaining issues
委派给qa-tester
  • 测试所有边缘用例:边界条件、快速输入、异常操作序列
  • 长时间测试:持续运行功能,检查性能是否下降
  • 压力测试:最大实体数量、最坏场景
  • 回归测试:验证打磨变更未破坏现有功能
  • 在最低配置硬件上测试(若可用)
  • 输出:包含剩余问题的测试结果

Phase 6: Sign-off

阶段6:验收

  • Collect results from all team members
  • Compare performance metrics against budgets
  • Report: READY FOR RELEASE / NEEDS MORE WORK
  • List any remaining issues with severity and recommendations
  • 收集所有团队成员的结果
  • 将性能指标与预算进行对比
  • 报告:READY FOR RELEASE / NEEDS MORE WORK(已就绪可发布 / 需要进一步优化)
  • 列出所有剩余问题及其严重程度和建议方案

Error Recovery Protocol

错误恢复协议

If any spawned agent (via Task) returns BLOCKED, errors, or cannot complete:
  1. Surface immediately: Report "[AgentName]: BLOCKED — [reason]" to the user before continuing to dependent phases
  2. Assess dependencies: Check whether the blocked agent's output is required by subsequent phases. If yes, do not proceed past that dependency point without user input.
  3. Offer options via AskUserQuestion with choices:
    • Skip this agent and note the gap in the final report
    • Retry with narrower scope
    • Stop here and resolve the blocker first
  4. Always produce a partial report — output whatever was completed. Never discard work because one agent blocked.
Common blockers:
  • Input file missing (story not found, GDD absent) → redirect to the skill that creates it
  • ADR status is Proposed → do not implement; run
    /architecture-decision
    first
  • Scope too large → split into two stories via
    /create-stories
  • Conflicting instructions between ADR and story → surface the conflict, do not guess
如果任何通过Task启动的代理返回BLOCKED、错误或无法完成任务:
  1. 立即告知用户:在继续依赖该阶段的任务前,向用户报告“[代理名称]: BLOCKED — [原因]”
  2. 评估依赖关系:检查被阻塞代理的输出是否为后续阶段所需。若是,在未获得用户输入前不要越过该依赖节点。
  3. 通过AskUserQuestion提供选项
    • 跳过该代理并在最终报告中注明缺口
    • 缩小范围后重试
    • 在此处停止并先解决阻塞问题
  4. 始终生成部分报告 — 输出所有已完成的工作。切勿因单个代理阻塞而丢弃已完成的工作。
常见阻塞情况:
  • 输入文件缺失(未找到剧情文档、GDD不存在)→ 重定向至创建该文件的技能
  • ADR状态为Proposed → 请勿执行;先运行
    /architecture-decision
  • 范围过大 → 通过
    /create-stories
    拆分为两个任务
  • ADR与任务之间存在指令冲突 → 告知用户冲突,请勿自行猜测

File Write Protocol

文件写入协议

All file writes (performance reports, test results, evidence docs) are delegated to sub-agents spawned via Task. Each sub-agent enforces the "May I write to [path]?" protocol. This orchestrator does not write files directly.
所有文件写入操作(性能报告、测试结果、证据文档)均委派给通过Task启动的子代理。每个子代理执行“是否允许写入[路径]?”协议。该编排器不直接写入文件。

Output

输出内容

A summary report covering: performance before/after metrics, visual polish changes, audio polish changes, test results, and release readiness assessment.
一份总结报告,涵盖:优化前后的性能指标、视觉打磨变更、音频打磨变更、测试结果以及发布就绪性评估。

Next Steps

后续步骤

  • If READY FOR RELEASE: run
    /release-checklist
    for the final pre-release validation.
  • If NEEDS MORE WORK: schedule remaining issues in
    /sprint-plan update
    and re-run
    /team-polish
    after fixes.
  • Run
    /gate-check
    for a formal phase gate verdict before handing off to release.
  • 如果状态为READY FOR RELEASE:运行
    /release-checklist
    进行最终发布前验证。
  • 如果状态为NEEDS MORE WORK:在
    /sprint-plan update
    中安排剩余问题,并在修复后重新运行
    /team-polish
  • 在移交至发布流程前,运行
    /gate-check
    获取正式的阶段关卡结论。