Imported from flanliulf/SpecLite (assets/source/speclite/sdlc-skills/3-solutioning/speclite-story-review-01-reviewer/SKILL.md). Install upstream with npx skills add flanliulf/SpecLite --skill speclite-story-review-01-reviewer. Copyright stays with the author.

[技能说明] 针对指定 Epic 或单个 Story 执行设计文档审查（SR），通过并行三层对抗式审查（Structure & Completeness Hunter、Consistency Checker、Contract & Boundary Auditor）对 Story 设计文档进行多维度分析，将发现进行四桶分类和严重性标签映射后，输出结构化的审查总结并保存到规范化的结果文件中。支持 Epic 粒度和 Story 粒度的双模式审查，以及多轮审查的自动编号和历史记录追踪。

[核心能力] - 并行三层审查：通过 Agent 工具同时启动 Structure & Completeness Hunter、Consistency Checker、Contract & Boundary Auditor 三个独立子代理，从结构完整性、跨文档一致性、契约边界三个正交维度并行分析，天然实现上下文隔离 - 双粒度审查：支持 Epic 模式（审查 Epic 下全部 Story，启用跨 Story 维度）和 Story 模式（审查单个 Story，跳过 Story 间冲突维度），根据用户输入自动判定 - 四桶分类：将所有发现去重后分入 decision_needed / patch / defer / dismiss 四个桶，每个桶有明确的判定条件 - 严重性标签映射：四桶分类与 [高/中/低] 严重性标签并存，基于来源数量和安全关键词进行映射 - Flow Gate 设计审计：Contract & Boundary Auditor 检查 Story 是否把 guidance path、建议文件名或历史实现形态误写成 hard gate - 自动轮次检测：自动扫描已有审查结果文件，确定当前轮次编号 - 首轮/复审自适应：首轮审查聚焦全量文档，复审聚焦上轮修复点和残留问题 - 大批量分批处理：Epic 模式下 Story > 5 时自动分批（每批 ≤ 5 个），确保审查质量 - 子审查失败降级：任一子代理失败时使用剩余层继续；全部失败时降级为单一 LLM 审查 - 只读安全保障：严格禁止修改 Story 文档和源码，仅输出审查总结

[执行流程]

路径约定和文件名格式以 `references/sr-config.md` 为准。
运行时变量使用 `$snake_case` 格式标识，与 sr-config.md 中的文件名模板占位符 `{花括号}` 区分。

Step 1：判定审查粒度并定位目录
    - 接收用户指定的审查目标（Epic 标识或 Story 标识）
    - 读取 `references/sr-config.md` 获取路径约定和双粒度判定规则
    - 根据用户输入判定 `$review_scope`：
        - 匹配 `epic {N}` / `epic-{N}` → `$review_scope = "epic"`，`$epic_id = N`
        - 匹配 `story {N-M}` / `{N-M}` / Story 文件路径 → `$review_scope = "story"`，`$story_id = N-M`，从前缀提取 `$epic_id`
    - 按 `$review_scope` 和配置中的目录格式确定 `$sr_dir`
    - 创建临时文件目录：`$sr_dir/.tmp/`（如不存在）

Step 2：检测审查轮次
    - 读取 `references/sr-config.md` 获取审查总结文件名格式
    - 按配置中的轮次检测规则，扫描 `$sr_dir` 下已有的审查总结文件
    - 统计已有轮次数量，确定本轮轮次号 → `$round_number` = 已有轮次 + 1
    - 判断审查类型 → `$review_type`：
        - `$round_number` == 1 → 首轮审查
        - `$round_number` > 1 → 复审（需参考历史记录）

Step 3：收集审查上下文
    - IF 复审（`$round_number` > 1）：
        - 读取历次 SR 结果文件（按配置中的文件名格式匹配）
        - 读取历次评估文件（按配置中的文件名格式匹配）
        - 重点关注最新一轮评估文件中的 "## 修订执行记录" 章节
        - 建立"已修复问题清单" → 写入 `$sr_dir/.tmp/review-context.md`
    - 读取 Epic 定义文件：按配置中的 Epic 文件目录定位 `epic-{$epic_id}.md`
    - IF Epic 模式：
        - 按配置中的 Story 匹配规则扫描该 Epic 下全部 Story 文件 → `$story_files`
        - 统计 Story 数量
    - IF Story 模式：
        - 按配置中的 Story 匹配规则定位指定 Story 文件 → `$story_files`
    - 确定对照基准文件清单 → `$baseline_files`：
        - 必需：`project-context.md`
        - 必需：`epic-{$epic_id}.md`
        - 按需：架构文档（`03-core-decisions.md`、`04-implementation-patterns.md`）
        - 按需：owning SPEC（当 Story 声称固定源码路径、schema、fixture 或 command 为 hard gate 时必须读取）
        - 按需：前序 Epic 的相关 Story（当本 Epic 引用了前序 Epic 接口时）
    - 若 Epic 文件不存在：终止执行，告知用户

Step 4：执行 Story 审查（三层并行审查引擎）
    - 传入 review-engine.md 的变量：
        - `$review_scope`、`$epic_id`、`$story_id`、`$sr_dir`、`$round_number`、`$review_type`
        - `$story_files`、`$epic_file`、`$baseline_files`
    - 传入 review-engine.md 的文件（复审时）：
        - `$sr_dir/.tmp/review-context.md`
    - 读取并执行 `references/review-engine.md`
    - 该引擎将完成：构建审查输入 → 并行三层审查 → 规范化去重 → 四桶分类 + 严重性标签映射
    - 引擎执行完毕后获取：
        - `$failed_layers`（上下文传回，失败的审查层名称列表）
        - `$review_findings`（从 `$sr_dir/.tmp/classified-findings.json` 读取）

Step 5：生成并保存审查总结
    - 读取 `$sr_dir/.tmp/classified-findings.json` 获取 `$review_findings`
    - 读取输出格式模板：`assets/output-template.md`
    - 根据 `$review_scope`（epic/story）和 `$review_type`（首轮/复审）选择对应模板变体
    - 将 `$review_findings` 整理为结构化总结
    - 只保存总结/结论部分，不保存完整审查过程
    - 确定今天日期，格式为 YYYYMMDD
    - 创建 `$sr_dir` 目录（如不存在）
    - 按 `references/sr-config.md` 中的文件名格式保存文件
    - 严格按照模板中定义的章节结构和格式规范输出，包括：
        - YAML 元信息头部（含 Scope 字段）
        - 审查结论（含审查层状态标注，引用 `$failed_layers`）
        - 审查范围
        - 上轮问题回顾（复审时）
        - 新发现（含严重性标签、四桶分类、审查来源、证据、影响、建议）
        - 逐篇审查结论（仅 Epic 模式）
        - 通过项（含 defer 桶的已知既有问题）
    - 清理临时文件：删除 `$sr_dir/.tmp/` 目录及其所有内容（删除失败不阻断流程）
    - 向用户展示审查总结要点
    - 完成后返回："✅ SR Story 设计审查完成（第 `$round_number` 轮），结果已保存"

[注意事项] - 绝对禁止修改任何 Story 文档 - 绝对禁止修改任何源码文件 - 绝对禁止自行执行修订操作 - Bash 工具仅用于 git log 辅助判断文件变更历史，禁止用于任何文件修改操作 - 结果文件中只保存总结/结论部分，禁止保存完整的审查输出过程，避免内容篇幅过大 - 路径约定和文件名格式以 references/sr-config.md 为准，不硬编码 - 三层子审查的详细执行逻辑见 references/review-engine.md - 子审查失败时使用剩余层继续；全部失败时降级为单一 LLM 自行审查，并向用户明确告知降级 - 始终使用中文输出审查结果 - 复审时必须标注哪些问题是新发现的、哪些是上轮遗留的 - 输出文件头部的 Model Used 字段必须如实填写当前执行审查的模型名称，便于跨 LLM 追溯和质量归因 - 如果找不到 Epic 文件或 Story 文件，立即停止并告知用户 - Epic 模式下 Story > 5 时必须分批（每批 ≤ 5 个），每批结果追加写入同一份 summary 文件 - 分批审查时需确保审查口径一致（同类问题给出同级别结论），跨批次依赖和冲突被识别 - Story 模式下审查范围章节需注明"Story 间冲突与依赖维度未启用"

[生成信息] 本 Skill 由 speclite-skill-creator 自动生成。如需修改，建议同步更新 forge/ 和 .claude/skills/ 两份副本，或通过 skills-upgrade 管理版本。

speclite-story-review-01-reviewer

About

Use it

Manifest

Reviews