mcpField
T
tk-reflect

tk-reflect

github.com/mtgvimAgent 工作流142 次安装今天更新
代码仓库

关于 tk-reflect

tk-reflect 是用于审视对话、仓库和记忆证据并识别可复用规则或技能候选项的技能。它会分类证据、评估可信度并报告建议;修改须另行批准,且不会创建或编辑技能。

主要功能

  1. 01审查变更、结果和相关记忆
  2. 02按五类目标分类证据
  3. 03区分已验证事实与解释
  4. 04评估可信度并建议行动
  5. 05应用变更前要求批准

适用场景

  1. 01从实现证据中提取可复用规则
  2. 02检查仓库候选项是否重复现有指导
  3. 03按需记录范围受限的反思报告

安装

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

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

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

包含的文件

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

test-prompts.json
agents/
openai.yaml
evals/
evals.json
triggers.json
references/
drive-optimistic.md
repository-placement.md

详细介绍

反思

仅在明确调用、明确要求从证据中提取可复用候选项,或存在一个有效的主动驱动尾部交接时应用。不要自动应用于普通摘要或实现完成的情况。隐式模式仅报告。 除以下单次、有界的诊断交接外,不要调用其他技能。

阅读当前对话、变更、差异、实现/测试/审查结果、相关的 .tigerkit/ 产物、当前宿主可发现的基于文件的持久化记忆,以及用户指定的来源。严格按五个维度分类——repo rule | repo skill | user rule | user skill | persistent memory——并选择 propose | update | merge | no-op | discard。

工作流

  1. evidence:提供附有路径/命令引用的 verified | unverified 事实,包括访问失败和既有成果检索结果,并按五个维度分类。
  2. interpretation:从事实中推导复用假设,并与事实分开。
  3. confidence:返回 high | medium | low 及其依据。
  4. action:对仓库候选项应用放置准则,选择目标和操作。措辞由单独的 Draft 负责。
  5. apply/receipt:结合候选项、单独审批和最新目标状态,得出转换表结果并附上引用;不要复制候选项正文。

驱动尾部模式

只有包含 Mode: drive-optimistic、Success state: Pass 和 Outstanding transition: final receipt 的交接,才授予乐观驱动反思中限定的权限。该模式只能应用符合条件的现有 repo rule,写入 .tigerkit/reflect.md,绝不提升技能,并返回 Return to: tk-drive 以及原样返回 Outstanding transition 的值。缺少授权或授权不匹配时,不得进行任何变更,也不能返回驱动尾部成功回执。

条件式 Agent Skill 诊断

在提升依赖根因的 propose | update | merge 候选项之前,仅当以下四个条件都已验证时,才交接给 tk-skill-diagnose,且恰好交接一次:

  1. 明确的 Agent Skill 名称或精确的 SKILL.md 路径;
  2. 可观察到预期/实际结果不匹配,或测得资源异常;
  3. 根因尚未验证;
  4. 候选操作取决于该根因成立。

请求必须明确涉及技能故障、其回顾总结,或复用该故障证据。不要因历史提及、已有有效诊断回执、no-op | discard 或一般性反思而交接。 如果宿主原生的同级交接不可用,则返回 Diagnosis required 载荷和 Unverifiable;绝不要在此处伪装成新鲜的实证诊断。

发送确切的事件 ID、目标/路径、宿主/调用方式、观察到的提示词、预期行为或资源锚点、观察到的行为/指标、证据路径/命令、候选项/基线引用,以及 Caller: tk-reflect。将未知项标为 unverified。

收到返回后,只能将 Reproduced 与已验证的根因用作证据。 Not reproduced 不能验证原始因果主张。 Inconclusive | Blocked | Unverifiable 会使置信度保持为 low,并阻止依赖根因的提升。效率证据还必须保留正确性。一次运行中绝不重复调用诊断;对于相同的 Incident ID + target + blocker,不得再次调用诊断,也不得允许诊断回调 reflect。若出现等同的重复情况,则以 Blocked 结束。

候选转换表

此表适用于独立反思和普通隐式反思;驱动尾部转换使用其参考文档中的 资格、恢复和回执表。

候选项条件状态变更
规则 `proposeupdatemerge`单独批准应用之前
规则 `no-opdiscard`无内容可应用reported
规则 `proposeupdatemerge`批准后已应用/重新验证精确目标
规则应用/重新验证失败`FailBlocked
技能候选项已展示证据、精确目标和工作草稿pending不创建/不进行语义变更
所有候选项没有已验证的证据Unverifiable无

每个候选项都包含:

  • Evidence:带有路径/命令以及 verified | unverified 状态的已观察差异/结果/重复情况。
  • Interpretation:仅根据 Evidence ID 推导出的复用范围/边界假设;不得使用指令性措辞,也不得将假设表述为事实。
  • Confidence:high | medium | low,Basis: <Evidence IDs>,并且仅在需要时添加 Uncertainty。
  • Action:存在重复内容时优先选择 merge | no-op。规则是简短的常驻指令;技能则需要具备触发条件、重复步骤、I/O 和独立价值。

按以下顺序选择 Action:现有目标已完全涵盖 → no-op;同一目标缺少已验证的边界 → update;合并重叠目标 → merge;没有合适目标且符合规则/技能资格 → propose;一次性内容或尚未解决的未验证/冲突证据 → discard。Action 不代表拥有应用权限,所有技能候选项都保持 pending。

将可发现的基于文件的持久记忆视为已有内容,而非自动写入目标。当记忆已完全涵盖相同行为和范围时,选择 no-op。当记忆与候选项共享事实但涵盖不同的行为维度时,在 Interpretation 和 Action 中记录这种区分,保持目标分离,并且仅在两个精确目标都已知时提出相互交叉引用。交叉引用或记忆变更在单独批准之前仍为 pending。如果宿主记忆路径不可用或无法读取,将其记录为 unverified;不得声称记忆中不存在已有内容。

对于 repo rule | repo skill,Evidence 负责保存规范化的原始放置输入,Interpretation 负责界定根目录/嵌套目录/技能边界,Action 负责作出选择。不要创建重复的放置字段。阈值证据缺失/冲突时,置信度保持 low,并阻止提升状态。

置信度只能按以下方式提升:high 至少需要两个来自不同出现情形/来源类型且独立验证的 Evidence ID,并且不存在尚未解决的冲突/反例;medium 至少需要一个已验证的 ID,但缺少重复性、独立性或边界中的一项;没有已验证的证据,或存在尚未解决的冲突/反例时,置信度为 low,且无法提升为 propose | update | merge。

Contract

仓库范围目标因代码库/领域/工具/团队而异;用户范围目标会跨仓库重复。持久记忆是当前主机上基于文件的目标,必须展示其原生路径。默认仅报告。将规则写入 DESIGN、reuse-map、rule 或持久记忆文件,需要单独明确批准,并注明目标和范围;符合条件的现有仓库规则在有效的 drive-tail 模式下除外。沉默、继续操作、过去类似的回答或单独调用 reflect 均不构成批准。

只有 tk-learn 可以创建新技能或在语义上更新/合并技能。此技能仅报告技能证据、当前主机上的原生精确目标、工作草稿,以及 pending;绝不会调用 tk-learn 或写入技能路径。

运行终态为 Pass | Pending | Fail | Blocked | Unverifiable | aborted。可执行候选项等待应用处置时使用 Pending;完成无操作/仅报告,或重新验证后的变更完成时使用 Pass;确定性声明被违反或应用门槛未通过时使用 Fail;用户停止时使用 aborted;存在冲突/应用范围不明确时使用 Blocked。绝不可将每个候选项的 reported | pending | applied 与运行终态混用。

默认不修改任何文件,也不创建日志。明确请求报告产物时,可以写入下文限定范围内的 .tigerkit/reflect.md 日志;有效的 drive-tail 模式可在其自身限定授权范围内写入相同日志。不要检查旧版全局状态,也不要将一次性变通方案泛化。RF-## 是单次运行内的标识,不是持久标识。即使获得批准,也绝不可原样提升原始凭据、日志或屏幕截图。

必需来源无法读取时,应标为 unverified,注明路径/错误,且不得据此进行解读。只有在出现精确的访问方式/路径/命令后,才重试一次;否则使用 Unverifiable。应用/重新验证失败按状态转换表处理。

CHECKPOINT / STOP

在有效的 drive-tail 模式之外,必须先取得单独的明确应用批准,且应先说明目标、证据、置信度和操作。在此之前,停留在 pending | reported。drive-tail 模式遵循其资格条件和回滚检查点,无需提问。

Output contract

按发现顺序分配 RF-01、RF-02、……。在对话中仅输出 ## Disposition;只有需要应用批准时,才在其后插入决策问题。处置表最多显示五行与决策相关的条目:

ID候选项操作目标原因
RF-01<short name><action/status><target><evidence refs>

引用证据路径,而非复制冗长正文,以保持对话精简。每个 Action 和 Why 单元格都必须说明人类可读的下一步操作及其原因;仅有 RF-## ID 或状态标记不构成结果。最多保留五行;其他候选项由 .tigerkit/reflect.md 记录时,应引用该文件。无操作结果保持精简。 仅当可执行的规则/技能候选项需要工作措辞时,才在 ## Disposition 中添加限定范围的 Draft 块。

仅在 drive-tail 模式之外明确请求报告产物,或有效的 drive-tail 移交时,才写入或替换 .tigerkit/reflect.md。独立日志每个候选项占一行,包含 ID、目标、证据引用、解读、置信度、操作、状态以及可选的草稿路径;drive-tail 字段遵循其参考规范。不得包含原始日志、对话记录、差异摘录、重复理由或复制的输出字段。按需创建其父目录,并以原子方式写入;若 scratch 未被忽略,则发出警告;绝不修改 .gitignore。 日志记录终态、候选项数量、日志自身路径,以及需要决策的 ID;对话摘要不得替代处置表,也不得追加这些元数据。没有候选项时,输出一行 — | None | no-op | — | no verified reusable evidence。

🔴 硬性门槛 · 可执行的用户输出

将技能的规范输出契约视为模式,并将此门槛视为其呈现层。绝不删除或重新排列必需的标题、表格、ID、状态标记、结果限额、审批或安全边界、宿主要求的进度通知或响应语言规则。将响应语言规则应用于每个自由格式子句和文字结果值;仅在规范标记、代码标识符、命令、路径或精确引用或源文本字面内容中保留其他语言。常规工作流术语属于文字,而非代码标识符:除非更改标记会导致含义错误,否则应予以翻译。

在第一个可用的自由格式文本位置,直接给出答案、结果或操作,不要先写引言。对于多步骤用户工作,使用尽可能少且范围明确的编号步骤。对于持续进行的工作,重述当前状态和下一步转换,不要重复计划或结果。明确说明已完成的行为。说明错误时,应描述观察到的故障、已知且有证据支持的原因,以及具体的恢复方式;绝不捏造原因。

省略离题内容、客套开场、重复回顾和结束寒暄。如果必填字段重复了已陈述的结果,应使用指代性或尽量简短的值,而不是再次复述。若工作尚未完成,结尾只给出一个由用户或工作流负责执行的具体下一步操作;若工作已完成,则直接结束,不要凭空编造下一步。仅当有证据支持且有助于执行步骤时,才提供具体时间估计。

当此门槛与规范输出契约或宿主测试框架冲突时,遵循优先级更高的契约,并在其第一个文本值或位置中应用相同格式。不要给用户贴标签、提及此门槛、暴露持久模式,也不要要求提供此技能以外的运行时引用。

🔴 硬性门槛 · 最终用户摘要

将进度说明、内部交接信封和最终用户响应视为不同的输出界面。在每条面向用户的最终响应的第一行之前,准确输出一行独立的 ---,然后立即开始技能规定的结果标题或结果句。不要在进度说明中输出此分隔符,也不要在成功阶段回执与下一阶段主动执行调用之间输出此分隔符。

不要在用户摘要中输出回执标题、Outcome: 标签或最终来源/状态信息块。如果宿主或技能要求提供最终状态,应在所属结果部分中输出唯一一行精确的 Status: <token>,而不是在底部添加元数据块。仅当路径、ID、提交或恢复详情会影响用户操作,或技能的规范结果模式要求时,才予以公开。将阶段回执作为内部交接信封处理:如果上级工作流要求阶段、状态、ID、Return to、Success state 或 Outstanding transition,只将这些内容返回给该上级工作流,绝不要在最终用户摘要中复述。

仅在技能已有的工件或账本中保存来源信息。没有此类存储位置的技能不得仅为保存回执而创建一个;只读技能必须继续保持只读。绝不要要求提供此技能以外的共享运行时引用。

🔴 硬性门槛 · 响应语言

在提供任何面向用户的进度、问题或摘要之前,根据用户最近一次明确的语言指示确定响应语言;若无此类指示,则使用当前用户消息的语言。所有面向用户的自由格式句子和文字结果值都必须使用所确定的语言,不要因为来源、技能正文、工具或代码使用英语就切换到英语。规范标题、状态标记、ID、命令、路径、代码和精确引用或源文本字面内容必须保持字节级不变;保留标记的同时,用所确定的语言解释其含义。返回前,检查所有面向用户的自由格式文字,并重写任何偏离所确定语言的句子。

用户决策问题

当用户拥有的决策阻碍进展时,在任何Recommendation之前,先提出一个完整、独立的Question。只展示与决策相关的证据、两个或三个互斥且权衡点明确的选项,并且恰好为一个选项添加以(Recommended)或(추천)结尾的标签。

如果提供了原生结构化输入,请使用:Claude Code 的AskUserQuestion、Codex 的request_user_input或 Hermes Agent 的clarify。只有在未提供这些输入时,才允许使用纯文本。调用失败或被拒绝不等于未提供;请保留Pending | Blocked。这只改变呈现方式,不改变权限或停止关卡。

禁止事项/反模式

  • 不要把解读当作事实,也不要夸大信心。
  • 不要重复创建已有技能,也不要在未经应用审批的情况下修改内容。
  • 不要在先前成果检查中遗漏可发现的持久记忆,也不要凭空编造未发现的宿主记忆路径。
  • 不要直接进行诊断,不要重复诊断交接,也不要创建反思/诊断循环。
  • 不要推广原始凭据/日志/屏幕截图或一次性变通方案。
  • 不要遗漏、重用或重新编号候选 ID,也不要遗漏 Summary。

评论

支持 Markdown