메뉴
需求门禁（Requirements Gate）——只要用户提出开发需求或变更请求（实现 / 新增 / 开发 / 加一个 / 修改 / 重构 / 优化 / 接入 / 修复 / add / implement / build / feature / fix），哪怕措辞很随意，且该任务还没有 status: approved 的 story.md，就必须在写任何代码之前使用本技能。不要因为需求看起来很简单而跳过。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
文档自动维护（Docs Maintenance）——git commit 前，凡本次改动对应的 story 已 verified 且其 design.md 影响面涉及架构 / 设计 / 约定变更，必须使用本技能。文档已覆盖变更则跳过——本技能的产出是文档与代码一致，不是每次都改文档。
Use when dispatching independent subagents via opencode CLI in the Journal repository, especially for verification-gate, requirements-gate, or docs-maintenance tasks where context isolation and standardized report output are required.
验收门禁（Verification Gate）——与 requirements-gate 成对的下游环节：需求门禁确保做对的东西，验收门禁确保做的东西是对的。开发完成、准备 git commit、或想宣称'做完了'之前，凡存在与本次改动相关、status: approved 但尚未 verified 的 story.md，必须使用本技能。注意：测试全部通过不等于验收通过——技术正确性归 verification-before-completion，需求符合度归本技能。
文档自动维护（Docs Maintenance）——git commit 前，凡本次改动对应的 spec 已 verified 且影响面涉及架构 / 设计 / 约定变更，必须使用本技能判断并同步更新 AGENTS.md / ARCH.md / DESIGN.md，并按需维护 README、llms.txt、用户使用说明与技术开发说明文档。当 PreToolUse hook 注入「文档维护」提醒时必须使用。文档已覆盖变更则跳过——本技能的产出是文档与代码一致，不是每次都改文档。
"灵感探讨的思维搭档。用户抛出模糊设计想法（"帮我想想 X 怎么做"、"纠结 A 和 B 方案"、"你觉得这样做怎么样"、"帮我过一遍思路"）、要对比方案、或需要把碎片需求拆成清晰设计决策时触发。过程工具，边聊边在浏览器里画探索画板（黑白点阵风格），不是产出最终文档。如果用户已有成型日志要转可视化长页，改用 visual-design-book；写代码前所有"还没想清楚怎么做"的环节都应先走 ideate。"
维护 identity/ 下任何档案前必须加载。定义人物五维度画像、
| name | requirements-gate |
| description | 需求门禁（Requirements Gate）——只要用户提出开发需求或变更请求（实现 / 新增 / 开发 / 加一个 / 修改 / 重构 / 优化 / 接入 / 修复 / add / implement / build / feature / fix），哪怕措辞很随意，且该任务还没有 status: approved 的 story.md，就必须在写任何代码之前使用本技能。不要因为需求看起来很简单而跳过。 |
把模糊的开发需求逼成一份无歧义、纯用户视角的 story.md：只回答"谁、在做什么事、现状为何失败、做完后什么变了、不做什么"，不碰"怎么实现"。实现方案（技术选型、接口、NFR、依赖、架构）交给下游 brainstorming 产出 design.md。
核心原则——用户视角校准：任何描述方案的输入（"做一个 X 功能""加 Y 按钮"）必须先反推到用户问题。脊柱不通过，不进解决方案讨论。这是本技能与"PRD 润色 prompt"的根本区别。
| 文件 | 视角 | 谁产出 | 内容 |
|---|---|---|---|
| story.md | 用户视角（"要什么"） | 本技能 + 用户确认 | 用户故事、背景与失败模式、成功标准、GWT 验收、三类边界 |
| design.md | 实现视角（"怎么做"） | brainstorming / 开发阶段 | 方案选型与 tradeoff、接口/数据契约、NFR、技术异常分支、架构决策 |
归属铁律："不做什么"是 story（用户意图），"怎么实现这个不做"是 design。例：「不为大客户启用」写 story 非目标；「has_dedicated_cs=true 跳过」的实现写 design。需实现知识才能回答的问题（用什么存储、如何回滚、接口长什么样），不在本技能职责内——记入交棒清单，转 design.md。
入口路由 ──→ (BRIDGE) ──→ 脊柱五问 ──→ 输出闸 ──→ story.md
│ forcing gate hard gate
│ (拦方案/拦泛指) (拦越界/拦模糊)
└─ KPI/数字目标走 BRIDGE，其余直入脊柱
三道关卡缺一不可，强度由分级调节，但没有任何一级可以跳过脊柱 Q1 与 Q5、跳过输出闸。
PM 输入的五种典型翻车，本技能逐一设防（完整识别信号与处理见 references/failure-modes.md）：
| 翻车原型 | 信号 | 防线 |
|---|---|---|
| A 解决方案当需求 | "做一个 X 功能""加 Y 按钮""老板说" | 脊柱 Q1 拒绝方案 → 反推 JTBD |
| B 用户=所有人 | "用户希望""很多用户反馈"，无定语 | 脊柱 Q1 连环追问到具体角色+场景 |
| C 业务目标硬转译 | KPI/OKR/"提升 X% 留存"直接接需求 | 入口 BRIDGE：强制 ≥2 行为变化假设 |
| D AI 自由发挥 | 没写"不做的事"，AI coding 越界生成 | 输出闸：Won't 是模板必填字段 |
| E 看起来全但模糊 | 8 页 PRD，"更方便""性能良好""体验流畅" | 输出闸：INVEST 6/6 + GWT 硬门 |
分级决定问多深，脊柱决定问什么。两者正交：
| 级别 | 适用 | 脊柱与输出闸 |
|---|---|---|
| L0 跳过 | 非开发请求；已有 approved story 的延续；用户标注 [skip-gate] | 忽略门禁 |
| L1 轻量 | 琐碎修复：typo、改文案、单行 bug、配置 | 脊柱快速走（Q1/Q4/Q5 必答，Q2/Q3 可一句话带过）；输出闸照跑 |
| L2 标准 | 常规新功能 / 功能变更 | 完整脊柱五问 + 输出闸 |
| L3 深度 | 触碰数据契约 / 权限 / 计费 / 对外 API / 不可逆迁移 / 跨团队指标 | 完整脊柱 + 多角色分派（references/review-dimensions.md）+ 输出闸。这些高风险维度属实现层，门禁只识别并标记到交棒清单 |
拿不准取高不取低。
判断 PM 输入是哪类，决定从哪进（完整规则 references/entry-routing.md）：
| 入口 | 信号 | 路由 |
|---|---|---|
| 业务目标 | 含 KPI / 数字目标 | 先走 BRIDGE（references/bridge-step.md），再进脊柱 |
| 草稿体检 | 已有 PRD 草稿 | 对照脊柱扫描，缺哪问追哪问 |
| 模糊想法 / 用户反馈 | 短句、转述、零散反馈 | 直入脊柱 Q1 |
优先用 rga 检索：仓库内相关模块/接口/配置；stories/ 及 brainstorming 输出目录下的历史 story.md / design.md；AGENTS.md / docs 既有约定。证据（文件路径+一句话结论）写入 story 背景节。检索为空也是信息——全新领域，假设风险更高。
任何路径最终都要走完五问，缺一不可（完整 prompt、追问规则、PM 答非所问的拦截见 references/spine-prompts.md）：
| # | 问题 | 通过标准 | 锚定 |
|---|---|---|---|
| Q1 | 谁 + 在做什么事 | 具体角色（不是"用户"）+ 具体场景（不是"使用产品时"） | JTBD |
| Q2 | 现在怎么解决 | ≥1 条现有路径（"放弃"也算） | — |
| Q3 | 为什么失败 | 具体失败模式，不接受"体验差""不方便" | 5 Whys |
| Q4 | 做完后什么变了 | 可观察的用户行为指标 + 数字目标 | Outcomes |
| Q5 | 不为谁、不做哪些场景、不解决哪些相关问题 | 三类边界都要答 | MoSCoW |
Iron Law：Q1 不通过不进 Q2。 任何 Q 答得抽象，必须重述、追问、不放行。Q1 拦截不是 block 一次，而是 block + JTBD 重述 + 展开方案空间——让 PM 看到"原来不止那一种解法"，这是本技能的核心价值瞬间。
脊柱过程中冒出的实现层问题（用什么存储、如何回滚降级、性能上限、依赖哪些系统），不在 story 里拍板——按 references/handoff-checklist.md 归类，记入 story 交棒清单转 design.md。门禁的价值是不让实现层缺口被忽略，而非替用户和 AI 做实现决策。
生成 story 前必须通过（完整审计逻辑 + 修复建议库 references/invest-audit.md）：
用 assets/story-template.md。存放位置跟随 brainstorming 输出约定，皆无约定时默认 stories/<YYYYMMDD>-<slug>/story.md，design.md 同目录。初始 status: clarifying。
story 写作双重职责：背景讲故事（人读友好）+ AC 用 GWT（机读可测）。验收标准规则：
[已废弃]向用户输出（一屏内）：readiness 等级（草稿/待澄清/可开发，定义见 references/review-dimensions.md）；最优先 3–5 个意图层缺口；需用户拍板的问题；交棒清单（移交 design.md 的实现层问题）。
用户确认后 status 改为 approved。approved 之前不写实现代码。 随后：
/plan），把 story.md 与 design.md 路径写进计划首行verified三条主路径的完整对话样例见 references/walkthroughs.md，演示脊柱如何连环拦截、BRIDGE 如何强制、输出闸如何修复——拿不准某一步的手感时去读对应走查：
| 走查 | 入口 | 演示 |
|---|---|---|
| A | 模糊想法 | 老板说"做个 AI 助手" → Q1 拦方案 + 拦泛指 → 重述真实问题展开解空间 → story |
| C | KPI 目标 | "次留 +5%" → BRIDGE 强制 ≥2 假设 → 对比解空间锁定 → 转译进脊柱 |
| E | 草稿体检 | 8 段模糊 PRD → 脊柱扫描戳破篇幅假象 → 输出闸逼出 GWT 与边界 |
| 借口 | 纠正 |
|---|---|
| "做一个 X 功能"就是需求 | X 是方案不是需求。脊柱 Q1 拒绝方案输入，反推到"谁+在做什么事+为何失败" |
| "用户希望……"够具体了 | "用户"不是角色。追到"哪类用户+在做什么事"，否则落入 B 翻车 |
| "提升 X% 指标"直接做 | KPI 是结果不是需求。进 BRIDGE 强制 ≥2 假设，看见"选错假设=做错产品" |
| 跳过 Q3 直接谈方案 | 不回答"为什么现状失败"，方案就是无的放矢 |
| 把"体验更好"写进验收 | 改成 GWT，给可测条件和数字阈值，否则输出闸 fail |
| 顺手把实现方案写进 story | story 只写"要什么"。实现进交棒清单 → design.md，混进来就是越层 |
| Won't 段落先空着 | Won't 是给 AI coding 的护栏，必填，空 = 输出闸 fail |
| 快模式跳过 INVEST | INVEST 永远是 hard gate。快模式省追问，不省质量底线 |
| PM 给一个假设就走完 BRIDGE | 强制 ≥2，对比解空间——一个假设看不见机会成本 |
| "我理解用户的意思了" | 理解 ≠ 共识。写下来被用户确认过的才是共识 |
[证据]/[推测] 标注脊柱 Q1=JTBD（Christensen）；Q2-3=5 Whys（Toyota）；BRIDGE=Opportunity Solution Tree（Teresa Torres）；用户故事=Connextra+INVEST（Bill Wake）；验收=GWT/BDD（Dan North）；边界=MoSCoW（DSDM）。
安装与 hook 注册说明见同目录
INSTALL.md（面向人类读者，不属于技能上下文）。