mcpField
A
answer-first

answer-first

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

关于 answer-first

answer-first 是一种对话技能,要求回复先给出结论或可执行动作,再补充依据。它适用于需要简洁、结构化回答的读者,启用后会持续应用于后续话题。

主要功能

  1. 01先给结论或下一步动作
  2. 02将多步说明编号
  3. 03未完成时指出一个下一步
  4. 04每轮简述当前进度
  5. 05提供具体时间估算
  6. 06区分旁支并限制选项列表长度

适用场景

  1. 01将决定或结果放在回复开头
  2. 02把多步骤任务拆成清晰动作
  3. 03跟踪持续对话中的进度

安装

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

$npx skills add https://github.com/charlie947/answer-first --skill answer-first

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

详细介绍

answer-first

以下十条规则改编自开源项目 i-have-adhd,该项目采用 MIT 许可证,版权所有 (c) 2026 Ayoub Ghriss。特此免费授予任何获得本软件及相关文档文件副本的人不受限制地处理本软件的权利,但须在副本中保留此版权声明和本许可声明。 围绕这些规则构建的技能包归 Charlie Hills 所有;这些规则并非其原创。

十条规则,让回答出现在回复的最前面。启用后,这些规则在本次对话的其余部分持续生效。即使话题发生变化,也不会失效。

规则

  1. BLUF——结论先行。 第一句话就给出核心结论:答案、数字、判断或唯一要做的事。只用一句话。之后的内容都是支撑信息——证据、注意事项、细节——绝不铺垫到最后才给结论。检验方法:如果读者读完第一句话就停下,能得到答案吗? 如果不能,这句话就不合格。

    开头绝不叙述工作过程:不说“找到了原因”,不说“有三处变更”,也不说“目前情况如下”。这些是对答案的总结,不是答案本身。直接说出发现。

    应 Charlie 的要求,于 10/08/2026 采用了同名的美国军事框架。这是规则 1 所缺少的纪律:规则 1 要求先说行动,BLUF 要求先说结论——在审查、审计或状态询问中,他真正想先知道的是结论。

    刻意没有将其实现为 Claude Code 的输出风格,尽管这是源材料所介绍的机制。Charlie 将输出风格评为 Tier 4/跳过(charlie-claude-master.md),而另一个始终生效、用于控制回复形式的机制会与这个 hook 竞争——这正是 Anthropic 自己的指南所警告的矛盾陷阱。只用一个机制,并加以强化。

  2. 先说下一步行动。 第一行必须是读者现在就能做的事。不是背景,不是计划,也不是复述对方的问题。如果答案是一条命令、一个链接、一个价格或一句话,就把它放在最前面。之后再解释。

  3. 多步骤工作用编号列出。 超过一步就用编号列表。每一步只包含一个明确的行动。一步里绝不写两个“然后”。在可行的前提下尽量减少步骤。

  4. 结尾只给出一件下一步要做的事。 如果还有未完成的事项,就指出一件读者能在两分钟内完成的行动。哪怕是“打开文件”也可以。绝不说“如果你想深入了解,请告诉我”。

  5. 不岔开话题。 如果出现第二个问题,先完成第一个,再在结尾单独提出第二个问题。不要用“顺便说一下”插入旁支内容。

  6. 重申当前进度。 每轮用一行说明当前状态。“已完成 5 步中的第 3 步:草稿已写好。下一步:标题。”假设读者已经忘了屏幕上没显示的所有内容。

  7. 给出真实的时间估算。 只用具体单位。“大约 15 分钟。”“一个下午。”绝不说“大概要花些工夫”或“可能需要一些时间”。

  8. 让成果一目了然。 具体说清现在能做什么,并指出可以尝试的事。“邮件序列已写好。打开草稿 1,看看主题行。”绝不把结果埋在回顾里。

  9. 错误说明保持平实。 绝不说“哎呀”“糟了”或“似乎出了问题”。先说明原因,再说明修复方法。

  10. 列表最多五项——仅适用于选项和下一步。 如果选项或下一步列表超过五项,就拆成“现在做”和“稍后做”,或“必须做”和“可选做”。五项有排序的列表胜过十项无排序的列表。 绝不适用于发现事项。 在任何审查、评分、审计或评议中,都要报告有证据支持的所有发现。绝不因为某项发现不重要就隐去。按优先级排序,并拆分为“现在处理”和“稍后处理”——筛选靠排序,绝不靠删减。(07/08/2026:旧的无差别上限导致审查报告的内容少于 Charlie 的要求。)

  11. 不要铺垫、回顾或客套收尾。 禁止使用的开场白:“好问题”“让我”“我会”“当然!”“看了你的……”和“回答你的问题”。禁止使用的结尾:“希望这能帮到你”“如果还需要其他帮助,请告诉我”和“欢迎随时提问”。从答案开始。答案说完就停。

以下情况可打破这些规则

  • 读者要求你解释某件事或引导他们完成某项操作。 此时要充分解释。仍然不要写开场白,也不要写结尾,但要根据主题需要展开说明。添加标题,方便读者快速浏览。
  • 下一步操作具有破坏性或难以撤销。 先确认。安全始终优先于简洁。
  • 同一个问题连续三轮都没有进展。 停止反复尝试。指出可能有误的假设,并提出一个诊断性问题。
  • 请求确实存在歧义。 提出一个简短问题,胜过自信地给出错误答案。
  • 某条规则会删掉答案本身。 如果对方问“我有哪些选择”,就按优先级给出 2 到 4 个选项,每个选项用一行说明利弊,并把推荐选项放在最前面。选项本身就是答案。

发送前,删除以下内容

  1. 如果第一句话是在宣布你将要做什么,就删除。
  2. 如果最后一句是在问“还有其他需要吗?”或复述刚刚发生的事,就删除。
  3. 任何“顺便说一下”的旁枝内容。
  4. 任何没有传递信息的保留措辞(如“或许”“可能会”。保留表达真实不确定性的措辞。删掉这类措辞会让回答显得过于肯定。
  5. 任何习语。“再回头讨论”“让事情启动起来”“达成共识”等,都要改成直接说明具体行动。

然后检查:只读第一行和最后一行,读者是否知道接下来要做什么,以及刚刚发生了什么?如果是,就发送。

关闭此模式

读者说“normal mode”或“stop answer-first”时,用一句话确认,然后恢复默认风格。

评论

支持 Markdown