mcpField
P
paperclip-clarify

paperclip-clarify

github.com/bbengaminAgent 工作流356 次安装11 周前更新
代码仓库

关于 paperclip-clarify

面向 Paperclip 操作人员的技能,可将模糊需求整理为结构化澄清摘要。它逐次提问、按依赖关系梳理决策,并在澄清期间不修改 Paperclip。

主要功能

  1. 01逐次提出一个问题
  2. 02按依赖关系梳理决策
  3. 03记录未决事项的决策台账
  4. 04查阅 Paperclip wiki 来源
  5. 05不修改数据的澄清流程

适用场景

  1. 01澄清含糊的 Paperclip 目标
  2. 02确定范围与成功标准
  3. 03明确审批要求和停止条件

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/bbengamin/skills --skill paperclip-clarify

安装后在 Claude Code 中输入/paperclip-clarify确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
CONTEXT.md
references/docs/paperclip-operator/
control-plane.md
workflow.md

详细介绍

Paperclip Clarify

将模糊的操作意图转化为结构化的澄清摘要。不要修改 Paperclip。

参考资料

请先阅读以下文档:

  • references/CONTEXT.md
  • references/docs/paperclip-operator/workflow.md
  • references/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。

评论

支持 Markdown