| name | sysdesign-evaluator |
| description | Use when evaluating system design documents (*-system-design.md) and OpenAPI specs (*-openapi.yaml) — loads design review rules, item-by-item scanning, red line checks, weighted scoring, and quality report. Cross-document consistency is handled by doc-quality-evaluator separately. |
Sysdesign Evaluator
Skill 标识
- Skill name:
sysdesign-evaluator
- Plugin:
cospowers-solution-design
- Scope: Independent split plugin package
cospowers-solution-design-plugin
- Entry skill:
solution-design
Skill 标识: sysdesign-evaluator
其他 skill 通过 sysdesign-evaluator 引用本 skill。
Extension Points
Before starting, read cospowers.config.json from the plugin root (2 levels above this skill's base directory — the directory shown in "Base directory for this skill" at skill load time). No fallback needed — the config always has valid defaults.
| Config field | Used for |
|---|
config.rules["design-review"] | Design review rules directory (default: rules/design-review/) |
config.rules["dfx"] | DFX rules directory (default: rules/dfx/) |
config.templates["system-design"] | System design template path (default: templates/system-design-template.md) |
Overview
Evaluate system design documents (*-system-design.md) and OpenAPI specs (*-openapi.yaml) produced by the agent-rules-plugin workflow using item-by-item rule scanning (one rule clause at a time, with real-time output), weighted scoring, and a detailed issue report that pinpoints exactly what is wrong, where, and why.
This skill focuses exclusively on single-document quality for system design and OpenAPI artifacts. Cross-document consistency (system requirements ↔ system design ↔ subsystem design) is not handled here — it is the responsibility of doc-quality-evaluator.
Supported document types:
| Document | Produced By | File Pattern | Design Subtype |
|---|
| 系统设计文档（总体设计） | design-spec | *-system-design.md | 总体设计 |
| OpenAPI 接口规范 | design-spec | *-openapi.yaml | -- |
Design type identification（文档子类型识别，仅 *-system-design.md）：
当评估系统设计文档时，按以下三级策略识别其设计子类型：
| 优先级 | 策略 | 方法 |
|---|
| 1 | 文件名匹配 | *总体设计*/*overall*design*/*architecture*design* → 总体设计； *概要设计*/*HLD*/*high*level*design*/*summary*design* → 概要设计； *技术需求设计*/*technical*requirement*design* → 技术需求设计 |
| 2 | 内容关键词 | 在前200行搜索：概要设计说明书/HLD → 概要设计；总体设计说明书/软件总体架构 → 总体设计；技术需求设计 → 技术需求设计 |
| 3 | 结构特征 | 含"函数定义"章节 → 概要设计；含"软件总体架构""模块结构图""系统流程"章节 → 总体设计；含"架构需求分析""方案选型"章节 → 技术需求设计 |
三级都无法识别时：提示用户确认文档类型（当前仅支持总体设计/概要设计/技术需求设计）。
M1-M6 审查模块映射：
识别出设计子类型后，确定对应的审查模块（每个模块对应 rules/design-review/ 下的 checklist 文件）：
| 设计子类型 | 审查模块 |
|---|
| 总体设计 | M1(design-01-doc-writing-standards-checklist.md) + M2(design-02-tech-requirements-design-checklist.md) + M3(design-03-overall-design-checklist.md) + M5(design-05-i18n-design-checklist.md) + M6(design-06-never-again-principles-checklist.md) |
| 概要设计 | M1 + M4(design-04-high-level-design-checklist.md) + M5 + M6 |
| 技术需求设计 | M1 + M2 + M5 + M6 |
M1（文档书写规范）、M5（国际化i18n设计）、M6（不贰过设计准则）为所有子类型必选模块。各模块的 checklist 文件路径为 rules/design-review/<filename>。
模块定义：
| 模块 | 全称 | 检查内容 |
|---|
| M1 | 文档书写规范 | 格式、术语、图表、编号、引用等文档级规范 |
| M2 | 技术需求设计 | 需求来源追溯、需求与设计映射、技术选型依据 |
| M3 | 总体设计 | 架构方案、模块划分、技术栈选择、系统流程 |
| M4 | 概要设计 | 函数定义、接口设计、数据结构、模块内部流程 |
| M5 | 国际化i18n设计 | 多语言支持、时区处理、字符编码、本地化策略 |
| M6 | 不贰过设计准则 | 历史故障经验、已知陷阱规避、团队教训应用 |
3-Stage review workflow（与 Phase 1 并行可选）：
除逐条扫描外，可采用以下模块化审查流程（适用于复杂文档、多人并行审查场景）：
- Stage 1 — 识别类型：确定设计子类型（总体设计/概要设计/技术需求设计）
- Stage 2 — 确定模块：根据子类型确定审查模块列表（M1-M6）
- Stage 3 — 并行审查：为每个模块启动子代理，按模块 checklist 逐项审查；所有子代理返回后汇总结果
日常评估仍以 Phase 0→1→3→4 主线为主；3-Stage 流程作为复杂场景下的补充选项。
Evaluation order (never skip or reorder):
Phase 0: 加载 → Phase 1: 逐条规范扫描 → Phase 3: 打分 → Phase 4: 生成报告
Phase 2（跨文档一致性核查）由 doc-quality-evaluator 承担，本 skill 跳过。
⚠️ 五大强约束（必须100%严格遵守）
违反任何一条强约束都是严重错误！
1. 逐条扫描约束：每条规则必须独立检查 ⭐⭐⭐
- ✅ 必须：对每条规则/检查项，先输出"📍 检查规则 [ID]: [规则内容]"，再执行检查，再输出结论
- ❌ 禁止：批量跳过多条规则，或只输出"整体符合规范"而不逐条检查
- ✅ 必须：有问题时，记录文档章节、引用原文、违反的具体规则条款
- ❌ 禁止：报告模糊描述如"设计不够详细"而不指向具体位置
2. 打分约束：分数必须有依据 ⭐⭐⭐
- ✅ 必须：每个维度的得分附有扣分明细（哪条规则扣了几分）
- ❌ 禁止：直接给出分数而不说明扣分原因
- ✅ 必须：红线违反时，总评直接为 F（不论其他维度分数）
3. 只报告真实问题：通过的规则不写入报告 ⭐⭐⭐
- ✅ 必须：只报告真正违反规范或存在不一致的问题
- ❌ 禁止：写入"符合规范，请保持"等无问题内容
- ✅ 必须：每个问题都有：位置 + 引用原文 + 违反规则 + 严重级别 + 修改建议
4. 一问题一类问题约束：发现一个错误就扫描全文同类 ⭐⭐⭐
- ✅ 必须：发现某类问题（如"DFX数字缺失"）后，立刻扫描全文所有同类实例
- ❌ 禁止：只记录第一个发现的问题，漏掉同一文档中的其他同类问题
5. 范围约束：只评估本 skill 负责的文档类型 ⭐⭐⭐
- ✅ 必须：只处理
*-system-design.md 和 *-openapi.yaml
- ❌ 禁止：评估系统需求文档或子系统设计文档（这些由其他 evaluator skill 负责）
Phase 0: 加载阶段
0.1 自动发现文档（Document Discovery）
不等待用户提供路径。 按以下顺序自动搜索，找到候选文档后展示确认信息。
搜索策略（按优先级依次执行）
Step A — 搜索标准输出目录
使用 Glob 在以下路径搜索：
docs/agent-rules/3-system-design/output/**/*.md → 系统设计文档（含子文档）
docs/agent-rules/3-system-design/output/**/*.yaml → OpenAPI 规范
Step B — 搜索用户指定的上下文路径
如果用户在对话中提到了某个目录或文件名，也在该路径下执行上述 Glob 搜索。
Step C — 向上递归搜索（兜底）
如果 Step A/B 均未找到任何文档，从当前工作目录向上最多 3 层执行搜索：
./**/*-system-design.md
./**/*-openapi.yaml
发现结果处理
搜索完成后，根据发现的文档数量决定评估范围：
🟢 单文档路径（发现 1 份文档）
直接开始评估，不询问用户。 立即输出声明并进入 Phase 1：
📄 发现 1 份文档，开始单文档评估：
🏗️ 系统设计文档: docs/agent-rules/3-system-design/output/2026-04-10-xxx/index.md
（或对应文档类型）
📂 评估模式: 单文档
开始评估...
🔵 多文档路径（发现 2 份文档，即同时存在系统设计和 OpenAPI）
两份文档可一起评估（分别独立扫描，共享评分报告）。展示发现结果后直接开始，不等待确认：
🔍 文档发现结果:
🏗️ 系统设计文档 (N 个):
[1] docs/agent-rules/3-system-design/output/2026-04-10-xxx/index.md (修改时间: YYYY-MM-DD)
📡 OpenAPI 规范 (N 个):
[2] docs/agent-rules/3-system-design/output/2026-04-10-xxx/xxx-openapi.yaml (修改时间: YYYY-MM-DD)
📂 评估模式: 双文档（系统设计 + OpenAPI）
开始评估...
如果同类型有多个文档（如多个 system-design.md），按修改时间降序排列并等待用户确认选择哪个。
其他处理规则
| 情况 | 处理方式 |
|---|
| 同类型有多个文档 | 按修改时间降序排列，建议选最新，等待用户确认 |
| 某类型文档未找到 | 在发现结果中注明"未找到"，继续评估已找到的文档 |
| 所有路径均未找到 | 提示"未找到任何文档，请提供文件路径或目录"，等待用户输入 |
| 用户对话中已直接提供路径 | 跳过 Glob 搜索；直接使用提供的路径 |
0.2 加载评审规范
根据输入文档类型，读取以下规范文件（必须实际读取，不可跳过）：
系统设计文档评估 → 读取 (路径前缀 = config.rules["design-review"]，默认 rules/design-review/):
<design-review-dir>/design-01-doc-writing-standards-checklist.md ← M1
<design-review-dir>/design-02-tech-requirements-design-checklist.md ← M2
<design-review-dir>/design-03-overall-design-checklist.md ← M3
<design-review-dir>/design-05-i18n-design-checklist.md ← M5
<design-review-dir>/design-06-never-again-principles-checklist.md ← M6
<design-review-dir>/模块设计规范.md
<dfx-dir>/安全.md (路径前缀 = config.rules["dfx"]，默认 rules/dfx/)
<dfx-dir>/性能.md
OpenAPI规范评估 → 读取:
rules/design-methods/RESTful_API格式规范v3.0.md
rules/business/01-OPENAPI开发规范.md
rules/business/API开发规范.md
rules/business/错误码规范.md
读取完成后，从规范文件中提取所有检查项，构建检查清单（每条规范条款 = 一个检查项，带编号如 SYS-01、API-01）。
输出：
✅ 规范加载完成
📋 检查清单共 [N] 项:
- 文档写作规范: [n1] 项 （仅系统设计文档）
- 总体设计规范: [n2] 项 （仅系统设计文档）
- 模块设计规范: [n3] 项 （仅系统设计文档）
- 不贰过准则: [n4] 项 （仅系统设计文档）
- DFX规范: [n5] 项 （仅系统设计文档）
- API规范: [n6] 项 （仅OpenAPI规范）
Phase 1: 逐条规范扫描
对加载的每条检查项，执行以下固定流程：
1.1 实时扫描输出格式
对每一条检查项，必须输出：
📍 检查 [CHECK-ID]: [规则摘要（来自规范文件的原始描述）]
├─ 检查位置: [文档章节 § X.X 或 "全文"]
├─ 引用原文: "[被检查内容的直接引用，如果不适用写 N/A]"
├─ 规范要求: [该规则的具体要求]
├─ 检查结果: ✅ 通过 / ❌ 违规 / ⚠️ 警告
└─ [仅违规时] 问题ID: [ISSUE-XXX] | 级别: [Critical/Error/Warning] | 扣分: [-N分]
1.2 违规记录格式
每个发现的问题记录到问题列表：
[ISSUE-XXX]
文档: [文档名]
位置: § [章节编号] [章节名]
规则: [CHECK-ID] — [规则描述]
引用原文: "[实际文档中的原文，精确到句子级]"
问题描述: [具体说明哪里违反了规则]
严重级别: Critical / Error / Warning
修改建议: [具体可操作的修改方向]
扣分: [-N分] (维度: [维度名])
1.3 扫描完成统计
每份文档扫描完成后输出：
📊 [文档名] 扫描完成
- 扫描规则数: [N] 条
- 通过: [n] 条
- 违规(Critical): [n] 条
- 违规(Error): [n] 条
- 警告(Warning): [n] 条
- 发现问题: [ISSUE-001 至 ISSUE-XXX]
1.4 三条设计红线检查（一票否决）
在规范扫描中，以下三条红线必须优先检查，任一违反立刻标记红线，继续扫描但最终总评直接为 F：
红线 R1 — 章节完整性
按以下模板逐章核对（仅计一、二级章节，三级及以下不计入缺失数）；缺失章节数 ≥ 3 → 红线违反：
- 系统设计文档（对照
templates/system-design-template.md，主入口 + 7 个子文档）：
子文档 1: 技术需求设计 / 子文档 2: 设计目标 / 子文档 3: 硬件方案 /
子文档 4: 软件方案 / 子文档 5: 关键特性设计 /
子文档 6: 总结 / 子文档 7: 变更控制
记录：缺失了哪些章节（具体章节号和名称）
红线 R2 — 可靠性章节
- 必须存在且有实质内容（不能只写"不涉及"或"参见平台"）
- 记录：可靠性章节内容是否覆盖：故障容错分析 / 资源使用分析 / 业务流程可靠性
红线 R3 — 安全性章节
- 必须存在且有实质内容
- 记录：安全章节内容是否覆盖：安全基线 / 威胁建模 / 数据保护
红线检查输出格式：
🚨 红线检查结果:
R1 章节完整性: ✅ 通过 / ❌ 违反 — 缺失章节: [§X, §Y]
R2 可靠性章节: ✅ 通过 / ❌ 违反 — 原因: [...]
R3 安全性章节: ✅ 通过 / ❌ 违反 — 原因: [...]
OpenAPI 规范不做 R1/R2/R3 红线检查（章节结构不适用）。
1.5 内置检查项（SYS- 系列，来源：技术需求设计评审标准 V2.0）
以下检查项在完成规范文件扫描后必须逐条执行，与从规范文件提取的检查项享有同等地位：
| 编号 | 检查项 | 位置 | 严重级别 |
|---|
| SYS-ARCH-01 | 架构差距定量化 — 若设计涉及性能演进，必须用具体数字说明"当前指标 vs 目标指标"的差距；"需要提升"式定性说法不可接受 | 子文档4 | Warning |
| SYS-PERFTEST-01 | 性能测试计划完整性 — 性能测试点必须明确包含：测试场景、数据量规模、持续时间、通过判定标准；缺少任一要素不完整 | 子文档5 | Error |
| SYS-CAPACITY-01 | 系统容量边界定义 — DFX 设计必须明确定义系统容量边界：最大并发数、最大数据量、消息队列堆积上限及超限行为（降级/拒绝/排队） | 子文档5 | Error |
| SYS-CONSISTENCY-01 | 分布式一致性策略 — 若涉及跨模块/跨服务数据操作，子文档4中必须明确说明一致性模式（强一致/最终一致）及其约束边界和时间窗口 | 子文档4 | Error |
| SYS-DR-01 | 灾难恢复计划细节 — 可靠性设计必须包含：RTO/RPO 指标、详细恢复步骤、数据一致性验证方法、故障演练频率；仅写"有 DR 方案"不可接受 | 子文档5 | Error |
| SYS-UPGRADE-01 | 版本升级兼容性 — 若涉及版本升级，子文档5部署部分必须说明：数据迁移策略、API 版本兼容性策略、灰度升级方案 | 子文档5 | Warning |
| SYS-CRITICALPAT-01 | 关键路径性能目标 — 子文档4中主要业务流程必须为关键路径定义具体响应时间目标（如：提交操作 ≤ 200ms）；无数字不可接受 | 子文档4 | Error |
| SYS-RESILIENCE-01 | 限流熔断策略 — 高并发系统 DFX 设计必须明确说明：限流阈值、熔断判定条件、对应降级策略、配置管理方式 | 子文档5 | Error |
| SYS-INTEGRATION-01 | 跨域集成安全设计 — 若涉及与外部系统集成，子文档4（架构）或子文档5（安全）必须明确说明：数据边界、权限隔离机制、加密传输方案 | 子文档4/5 | Error |
| SYS-DEBUGGABILITY-01 | 可调试性设计 — 若系统含跨3个以上服务的业务链路、异步消息流程或多步骤状态机，子文档5 §5.4 必须有独立验证方案（dry-run/mock模式）、增量验证方案（contract test/smoke test）、TraceID全链路透传说明；缺任一为 Error | 子文档5 | Error |
| SYS-MONITORING-01 | 可监控性设计 — 子文档5中可运维性部分必须包含具体的业务监控指标定义（指标名称+采集方式+告警阈值），不得只写"接入平台监控"或"参见运维规范"；无具体指标定义视为不完整 | 子文档5 | Error |
| SYS-COVERAGE-01 | 需求覆盖完整性 — 子文档1（技术需求设计）声明的所有系统功能模块和场景，在子文档4（软件方案）和子文档5（关键特性设计）中均有对应设计说明，无遗漏模块；各模块设计章节中包含边界值/临界条件说明（如最大并发数、数据量上限、超时阈值、输入限制等），不得只描述正常路径 | 子文档1/4/5 | Error |
以上 12 条内置检查项仅适用于系统设计文档（*-system-design.md），OpenAPI 规范不适用。
Phase 2: 跨文档一致性核查（跳过）
本 skill 不执行跨文档一致性核查。跨文档一致性（系统需求 ↔ 系统设计 ↔ 子系统设计的方案一致性、DFX 数字一致性、REQ 追踪覆盖率）由 doc-quality-evaluator 承担。
Phase 3: 打分
3.1 评分维度与权重
| 维度 | 权重 | 说明 |
|---|
| 技术可行性 | 30% | 组件真实可用，逻辑无漏洞，性能无明显瓶颈，方案有依据 — 权重最高因为方案本身的可行性是最核心的质量指标 |
| 需求完整性 | 25% | 所有关键场景被覆盖，DFX 要求有实质内容，无空章节或"不涉及"敷衍 |
| 可测试性 | 20% | 每个功能流程覆盖正常路径、异常路径、边界条件三类场景；可注入依赖，有测试接口，支持隔离测试 |
| 规范符合性 | 15% | 文档格式、命名、章节完整性等符合团队规范 |
| 架构合理性 | 10% | 设计模式与现有架构一致，依赖合理，无循环依赖，边界清晰 |
3.2 每维度扣分规则
每个维度满分 100 分，按问题严重级别扣分：
| 问题级别 | 说明 | 每个问题扣分 |
|---|
| Critical | 红线违反、方案根本性缺陷、安全漏洞 | -40 分 |
| Error | 逻辑错误、空章节、数字无依据、接口设计缺陷 | -20 分 |
| Warning | 命名不规范、建议性问题、数字无来源 | -8 分 |
每个维度最低 0 分（不出现负数）。
严格扣分示意：
- 1 个 Critical → 维度直接跌至 60 分以下（D 区）
- 2 个 Error → 维度跌至 60 分（勉强及格线）
- 3 个 Warning → 维度扣 24 分
3.3 总分计算
总分 = 技术可行性×0.30 + 需求完整性×0.25 + 可测试性×0.20
+ 规范符合性×0.15 + 架构合理性×0.10
| 总分 | 等级 | 含义 |
|---|
| 95-100 | A | 优秀，可进入实施规划 |
| 80-94 | B | 良好，必须修复所有 Error 级问题后才能进入实施 |
| 65-79 | C | 勉强，必须修复所有 Error 及 Critical 问题并重新评估 |
| <65 | D | 不及格，需大幅返工后重新评估 |
| 红线违反 | F | 直接失败，不论其他分数 |
3.4 打分输出格式
📊 评分明细:
┌─────────────────────┬──────┬──────────┬────────────────────────┐
│ 评分维度 │ 权重 │ 维度得分 │ 扣分明细 │
├─────────────────────┼──────┼──────────┼────────────────────────┤
│ 技术可行性 │ 30% │ [N]/100 │ ISSUE-003(-20), ... │
│ 需求完整性 │ 25% │ [N]/100 │ ISSUE-007(-20), ... │
│ 可测试性 │ 20% │ [N]/100 │ ISSUE-012(-8), ... │
│ 规范符合性 │ 15% │ [N]/100 │ ISSUE-015(-8), ... │
│ 架构合理性 │ 10% │ [N]/100 │ - │
├─────────────────────┼──────┼──────────┼────────────────────────┤
│ **加权总分** │ 100% │ **[N]** │ │
└─────────────────────┴──────┴──────────┴────────────────────────┘
红线状态: R1 ✅ / R2 ✅ / R3 ❌ 违反
总评: [A/B/C/D/F] — [结论描述]
Phase 4: 生成评估报告
将全部结果整理为结构化 Markdown 报告，保存到与被评估文档同目录的 quality-reports/ 子目录（如不存在则创建）。文件名：YYYY-MM-DD-<文档名>-quality-report.md。
报告结构
# 系统设计文档质量评估报告
**评估对象**: [文档名列表]
**评估日期**: YYYY-MM-DD
**评估模式**: 单文档 / 双文档（系统设计 + OpenAPI）
**设计子类型**: [仅系统设计文档] 总体设计 / 概要设计 / 技术需求设计
**审查模块**: [M1+M2+M3+M5+M6]（根据子类型确定）
**总评**: [A/B/C/D/F] — [N分] / 100
---
## 零、总体结论
（用 3-5 句话概括：文档类型、整体质量评价、主要问题方向、是否建议通过审查）
---
## 一、红线检查结果
| 红线 | 状态 | 说明 |
|---|---|---|
| R1 章节完整性 | ✅ 通过 / ❌ 违反 | [details] |
| R2 可靠性章节 | ✅ 通过 / ❌ 违反 | [details] |
| R3 安全性章节 | ✅ 通过 / ❌ 违反 | [details] |
> 任一红线违反 → 总评 F，必须大幅返工后重新提交评估
---
## 二、评分总览
[评分表格，同 Phase 3.4 格式]
**模块级汇总**（仅系统设计文档）：
| 审查模块 | 总项数 | 通过 | 不通过 | 不适用 | 通过率 |
|---|---|---|---|---|---|
| M1 文档书写规范 | - | - | - | - | -% |
| [其他适用模块] | - | - | - | - | -% |
| **合计** | - | - | - | - | -% |
---
## 三、问题清单（按严重级别排序）
### 🚨 Critical 级问题（必须修复才能继续）
[ISSUE-XXX 详情，格式：文档/章节/规则/原文/描述/建议]
### ❌ Error 级问题（建议修复后继续）
[...]
### ⚠️ Warning 级问题（可酌情处理）
[...]
---
## 四、每份文档单独评分
| 文档 | 规范扫描 | 文档得分 |
|---|---|---|
| 系统设计文档 | [N]/100 | [N]/100 |
| OpenAPI规范 | [N]/100 | [N]/100 |
---
## 五、改进建议（优先级排序）
1. **[最高优先级]** [修复 Critical 问题的具体步骤]
2. **[高优先级]** [修复 Error 问题的具体步骤]
3. **[中优先级]** [修复 Warning 问题的建议]
---
## 六、最终判断与下一步
### 最终判断
- **是否建议通过**：[通过 / 有条件通过 / 不通过]
- **建议后续步骤**：[如：修改后重新审查 / 补充 XX 内容后进入子系统设计]
### 下一步
- 总评 A/B → 可调用 `writing-plans` 进入实施规划
- 总评 C → 修复所有 Error 及以上问题后，重新运行 `sysdesign-evaluator`
- 总评 D → 需要较大修改，建议回到 `design-spec` 修订系统设计
- 总评 F → 红线违反，必须大幅返工，重新生成设计文档
常见问题类型参考
评估中最常见的问题模式，供识别时参考（不是代替逐条扫描）：
| 问题类型 | 典型表现 | 严重级别 |
|---|
| 空DFX章节 | 安全章节只写了"参见平台安全机制" | Error |
| 未验证假设 | 设计假设"用户已登录"但无说明前置条件 | Error |
| N+1查询 | 列表接口在循环中逐条查询DB | Error |
| 缺Mermaid图 | 必填章节只有文字描述无图 | Error |
| 数字无来源 | 性能目标"TPS > 10000"无ADR或历史数据支撑 | Warning |
| API契约不完整 | OpenAPI 接口缺少错误码定义或响应 schema | Error |
| 命名不一致 | 字段在不同章节里分别叫 userId、user_id、uid | Warning |
| 可靠性方案模糊 | 可靠性章节只写"采用高可用方案"无具体机制 | Error |
| 需求覆盖不完整 | 子文档1声明的功能模块在子文档4/5中无对应设计章节，存在遗漏 | Error |
| 缺少边界值 | 设计章节只描述正常路径，无并发上限/数据量上限/超时阈值/输入限制等边界条件 | Error |
与其他 Skills 的集成
sysdesign-evaluator 是一个被动评估器，不主动路由下一步。
- 由
design-spec 步骤 8（系统设计文档完成后）以隔离子代理方式派遣
- 由
design-spec 步骤 9（OpenAPI 规范完成后）以隔离子代理方式派遣
- 评估完成后，将以下内容返回给调用方 skill：
- 评级（A/B/C/D/F）和总分
- 红线状态（R1/R2/R3）
- Critical + Error 问题表格（位置、问题描述、修改建议）
- 质量报告保存路径
- 不触发任何下一步；由调用方（
design-spec）根据评级决定：
- A/B（≥ 80）：调用方继续其自身的下一步（由调用方 skill 的 Checklist 决定，与本 skill 无关）
- C/D/F：调用方修复问题后重新派遣本 skill，直到评级达到 B 或以上
- 评估报告路径：
docs/agent-rules/3-system-design/output/YYYY-MM-DD-xxx/quality-reports/YYYY-MM-DD-xxx-quality-report.md
