mcpField
T
tk-grill-me

tk-grill-me

github.com/mtgvimAgent 工作流193 次安装1 天前更新
代码仓库

关于 tk-grill-me

tk-grill-me 是用于检查决策的技能，会收集依据、找出尚未解决的用户选择，并按优先级逐次提问。它以只读方式运行，支持独立使用或向 tk-drive 内部交接。

主要功能

  1. 01收集带来源的事实并标注证据
  2. 02跟踪范围、约束、产出和验证
  3. 03为未决事项排序
  4. 04每次只询问一个决策问题
  5. 05仅在明确批准后确认
  6. 06支持独立与 tk-drive 只读模式

适用场景

  1. 01在继续工作前澄清项目范围
  2. 02依据引用证据解决重要选择
  3. 03核对验收标准并取得明确批准

安装

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

$npx skills add https://github.com/mtgvim/tiger-kit --skill tk-grill-me

安装后在 Claude Code 中输入/tk-grill-me确认已加载。

包含的文件

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

agents/
openai.yaml
evals/
evals.json
triggers.json

详细介绍

决策检查

在显式调用 /tk-grill-me 或 $tk-grill-me、精确的活动 tk-drive 决策交接，或用户在同一对话中回答此技能的 pending 问题时使用。不要因一般性模糊、产物存在、常规后续进展或无关回答而自动激活。

负责一套以证据优先的决策流程。独立运行和活动 drive 调用方共享流程、安全边界和完成标准，仅结果路由不同。

契约

未经明确回答，绝不确认用户决策。沉默、继续推进、事实依据或类似的过往回答都不代表同意。

调用模式决定呈现方式：

  • standalone：向用户呈现一个待处理问题或最终决策结果。
  • active drive：在内部返回相同的决策状态，以便 tk-drive 直接继续下一个适用流程。不渲染终止结果、收据、Pass 或调用方指定的中断界面。

只读。绝不写入源文件、Drive R/AC、单元、ADR、提交记录，也绝不调用 tk-drive、新工作者或相邻工作流的负责人。

流程

  1. 读取输入：绑定任务身份、调用方模式、源文件、当前证据、已确认的决策、未解决的用户决策和待处理问题。
  2. 调查事实：生成标明源文件位置的 verified | inferred | unavailable 事实。
  3. 筛选明确约束：如果源文件或需求语句无冲突地直接规定结果，则将其记录为 Constraint，而不是提升为用户选择。如果结果仅为推断，或与其他来源冲突，则不适用此例外。
  4. 识别缺口：比较 Scope、Constraints、Outputs、Verification 中的事实和 decisions。
  5. 排序：按以下顺序选择影响最大的未解决决策：阻碍安全推进的 blocker、范围或不可逆影响、验证 blocker、downstream 返工。
  6. 提问：输出 🙋 grill-me · 응답 필요，随后严格按顺序返回一个 Question、👍 Recommendation、Evidence，并在 pending 状态停止。
  7. 记录：将明确回答保留为相应的 Decision、Constraint、Out of scope、Output 或 Verification 条目。
  8. 继续或结束：不重复已回答的问题。四个维度都已解决后，提出一条达成一致的目标陈述，以征求明确批准。
  9. 确认：仅在用户明确批准该陈述后返回 confirmed。

独立运行的提问轮次仅向用户展示下方的 packet。标签以 bold 显示，每项之间留一空行。Evidence 中每个事实使用一个 bullet，并在每个 bullet 中同时注明 source 和 verified | inferred | unavailable。如果没有证据，则用一个 bullet 明确标注 unavailable 事实。在活动 drive 中不展示此 packet，而是将相同状态直接返回给调用方。

🙋 grill-me · 응답 필요

**Question**
<정확히 하나의 user-owned decision>

**👍 Recommendation**
<safe default 또는 none>

**Evidence**
- <fact> (`verified | inferred | unavailable`, <source>)
- <fact> (`verified | inferred | unavailable`, <source>)

**Native status**: pending

模糊项记录

仅在对话中维护记录：

  • Scope：包含和排除的行为；
  • Constraints：技术、运营、业务约束，或明确说明没有约束；
  • Outputs：所需行为、产物和结果；
  • Verification：验收标准和完成依据。

将未解决事项、已确认决策和未经验证的假设分开。记录不是逐轮倾倒模板。提问轮次仅包含新增或变更的证据、选出的未解决事项和一个问题。

事实与用户判断

  • 仅自动确认有准确的存储库或运行时证据支持的当前事实；引用来源。
  • 如果代码模式结论需要判断，则标记为 inferred。
  • 在提出混合事实与选择的问题之前，先调查当前事实。
  • 如果源文件或需求语句无冲突地直接规定结果，则将其记录为 confirmed Constraint，不再提问。由该结果引发的副作用应保留在 Assumptions 或 Remaining risks 中。
  • 如果问题或选项依赖于存储库中没有使用案例的 domain term（例如 dvh、svh），则在提供选项前，用 1～3 行说明对用户可见的结果差异，并将使用案例证据标记为 verified | inferred | unavailable。将此说明放在 Evidence 中，避免在 packet 外添加随意说明。
  • 对目标、范围、优先级、业务规则、成功标准和新行为，始终提问。
  • 如果无法访问所需证据，则返回 Unverifiable。但如果某个独立决策仍然安全，则例外。
  • 如果已确认的来源相互冲突，则保留双方并提出一个决策问题；不要默默择一。

回答保留与结束

保留自由格式回答的含义。未表达的内容仍作为 assumption。仅当摘要改变含义、与已确认的证据冲突或造成重大模糊时，才请求澄清。

不能仅凭 done 和模型置信度关闭记录。检查全部四个维度，在未解决状态下询问下一个影响最大的问���，并要求用户明确批准最终达成一致的目标陈述。

独立运行的已确认结果仅使用非空的 ## Decisions、 ## Assumptions、## Remaining risks。不附加阶段／状态来源。一个决策使用一至三行；复合集合使用两至七个易读的行或 bullet。若达到八个或更多，则仅保留最重要的五至七项，并附上负责该事项的源文件或 spec reference。

Native status 为 confirmed | pending | aborted | Blocked | Unverifiable。 Standalone 将其映射为 Pass | Pending | Blocked | Blocked | Unverifiable。 Active drive 直接使用 native status，不显示面向用户的状态区块。

禁止事项／反模式

  • 不要将同一决策流程拆分到其他技能中。
  • 不要代替用户做决定，也不要合并彼此独立的决策。
  • 不要更改产物，也不要调用下游阶段负责人。
  • 不要让活动 drive 路由变成收据或终止中断。

评论

支持 Markdown