产品
在构建前验证功能需求
一份决策备忘录，测试拟议功能是否解决已核实的用户或业务问题，并选择构建、探索、推迟或拒绝。
流程
按这个顺序做。
- 说明拟议能力、预期结果、受影响用户、决策期限、当前替代方案，以及哪些证据会改变决策。
- 收集用户行为、支持证据、研究、产品数据和业务背景，区分用户提出的请求与观察到的需求。
- 把需求映射到用户任务、频率、严重性、战略契合、限制，以及不解决问题的成本。
- 设计最小且安全的发现测试，例如原型、礼宾试验、带埋点的漏斗或客户对话，并设定成功与停止标准。
- 比较自建、购买、流程变更、推迟和拒绝方案的预期价值、成本、可逆性、风险与学习价值。
- 记录决策、信心、负责人、日期、假设、反证，以及会触发变更的后续测试或指标。
- 交付包含证据和未解决风险的备忘录，并在承诺支出、让用户暴露或宣布构建决策前暂停。
先准备
猫会向你要的输入。
- 功能提案与目标结果
- 用户与业务证据
- 替代方案与限制
- 决策负责人与测试时间范围
路由器 + 一份 playbook
先路由。只选一份。
Cat Paw 每次任务只加载一份 playbook，不合并多份。先走这个路由器；其余路径是此 workflow 可检查的候选。
- 路由器：
minimal-code-pack skills/minimal-code-pack/feature-necessity-decision/SKILL.md
界限
界限跟着提示一起走。
- 开始前核实实际工具、账号、权限和工作区；绝不声称拥有不可用的工具、账号、来源或能力。
- 私有代码、产物、实时探测或非公开数据使用 Latch/target-workspace；如果无法访问，就在边界停止并报告阻塞，不要用猜测替代。
- 任何有后果的外部行动前先暂停并取得明确批准；返回证据、未解决风险、假设以及仍等待批准的行动。
完成代表
一个可核对的终点。
可复核的需求验证备忘录建议构建、探索、推迟或拒绝，并附用户证据、替代方案、信心、后续测试和明确的未解决风险。
来源
这个流程从哪来。
- github.com/DietrichGebert/ponytail/tree/e3ba2aa6f1e6f0bc4d69eb09c9f0d0a93af56156/
- www.gov.uk/service-manual/user-research
- www.gov.uk/service-manual/service-assessments
来源确立 workflow 的模式。如有 Reddit 或社区帖子，视为实务轶事，不是普遍事实。
