charted-review

上下文

• designDocPath: $ARGUMENTS[0]

目标

通过同时调度四个专家子 Agent，审查 ${designDocPath} 中的设计文档，然后综合他们的反馈，形成一份可执行的审查意见。

第 1 步 - 设置 Agent

如果第 2 步中的子 Agent 尚未配置，请询问我是否要安装它们。 如果我确认，请将子 Agent 从 ./assets/agents 文件夹复制到 {workspaceRoot}/.cursor/agents 文件夹（如果使用 Cursor）。如果我使用的不是 Cursor，请相应调整路径。

第 2 步 — 并行专家审查

同时（在一条消息中）启动以下四个子 Agent。每个 Agent 都会收到完整的设计文档内容，并须返回结构化审查意见。

子 Agent 类型	关注领域
accessibility-expert	拟议 UI 的无障碍性——ARIA、键盘导航、屏幕阅读器支持、颜色对比度、焦点管理、语义化 HTML。
security-analyst	安全影响——输入验证、注入风险、身份验证／授权缺口、数据暴露、安全默认设置。
ux-expert	易用性——交互模式、错误／空白／加载状态、信息架构、响应式设计、认知负荷。
xp-coach	工程实践——可测试性、渐进式交付、PR 计划质量、简洁性、YAGNI、重构机会。

每个子 Agent 的提示词都必须包含：

1. 设计文档的完整内容。
2. 要求按以下固定章节返回审查意见：
   • 优点 — 设计做得好的地方（简要说明）。
   • 问题 — 编号列表。每个问题都包含简短标题、说明和具体建议。
   • 结论 — 以下选项之一：approve、request-changes 或 needs-discussion。

第 3 步 — 综合与检测冲突

收集四份审查意见。向用户展示一张汇总表：

专家	结论	问题数

然后按专家列出所有问题。

列出问题后，识别冲突——即两位或更多专家提出相互矛盾的建议（例如，一方建议“添加确认对话框”，另一方建议“减少交互步骤”；或者一方建议“拆分成更多 PR”，另一方认为“PR 已经太多”）。

第 4 步 — 挑战轮（如有冲突）

针对每项冲突：

1. 向涉及的两位专家清楚说明分歧。
2. 重新启动每个存在冲突的子 Agent，并提供：
   • 原始设计文档。
   • 该 Agent 自己最初的审查意见。
   • 与其观点相矛盾的另一位专家提出的问题。
   • 要求其修订观点，或以更有力的理由为观点辩护。
3. 若冲突彼此独立，则并行处理冲突双方。

挑战轮结束后，检查专家是否已达成一致。

第 5 步 — 解决

• 如果所有冲突都已解决：呈现最终综合审查意见，并纳入达成一致的修改建议。
• 如果仍有未解决的冲突：以清晰的格式向用户呈现剩余分歧：

未解决：{简短标题}

{专家 A} 主张：{观点摘要}

{专家 B} 主张：{观点摘要}

你怎么决定？

针对每项未解决的冲突，等待用户作出决定后，再生成最终综合审查意见。

步骤 6 — 最终输出

生成一份汇总审查，包含：

1. 总体结论 — 根据汇总结果，选择 approve、request-changes 或 approve-with-nits。
2. 行动项 — 按优先级排序的编号清单，列出设计文档需要进行的具体修改。
3. 已解决的冲突 — 简要说明每项冲突如何解决（专家让步或用户决策）。