核心用法
task-review-workflow 是一套面向任务驱动开发的代码审查标准流程，专为 AI 编程助手设计。该技能要求审查者按 8 个严格顺序步骤执行：收集任务上下文 → 对照 REVIEW_CHECKLIST.md 基准审查 → 逐文件 diff 分析 → 本地验证（如可行）→ 撰写明确反馈 → 裁决合并或变更请求 → 执行后合并操作（Trello 状态更新、分支清理）→ 向编程代理发送最终交接消息。整个流程强调任务-PR 联动，确保每次代码变更都可追溯到原始需求。
显著优点
流程完整闭环：从需求对齐到分支清理形成闭环，避免"合并后遗忘"的常见疏漏；强制标准化：要求使用 REVIEW_CHECKLIST.md 作为基准，减少审查主观性；安全机制内置：明确禁止删除 main 分支，降低误操作风险；状态机清晰：merged/CR sent/waiting for fixes 三种终态简化多代理协作；本地验证支持：鼓励在可行时实际运行测试，而非仅静态代码阅读。
潜在缺点与局限性
工具链耦合：深度依赖 Trello 和特定分支命名规范（task branch），迁移成本高；未覆盖冲突处理：未说明多 PR 并行或合并冲突时的协调策略；本地验证"软约束"：使用"when possible"措辞，实际执行力度存疑；缺少量化指标：无代码覆盖率阈值、审查耗时等硬性 KPI；AI 间协议假设：假设存在明确的"programmer agent"角色分工，小型团队可能难以映射。
适合人群
- 采用 AI 辅助编程的敏捷开发团队
- 需要标准化审查流程以控制技术债务的中型项目
- 已使用 Trello 进行任务管理的组织
- 追求"任务-代码-审查-交付"全链路可追溯性的质量敏感型团队
常规风险
1. 流程僵化风险：8 步顺序执行可能拖慢紧急修复，建议保留 hotfix 快速通道
2. Trello 单点故障：任务状态依赖外部系统，需考虑离线降级方案
3. 分支误删：尽管有 main 保护，其他长期分支（如 release/*）仍可能被误清理
4. 审查负载不均：未指定多审查者分配策略，可能导致瓶颈