菜单
质检 Agent：检查 vibe-coding-kit 其他 Skill 的产出物是否符合治理规范。 当用户说"检查一下产出"、"帮我看看合不合规"、"质检"、"验证 PRD"、"检查项目说明书"， 或在任何 Skill 完成产出后，使用此 Skill 做合规检查。 它读取项目根目录的 harness.json，逐条校验产出文件，报告违规项和修复建议。 这是 vibe-coding-kit 套件的治理层（harness），确保所有产出物格式统一、质量达标。 它不止检查格式，还会做跨 Skill 一致性校验——比如 PRD 里的项目名和项目说明书里的项目名是不是一致。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | vibe-coding-harness |
| description | 质检 Agent：检查 vibe-coding-kit 其他 Skill 的产出物是否符合治理规范。 当用户说"检查一下产出"、"帮我看看合不合规"、"质检"、"验证 PRD"、"检查项目说明书"， 或在任何 Skill 完成产出后，使用此 Skill 做合规检查。 它读取项目根目录的 harness.json，逐条校验产出文件，报告违规项和修复建议。 这是 vibe-coding-kit 套件的治理层（harness），确保所有产出物格式统一、质量达标。 它不止检查格式，还会做跨 Skill 一致性校验——比如 PRD 里的项目名和项目说明书里的项目名是不是一致。 |
这不是一个独立使用的 Skill，而是其他 Skill 的"守门员"——在任何 Skill 声称"完成"后，用它来验证产出物是否真正符合规范。
治理规则来自项目根目录的
harness.json（唯一真实来源）和CLAUDE.md（人类可读宪法）。 本 Skill 把这些规则变成逐条可执行的检查项。
先确认用户想检查什么：
docs/ 下所有已有产出物docs/ 不存在或为空，直接报告"没有可检查的产出物"读取项目根目录的 harness.json，提取：
produces（该产出什么文件）required_sections（必须包含的章节）field_requirements（字段级校验规则）validation（内容级校验规则）cross_skill_rules（跨 Skill 一致性规则，仅在多 Skill 产出共存时检查）quality_gates.before_delivery（交付前必须通过的门）workflow（流程定义：阶段、步骤、entry_gate/exit_gate、账本规则）—— 用于新增的流程一致性检查progress_cards（项目进度卡规则：低上下文读取、总表/模块卡/任务卡同步）并读取 docs/进度账本.md（流程状态来源）。若不存在，流程检查记为"未启用账本"。
如果项目存在 .dsu/progress/index.md，读取该文件并按需抽查相关模块卡和任务卡；如果不存在，项目进度卡检查记为"未启用"。
按以下顺序逐项检查，每项给出通过/不通过/不适用：
对照 harness.json.workflow 和 docs/进度账本.md，核对过程有没有跑偏（不只是产出物对不对）：
exit_gate 是否真的过了（防止"账本说完成、产出物却没达标"）。required:false、且在账本"跳步留痕"写了理由；required:true 的步骤被跳 = 🔴 违规。docs/ 下实际存在的产出物对得上。输出：🔴 流程违规（如"S1 未过却已在 S2"）／🟡 跳步未留痕、账本与进度说明书不一致／✅ 流程一致。
如果项目启用了 .dsu/progress/，对照 harness.json.progress_cards 检查：
.dsu/progress/index.md 是否存在且非空。.dsu/progress/modules/duXX-xxx.md。输出：🔴 缺少总表或状态冲突／🟡 总表过细、模块卡缺失、任务 closeout 未同步／✅ 项目进度卡可用。
对照 produces，确认每个文件是否已创建、是否非空。
对照 required_sections，在文件中搜索这些章节标题是否存在。
对照 field_requirements：
v\d+\.\d+）对照 validation：
对照 constitution.forbidden 逐条扫描：
{ } 配对、TODO、TBD 等占位符模式sk- 前缀等）prd.md 的「产品结论」与 项目说明书.md 的「需求基准描述」逐条对照 quality_gates.before_delivery。
按严重程度分组输出：
## 质检报告：{Skill 名称 / 全量检查}
### 🔴 错误（必须修复，否则产出不合格）
| # | 文件 | 规则 | 问题 | 修复建议 |
|---|------|------|------|---------|
| 1 | docs/prd.md | 版本格式 | "版本：待定"不符合 v数字.数字 格式 | 改为 "版本：v0.1" |
| 2 | docs/prd.md | 字段非空 | "产品名称"为空 | 填写实际产品名称 |
### 🟡 警告（建议修复，不阻断）
| # | 文件 | 规则 | 问题 | 修复建议 |
|---|------|------|------|---------|
| 1 | docs/prd.md | 边界声明 | "明确不做"为空，缺少边界 | 至少写一条"本版不做什么" |
### 🔵 提示（最佳实践建议）
| # | 文件 | 建议 |
|---|------|------|
| 1 | docs/项目说明书.md | 「目录结构」建议填写，方便后续维护 |
### 流程审计结果（这一版新增）
| 检查 | 状态 |
|------|------|
| 阶段按序推进 | ✅ 一致 |
| 无假完成（出口门真过） | ❌ S1 标完成但 prd 缺验收 |
| 跳步均已留痕 | 🟡 S1.5 跳过未写理由 |
| 账本与产出物吻合 | ✅ 一致 |
### 项目进度卡审计结果
| 检查 | 状态 |
|------|------|
| 总表存在且非空 | ✅ 通过 |
| 总表只放索引级信息 | ✅ 通过 |
| 模块卡按需下钻 | 🟡 DU02 指向的模块卡不存在 |
| 任务 closeout 三处同步 | ✅ 通过 |
| 状态枚举合规 | ✅ 通过 |
| 下一轮 AI 最小上下文可用 | ✅ 通过 |
### 质量门结果
| 门 | 状态 |
|----|------|
| QG-001 文件存在 | ✅ 通过 |
| QG-002 无占位符 | ❌ 未通过 |
| QG-003 无敏感信息 | ✅ 通过 |
| QG-004 版本号 | ❌ 未通过 |
| QG-005 验收可验证 | ✅ 通过 |
| QG-006 语言检查 | ✅ 通过 |
### 总结
- 错误 X 项，警告 Y 项，提示 Z 项
- 质量门：A/B 通过
- 判定：❌ 不合格，需要修复后重新质检
如果全部通过：
## 质检报告：全部通过 ✅
所有产出物符合治理规范：
- 文件齐全、章节完整、字段合规
- 质量门 6/6 通过
- 跨 Skill 一致性检查通过
可以交付。
.claude/settings.json 中的 hooks，每次写入关键文件后自动提醒| Skill | 关键检查项 |
|---|---|
| vibe-coding-prd | prd.md 必须章节齐全 / 版本号格式 / 产品名称非空 / 验收标准可验证 |
| vibe-coding-requirements | 需求基准描述 80-300 字 / 覆盖四要素 |
| vibe-coding-architecture | 选定技术栈含"选定"和"否决" |
| vibe-coding-production | 安全清单逐条确认 / 验收清单是 checkbox 格式 |
| vibe-coding-survival | 以后再说清单存在 |
| （流程）进度账本 | 阶段按序、无假完成、跳步留痕、账本与产出物吻合 |
| （开发期上下文）项目进度卡 | 默认只读 index、模块按需下钻、任务 closeout 三处同步、状态枚举合规 |
CLAUDE.md 是事前预防——在 AI 开始工作前就告诉它规则harness.json 派生，保持规则一致教非技术背景的人看懂技术架构、做好技术选型——把"只会照搬话术的小白"练成"能看穿方案好坏的人"。 当用户问"该用什么技术/框架"、"帮我选技术栈"、"AI 给的方案我看不懂"、"这几个方案怎么选"， 或者需要把 demo 做成更正经的东西、要理解 AI 提出的架构时，使用此 Skill。 这是 vibe-coding-kit 套件里负责"成长"的核心 Skill：用 6 个大白话维度拷问任何方案，再配五步决策法做选择。 即使用户没明说"架构"二字，只要 ta 面对多个技术方案不知道怎么选、或看不懂 AI 的技术建议，就应主动用本 Skill。
一个"访谈式"的需求 Agent：通过一问一答 + 在岔路口给建议，把一个说不清需求的人，带到一份 AI 能直接照着开工的 PRD。 当用户说"我想做个 XX 但不知道怎么跟 AI 说"、"帮我理需求"、"帮我写个 PRD"、"我有个想法，帮我想清楚再开工"， 或在 Claude Code / Codex 里准备开一个新项目、却还没把要做什么定清楚时，使用此 Skill。 它不是让用户填表格，而是像产品顾问一样访谈：一次只问一件事，遇到用户判断不了的选择（尤其"产品形态"和"技术栈"） 会给出 2-3 个大白话选项 + 推荐一个最简可行的默认 + 一句话讲清代价，等用户拍板。 访谈结束后，直接把 prd.md 和 项目说明书.md 写进项目目录，并提议生成可点击的 HTML 原型。 这是 vibe-coding-kit 套件里"把需求从人嘴里问出来"的交互入口。
把验证过的 Vibe Coding demo，做成能长期运行、给别人用的正式系统。 当用户说"想上线"、"怎么部署"、"这个 demo 想做成正式的"、"要注意安全吗"、"怎么测试我的项目"， 或者准备把代码开源/公开发布时，使用此 Skill。涵盖开发规范、安全基线、部署、手动验收、文档要求。 这是 vibe-coding-kit 套件里负责"从 demo 到上线"的 Skill。 即使用户没明说"上线"二字，只要 ta 准备把一个能跑的东西交给别人用、或放到服务器/公网上，就应主动用本 Skill。
Vibe Coding（用 AI 写代码）项目的第一步：把模糊的想法，变成 AI 能精准落地、不会跑偏的需求。 当用户说"我想做一个 XX"、"帮我用 AI 做个 demo"、"我有个想法想验证"、"帮我跟 AI 对齐需求"， 或者描述了一个还很模糊的软件/工具/系统点子时，使用此 Skill。也用于先判断"这件事到底要不要写代码"。 这是 vibe-coding-kit 套件的入口——只想跑 demo 验证想法的人，通常只需要这一个 Skill。 它不止教你说清"想要什么"，还教你用"数据旅程 + 3×4 提问"把需求补全到考虑周全，避免只描述了"一切顺利"的happy path。 即使用户没明说"规划"二字，只要 ta 准备让 AI 开始写代码、却还没把需求说清楚，就应主动用本 Skill 先做需求对齐。
Vibe Coding（用 AI 写代码）开发过程中的避坑与自救——真正翻车大多发生在"开工后"。 当用户说"AI 越改越乱"、"demo 改坏了退不回去"、"AI 老忘记之前说的"、"功能越加越多很乱"、 "AI 说做好了但其实没用"，或者正在用 AI 持续开发一个项目时，主动使用此 Skill。 涵盖：管理 AI 对话（防忘事）、守住范围（防膨胀）、保住能用的版本（防丢失）、让 AI 证明给你看（防轻信）， 以及哪些事必须找真人工程师的「红线」，和把一切串起来的「项目说明书」。 这是 vibe-coding-kit 套件里贯穿整个开发过程的 Skill，建议从第一行代码起就配合使用。