产品需求沟通 / 需求讨论完善 / 产品需求澄清 / 澄清 PRD / 需求对齐会 / 需求讨论会后整理 / 用户故事 / 验收标准 / 产品意图 / 需求不清楚 / clarify requirement / requirement discussion —— 交付物是「这需求到底要什么」:意图、目标用户、成功标准、用户路径、意图级非目标、功能点验收点、拷问问题池、决策关闭 backlog。Skip 要的是现状清单(现有流程·页面·API·数据·运营规则怎么运作、已有什么能力、缺口在哪)→ requirement-baseline;要的是变更边界(in/out、受影响对象、依赖、版本切片、appetite)→ requirement-scope;要成文 PRD → requirement-doc-writer;一问一答拷问 → grill-me;已有 spec/PRD 实质内容写错要改对(substance 修正,非澄清)、多阶段交付计划 → product-rd-workflow。
Scanned 9/2/2026
Install to Claude Code
npx -y skills add ccoalm/ccl-skills --skill requirement-intent --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Requirement Intent?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ccoalm-requirement-intent)More formats (shields.io, HTML) on the badges page.
---
name: requirement-intent
description: 产品需求沟通 / 需求讨论完善 / 产品需求澄清 / 澄清 PRD / 需求对齐会 / 需求讨论会后整理 / 用户故事 / 验收标准 / 产品意图 / 需求不清楚 / clarify requirement / requirement discussion —— 交付物是「这需求到底要什么」:意图、目标用户、成功标准、用户路径、意图级非目标、功能点验收点、拷问问题池、决策关闭 backlog。Skip 要的是现状清单(现有流程·页面·API·数据·运营规则怎么运作、已有什么能力、缺口在哪)→ requirement-baseline;要的是变更边界(in/out、受影响对象、依赖、版本切片、appetite)→ requirement-scope;要成文 PRD → requirement-doc-writer;一问一答拷问 → grill-me;已有 spec/PRD 实质内容写错要改对(substance 修正,非澄清)、多阶段交付计划 → product-rd-workflow。
---
# Requirement Intent
把不清晰的产品意图变成可关闭的决策:已知/未知、用户路径、意图级非目标、可观察验收点、拷问问题池。需求对齐会后整理、缺哪些信息、写 PRD 前补齐目标用户与约束时进入本技能。
## 硬约束(先读,全程适用)
1. **证据不足不得写成事实。** 每条结论标来源;缺来源的事实交 `requirement-baseline`,不自行推断。
2. **描述性证据不决定产品承诺。** 代码、数据、配置只补事实,不裁决产品口径。
3. **关闭表只补自己那部分。** 唯一 canonical 是 `requirement-doc-writer/references/requirement-closure-contract.md`。本技能只补用户价值、问题、方案关联、产品口径、路径和验收字段,逐字段记录 closure_method/source、decision_authority 和所需 decision_evidence,**只提出行状态候选,不得把整行设为 `closed`**。
4. **自动填写的边界。** 仅凭可引用的已批准 policy,才可以 `bounded-agent-policy` 为 decision_authority 批量确定单个 `low-risk-default` 非核心字段;没有该 policy 时保持 open 或转 `human-decision`。不得升级为核心承诺。
5. **PRD Ready 不由本技能判。** 完整 PRD 正文只有在完整 lifecycle 判定 `PRD Ready` 后才转 `requirement-doc-writer`;未关闭时只交接关闭表和下一动作。
6. **「非目标」在这里是意图级**——本轮不追求的目标、容易被误解成目标而排除的诉求。变更级的「本轮不改哪些对象」属 `requirement-scope`。同理「验收」在这里是功能点的 pass/fail 条件,不是切片验收边界。
### 安全 4 问(命中即阻断)
需求涉及身份、计费、配额、租户/用户隔离、权限、删除、覆盖时,澄清记录必须逐项包含安全 4 问的答案(无命中则显式记"无安全敏感输入")。命中上述任一项时,必须先读取 `requirement-doc-writer/references/security-four-questions.md`(问题本体 canonical,含本技能的落点细则)再作答,并在产物中写明所依据的 canonical 文件名 `security-four-questions.md`(实测:要求一段**固定字样**的旧写法命中率仅 20.5%,而逐项作答与写明来源文件分别可达 82% / 59%——本仓无法机械校验运行时产物,故只要求可核的实质,不要求不可核的字面戳);凭记忆或转述作答、未写明来源、或命中后仍记"无命中",均为违规。**读取不可得时(本会话无文件读取工具 / 文件缺失 / 读取失败)走这条路径,不得声称已读**:改写 `依据: 不可得(<原因>)`;按常驻反射尽力作答、本节标 `interim` 并写出解除方式,缺口连同风险标签交 `feature-risk-router`,由风险 owner 决定是否接受**推迟**——接受的是推迟、不是关闭:本节转正式关闭仍须真实读取 canonical 后逐项重答;agent 与需求提出方均不得自行判为已关闭。always-on 常驻反射见 agent-context/session-start.md「设计期安全 4 问」;本节只定义产物落点与交接。
命中后把风险标签与 gate 选择转给 `feature-risk-router`;进入研发交付时转 `product-rd-workflow`。
## 产出
| 模块 | 内容 |
| --- | --- |
| 已知 | 已确认的用户、场景、目标、约束、事实来源 |
| 未知 | 阻塞问题、需确认对象、默认假设 |
| 用户路径 | 触发入口、主路径、异常/取消/回退路径 |
| 非目标(意图级) | 本轮不追求的目标、容易被误解成目标而排除的诉求 |
| 验收点 | 可观察的通过/失败条件,不复述功能名 |
| 讨论闭环 | 沟通记录、争议点、已决策、未决项、下一轮问题 |
| 拷问问题池 | 可用于 `grill-me` 的一问一答压力测试问题、推荐默认值、错判代价 |
| 需求点关闭表 | 按共享契约记录合理性、产品口径、验收和待关闭项 |
## Workflow
1. 定位意图:记录用户目标、目标用户、触发场景和成功标准。
2. 检查需求合理性:逐项判断问题是否真实、方案是否直接关联问题、是否有替代或更小方案、核心价值能否闭环、范围投入是否经济、失败代价是否可接受。
3. 主动补全:按共享契约完成一轮有界取证 pass,再升级权威冲突、额外授权和人类决策项。
4. 拆用户路径:主路径、分支、异常、退出和撤销路径。
5. 分离事实与假设:每条结论标注来源;缺来源的事实交 `requirement-baseline`。
6. 明确意图级非目标并整理讨论:分开记录争议、已决、未决和下一动作。
7. 更新 `需求点关闭表`(按硬约束 3、4):只知道 owner 而没有明确决定记录时保持 open/blocked。
8. 最小化追问:批量处理可自动项后,只提出一组仍阻塞的 `human-decision` 问题;每题给候选方案、推荐、代价、accountable owner 和受影响 requirement/P0。Agent 维护完整机器账本,产品人员无需逐格填写。需要一问一答压力测试时转 `grill-me`。
9. 写验收点并交接:每个功能点至少一个可观察 pass/fail 条件;安全命中项补负向验收;把完整关闭表交回 lifecycle 或下一窄 owner。
## 不用本技能,改用谁
- 要现状清单(现在怎么运作、有什么能力、缺口在哪)→ `requirement-baseline`。
- 要变更边界(in/out、受影响对象、依赖、切片、appetite)→ `requirement-scope`。
- 把结论沉淀成 PRD / 需求文档正文 → `requirement-doc-writer`(且须 lifecycle 已判 `PRD Ready`)。
- 一问一答压力测试、只追问一个阻塞决策 → `grill-me`;本技能只生成问题池并整理拷问后的结论。
- 技术实现计划、研发排期、跨阶段生命周期 → `product-rd-workflow`。
- 已有 spec/PRD 实质内容写错要改对(substance 修正)→ `product-rd-workflow`:改实质是变更重入,不是意图澄清;只动措辞不动实质才是 `tighten-doc`。
- 结构化测试用例 / Feishu TC → `test-artifact-management`;测试层与验证策略 → `testing-strategy`。
- 风险定级、灰度、必跑 gate → `feature-risk-router`。
## 完成标准
逐条可核,缺一条即为 `interim` 而非完成:
- 产品意图、目标用户、成功标准三者都有明确记录,或明确列为 `human-decision` 待关闭项。
- 每个功能点至少有一个**可观察的** pass/fail 验收条件(不是「体验更好」这类不可判定表述)。
- 已知与未知分开;每条已知有来源,每条未知有 accountable owner。
- 用户路径含异常/取消/回退,不只主路径。
- 关闭表没有任何整行被设为 `closed`;自动填写项都能指出所依据的已批准 policy。
- 安全 4 问:记了「无命中」,或四项逐条答案 + 写明所依据的 canonical 文件名;读取不可得时写了 `不可得(<原因>)` 并把本节标 interim。
## 输出模板
```text
需求澄清结果
- 产品意图:
- 目标用户 / 场景:
- 已知事实(含来源):
- 未知 / 待确认(含 owner):
- 用户路径:
- 非目标(意图级):
- 沟通记录 / 争议点:
- 已决策 / 未决项:
- 下一轮问题 / 拷问问题池:
- 需求合理性:问题真实性 / 方案关联 / 更小方案 / 价值闭环 / 范围经济性 / 失败代价
- 需求点关闭表:
- 验收点:
- 安全 4 问:无命中 / <逐项作答四项>
- 依据来源:<读到了写 `security-four-questions.md`;没读到写 `不可得(<原因>)` 并把本节标 interim。不得留空>
- 下一步 owner:
```
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!