project-design-review

name	project-design-review
description	审查已有软件项目、已有仓库或已有实现的当前设计。用户要求基于现有代码或文档审查架构形态、模块边界、依赖方向、数据流、状态流、业务工作流、系统边界、设计债、遗留系统现状，或按传入目标找设计问题时使用。调用时应根据用户已经给出的审查目标直接确定范围并完成审查。

Project Design Review

目标

基于已有项目证据，按用户传入的审查目标直接完成设计审查。审查阶段主要输出当前设计的问题、证据、影响和风险，不展开改进方案。

默认使用用户语言。默认不编辑代码、不改配置、不修测试、不提交变更。

默认边界

• 可以读取文件、运行只读分析命令、运行本 skill 的只读盘点脚本、生成审查报告。
• 不要重构、格式化、修复测试、修改配置、提交代码或改变运行时状态。
• 避免询问能从仓库中发现的事实；只在答案会实质改变设计判断时问聚焦问题。

工作流

1. 解析审查目标

先从用户请求中确定审查范围、关注点和输出深度：

• 如果用户指定模块、业务流、架构层、风险类型或文件路径，只审查该范围，并读取必要上下文。
• 如果用户笼统要求“审查这个项目”“看看设计问题”，自行选择最高风险的 2-4 个切片完成审查，不要停下来让用户选择。
• 如果用户要求全面审查，覆盖主要设计维度，但优先输出高风险发现，不写流水账式项目说明。

可在开头用 1-3 行说明本次实际审查范围和关键假设。不要默认输出完整项目地图。

2. 扫描项目证据

按审查目标读取足够证据。优先检查 README、docs、spec、issue、构建文件、依赖清单、入口点、测试、CI、部署文件、主要源码目录和关键代码路径。

内部建立这些事实，用来支撑判断；只有在解释发现需要时才输出：

• 项目目的和产品形态。
• 技术栈、运行方式和主要入口。
• 主要模块、依赖方向和运行时边界。
• 核心业务对象、状态、数据来源和持久化边界。
• 关键用户流程、系统流程、失败路径和外部集成。
• 测试、观测、部署和运营证据。

3. 选择审查视角

选择 1 个主视角；混合项目最多再加载 2 个辅助视角。只加载实际相关的视角文件：

• references/lenses-high-concurrency.md：高并发、分布式、实时、队列密集、流式或可靠性敏感系统。
• references/lenses-agent-llm-apps.md：agent、LLM、RAG、工具调用、工作流自动化或 AI 应用系统。
• references/lenses-crud-saas.md：CRUD、SaaS、管理后台、工作流、marketplace、CRM、计费或业务运营系统。

如果没有完全匹配的视角文件，根据项目特征归纳审查视角，不要勉强套用已有视角。

4. 直接输出审查发现

围绕用户目标输出发现，每个发现必须满足：

• 有本地证据或明确证据缺口。
• 解释为什么这是设计问题，而不只是实现细节。
• 说明影响范围和风险。
• 只给极短下一步分类，不展开改进设计。

发现格式：

Findings:
1. Problem title
   Evidence:
   Why this is a design issue:
   Impact:
   Risk:
   Next-step category:

风险可用 Critical、High、Medium、Low。如果证据不足但风险值得追踪，明确写成假设或证据缺口。

Next-step category 只能使用短分类：

• Needs design discussion
• Needs validation
• Needs immediate containment
• Needs owner decision
• Acceptable risk

不要在 Next-step category 后追加重构步骤、迁移计划或实现建议。

5. 处理没有发现或证据不足

如果没有找到足够强的设计问题，明确说没有高置信发现，并列出剩余风险或证据缺口。

如果证据不足以支撑用户指定审查目标，输出：

• 已检查的证据。
• 缺少的关键证据。
• 当前只能成立的低置信判断。
• Next-step category: Needs validation

不要用缺少证据填充泛泛建议。

6. 处理用户要求改进的情况

如果用户在审查后要求“怎么改”“给方案”“制定路线图”“设计重构”，不要继续用审查口吻直接给方案。先简要复述已确认的问题，再切换到 design-grill 风格：

• 明确要解决的问题。
• 提出候选方案和取舍。
• 询问会改变设计方向的问题。
• 必要时形成设计记录或实施计划。

核心审查量表

按用户目标选择相关维度，不必每次逐项输出：

• 架构形态：分层、模块边界、依赖方向、扩展点、运行时边界，以及抽象是否匹配真实复杂度。
• 业务工作流：主要流程、状态迁移、业务规则归属、失败路径和运营交接。
• 数据流和所有权：事实来源、持久化边界、派生数据、缓存失效、事件流和 schema 演进。
• 接口契约：API、命令边界、组件契约、集成点、版本、兼容性和错误语义。
• 正确性和故障行为：校验、重试、幂等、部分失败、回滚、补偿、恢复和用户可见降级。
• 安全和隐私：信任边界、认证授权、密钥处理、数据暴露、审计能力和敏感流程控制。
• 可维护性：变更局部性、命名、内聚、耦合、复杂热点、重复、测试接缝和文档质量。
• 可扩展性和性能：预期负载、瓶颈、并发模型、队列、缓存、数据库访问模式、资源限制和背压。
• 可观测性和运营：日志、指标、追踪、告警、发布安全、feature flag、runbook 和事故恢复。
• 测试和验证：单元、集成、端到端、契约、负载、回归、评估、fixture 和 CI 可靠性。

输出风格

• 先给审查范围和结论，再给证据。
• 本地证据使用文件引用。
• 严重问题按风险排序。
• 对未知和薄弱假设保持明确。
• 不写泛泛最佳实践清单。
• 不把审查输出变成改进方案文档。
• 可以附一个很短的 Evidence gaps 小节；不要附完整项目地图，除非用户明确要求。

资源

• references/lenses-high-concurrency.md：高并发和分布式系统的额外审查提示。
• references/lenses-agent-llm-apps.md：agent 和 LLM 应用的额外审查提示。
• references/lenses-crud-saas.md：CRUD、SaaS 和业务工作流系统的额外审查提示。