关于 paperclip-clarify
面向 Paperclip 操作人员的技能,可将模糊需求整理为结构化澄清摘要。它逐次提问、按依赖关系梳理决策,并在澄清期间不修改 Paperclip。
主要功能
- 01逐次提出一个问题
- 02按依赖关系梳理决策
- 03记录未决事项的决策台账
- 04查阅 Paperclip wiki 来源
- 05不修改数据的澄清流程
适用场景
- 01澄清含糊的 Paperclip 目标
- 02确定范围与成功标准
- 03明确审批要求和停止条件
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ bbengamin/ skills --skill paperclip-clarify安装后在 Claude Code 中输入/paperclip-clarify确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/CONTEXT.mdreferences/docs/paperclip-operator/control-plane.mdworkflow.md详细介绍
Paperclip Clarify
将模糊的操作意图转化为结构化的澄清摘要。不要修改 Paperclip。
参考资料
请先阅读以下文档:
references/CONTEXT.mdreferences/docs/paperclip-operator/workflow.mdreferences/docs/paperclip-operator/control-plane.md
如果缺少这些项目文档,请先运行 paperclip-setup,从随附模板创建这些文档。
流程
将此流程作为 Paperclip 专属的深度访谈。
每次沿决策树推进一个分支,先解决依赖项,再处理依赖于它们的决策。例如,在预期结果明确之前,不要澄清问题范围;在影响范围明确之前,不要澄清自主程度;在成功标准具体明确之前,不要澄清验证方式。
每次只提一个问题,等待操作者回答,然后选择下一个最具影响力的分支。每个问题都要提供你建议的答案,方便操作者快速接受、修改或否决。绝不要在同一轮中捆绑多个问题。
如果能从代码库或 Paperclip 状态中查明答案,就检查代码库或状态,而不是提问。
如果操作者提供了 Paperclip wiki URL、wiki 页面路径或作为背景资料提供的 wiki 源内容,那么在提出 wiki 内容能够解答的问题之前,使用 paperclip-wiki-fetch 阅读相关内容。如果缺少 wiki 访问详情,只询问最少的必要信息,并确保澄清过程不会修改任何内容。
不要浅尝辄止。除非输入已经异常明确,否则一次有效的访谈通常需要多轮。如果问题少于 5 个,应对此保持警惕:在结束之前,确认自己不是只接受了标签,却没有真正理解工作内容。
在整个过程中维护一份精简的决策记录:
- 已确认:已解决到足以据此制定计划的事实和决策。
- 假设:你建议的答案,但操作者尚未明确确认。
- 待决分支:仍未解决且会影响后续决策的事项。
- 矛盾:意味着范围、所有权、验证方式、自主程度或停止条件彼此不兼容的答案。
根据决策记录选择下一个问题。如果答案解决了一个分支,却暴露出某个依赖项,就先处理该依赖项,再转向其他分支。
在对上下文和主题形成可用的整体理解之前,始终处于澄清模式。不要因为操作者回答了前几个问题,就转而开始规划、拆解、实施或修改 Paperclip。
总结前的最低要求:
- 除非以下每个必需领域都已得到明确回答,否则至少针对每个领域提一个问题。
- 如果答案中包含“安全”“完成”“设置”“E2E”“Agent”“审查”“后端”“前端”“数据库”“自主”或“自给自足”等含糊词语,应继续追问。
- 对过于宽泛的目标提出质疑:要让第一个 AFK 循环成功,必须满足什么条件?
- 用具体场景检验计划:干净检出、缺少密钥、E2E 失败、架构变更、依赖项不稳定、Agent 受阻、部分实现以及审查者拒绝。
- 检查矛盾和缺失的上下文:如果两个答案暗示的范围、所有权、验证标准或停止条件不一致,就继续提问,不要试图将其一概而论。
- 总结前,确保能够复述第一个具体的 AFK 循环、它应关联的控制平面对象、明确排除在范围外的事项、证明成功的证据,以及必须让 Agent 停下来的条件。
- 总结前,检查决策记录。每个会影响后续的分支都必须已确认、有意列为待解决问题,或降级为非阻塞假设。
- 如果预期结果、范围、验证方式、自主程度或停止条件仍存在重大歧义,就不要生成最终总结。
需要明确:
- 预期结果
- 重要性
- 范围
- 非目标
- 成功标准
- 目标用户或操作者
- 约束
- 风险
- 自主程度
- 必要审批
- 验证要求
- 停止条件
- 待解决问题
问题库
将这些问题用作提示,而不是照本宣科。每次只提出最有价值的下一个问题。
- 这项工作应关联到哪个确切的 Paperclip Company、Goal、Project 或现有 Issue?
- 怎样的结果才能让操作人员认为第一个 AFK 循环成功了?
- 第一轮明确不包括哪些内容?
- 哪些现有 Issue 是权威依据,哪些仅供历史参考?
- Agent 可以在无需询问的情况下更改哪些内容:前端、后端、数据库、基础设施、文档、测试、密钥、外部服务?
- 什么情况必须停止并向看板提问?
- 将 Issue 标记为完成前,必须进行哪些验证?
- 从全新检出开始,必须具备哪些本地设置?
- 需要哪些密钥、服务、迁移、种子数据、浏览器或测试命令?
- 已经出现或可能出现哪些故障模式?
- Agent 应在评论或制品中留下哪些审查证据?
- 如果 Agent 无法在本地运行完整验证,应如何处理?
- 哪些决策可以撤销,哪些决策必须在实施前获得批准?
- 什么情况会使计划中的 Issue 范围过大,不适合 AFK 执行?
输出
最后附上澄清摘要:
## Clarification Summary
### Outcome
### Why This Matters
### Scope
### Non-Goals
### Success Criteria
### Constraints
### Risks
### Autonomy Level
### Required Approvals
### Validation
### Stop Conditions
### Open Questions
然后询问是否继续进入 paperclip-record-strategy。
修改规则
切勿通过此技能创建或更新 Paperclip goals、projects、issues、approvals、skills 或 comments。