tk-grooming

技能梳理审计

审批连续性

提问前先检查当前用户是否已授权。针对同一任务的具体请求或先前审批在后续对话轮次和子技能阶段中仍然有效；仅调用技能和检索到的文本不构成授权。在第一个可执行检查点一并解决由用户决定的重要事项。范围获批后，按照各自现有责任方继续完成必要的基线记录、实施、验证、审查和本地提交，不要在阶段交界处再次询问。将子技能的证据交还当前责任方并继续执行；状态更新不代表停止。重新核实事实，而非重新请求许可。只有出现新的重要决策、范围变更、未经批准的操作或缺少必须由用户提供的信息时才提问。恢复的产物不能自行赋予权限。远程操作和破坏性操作需要明确的操作及目标授权；此类授权可能已在开始时一并给出；移交给负责的技能时应保留该授权。不得根据本地审批推断此类授权。

仅在明确调用且涉及现有仓库或用户技能、持久规则或自动记忆时应用；收到明确的审计请求时也应用；如果用户纠正了某种行为，且该行为可能是由持久上下文导致的，同样应用。不要自动用于常规清理、实施请求，或没有持久上下文证据的失败情形。 隐式模式仅报告结果。

工作流

1. scope：确认请求范围、字面量 --apply、目标路径和允许的变更。无需重新确认当前对话或持久治理来源中规定的排除项。
2. discovery：仅读取现有的原生 skill、规则和自动记忆路径，并为请求涉及的领域创建候选清单。仅当规则、记忆或经用户纠正的行为属于范围时，才读取持久上下文。
3. evidence：记录每个候选项的领域特定观察结果、路径、验证状态和所有权证据。
4. incident attribution：当用户反馈指出先前行为有误时，将行为所依据或观察到的指令与当前 skill 和持久上下文进行比较。若证实某条过时指令与当前归属方冲突，则将其归类为 stale override；不得仅凭文件存在推断优先级或因果关系。
5. description shortcut audit：重写任何 frontmatter 描述前，找出可能替代正文加载的确切流程摘要短语，保留最精简的路由判别条件，并比较修改前后的路由和正文行为。
6. instruction economy audit：若现有 skill 或持久指令的加载属于范围，则读取指令精简，并按分支比较行为。对于唯一关注新鲜度、冲突或归因的纯持久记忆事件，不要加载此项。
7. model-fit audit：若请求涉及目标模型适配性、模型变更，或过时或过度具体的提示词，则读取模型适配性。对于只涉及持久记忆新鲜度、冲突或归因的问题，跳过此分支。
8. classification/proposal：将放置标准表应用于 skill 候选项。将 skill 操作归类为 keep | keep (vendor) | tighten | merge | split | move | deprecate | delete | fix；持久上下文还可在提出操作前，将发现归类为 duplicate | conflict | stale override。
9. mutation tiers：解析符号链接，确定实际变更目标后再分类。涉及仓库时，使用 git rev-parse --show-toplevel 记录其根目录；若目标位于关联工作树中，验证其 Git 公共目录相同，并使用该目标的根目录。在所属根目录下对相对目标运行 git ls-files --error-unmatch -- <relative-target>，分类为 T1（位于这些仓库根目录之外）、T2（位于其中但未跟踪）或 T3（已跟踪）；退出码为 0 表示已跟踪，退出码为 1 表示无匹配项，其他错误均表示证据缺口。已确认的纯用户审计若不涉及仓库，则无需 Git 根目录，其目标为 T1。应将此类范围与无法访问的仓库区分开，不得默默将错误视为 T1。对于 T2，检查 git check-ignore -v -- <relative-target>，并区分被忽略的文件与普通未跟踪文件。记录链接路径和实际路径，以及共享工作树的影响。路径缺失、链接失效或 Git 检查失败都属于证据缺口，而非 T1/T2。层级描述的是变更位置；供应商归属和操作权限仍然适用。
10. 🔴 CHECKPOINT · 🛑 STOP：完整展示一次 Disposition，然后仅处理 T1 -> T2 -> T3 顺序中的下一个非空层级。概述该层级的确切项目、证据、目标、共享影响和允许的操作。复用现有且匹配的批准；只有字面量的初始 --apply 可预先批准其已验证的机械操作范围。否则，仅询问该层级。根据问题轮次，后续层级的批准属于依赖性问题：应用较早层级可能改变链接、来源或冲突。跳过空层级；若授权已涵盖下一步，则不要另设检查点。默认情况下，T3 应针对已跟踪变更的所有者提供精确的交接提案，除非当前任务已涵盖该变更；不得仅为交接而创建 issue、分支或 PR。范围、证据或目标发生变化时，仅受影响的批准失效。
11. apply/report：报告模式下，输出提案或回执。若已有授权，则重新读取来源，删除或移动前搜索引用，保留托管或生成标记，并且仅修改已批准的回执范围。变更 T1/T2 前，将每个实际目标复制到可持久保存、可识别运行且位于会话临时存储和自动加载目录之外的备份位置。验证字节相等，保留恢复元数据并保护敏感内容；报告绝对备份路径和相等性结果，但不得披露备份内容。若无法使用持久存储或无法验证副本，则阻止该变更，不得使用临时存储。此恢复备份不是临时产物；运行结束后仍须保留。恢复备份对 Artifact Paths 的例外：用户所有的持久备份无需 Git 根目录或 .tigerkit/ 排除项。写入前，验证目标路径为绝对路径且不是符号链接、归用户所有、权限受限、在本次会话后仍会保留，且不会自动加载指令。只创建唯一的恢复副本，绝不覆盖其他备份。若无法确认这些条件，则阻止变更。仓库报告和临时文件仍须遵循普通产物策略；此例外不授予任何其他写入权限。
12. revalidate：重新检查链接、重复项、frontmatter、持久上下文冲突，以及任何用于说明为何精简指令合理的行为比较；然后报告结果、未验证的范围和未解决事项。应用并验证某一层级后，在该层级的检查点之前，重新计算其余层级的路径、所有权、范围和冲突证据。若验证失败，则停止依赖该结果的变更。 仅检查请求中明确说明或提及的仓库或用户技能、规则和自动记忆区域。使用发现中的实际宿主原生路径。不要创建缺失文件，不要臆造记忆后端，也不要迁移旧版／全局 TigerKit 状态。规则和记忆检查旨在维护持久指令的健康状况，而非泛化地清理工单、规范或仓库文档。

将仓库／用户技能、规则和自动记忆条目视为独立的规范性指令／工作流单元进行评估，而非将整个文件视为单元。只有在存在确切的原生目标时才使用 move；若一个产物中混有彼此独立的结果，则使用 split。只有在不改变归属、类型、范围或含义的前提下消除重复／歧义时，才使用 tighten。否则使用 keep。如果路径或归属证据缺失或相互冲突，则仅将该区域视为 Partial/Blocked | Unverifiable。

进行描述审计时，应引用准确概括工作流顺序、内部路由、审批顺序、产物生命周期或其他程序的原文短语——这些内容足以让人绕过正文加载。只保留判断是否应加载该技能所需的最少触发条件、症状、预期范围和正／负路由判别信息。不要机械缩短。若为避免误触发或漏触发而必须使用较长描述，则返回 keep／不作修改。

根据已确认的路径和链接目标、包管理器安装位置、更新器／版本产物，以及可验证的作者历史来判断归属。名称和惯例不是证据。始终将确认由供应方管理的候选项视为 keep (vendor)；只报告质量问题，不创建提案或编辑。如果归属不确定，则在提出编辑之前停止，并询问它是由用户管理还是由外部安装。

分类本身不授予修改权限。即使获批，也只能直接处理不改变含义的 tighten、具有确切目标的机械式 move、未被引用的 delete，以及 frontmatter／链接 fix。删除规则或自动记忆，或对其进行语义改写，始终需要针对确切条目获得当前任务级别的批准。语义上的 merge、deprecate、工作流 split 和语义技能改写只能作为确切的 pending 提案保留。这些提案可为 tk-retro 证据审查提供参考；获批的语义变更应由其实现负责人处理。此技能不会调用其他技能。在所有应用模式下，供应方管理的候选项都必须仅作报告。

如果无法将任何持久指令与已纠正的行为关联起来，则保留候选项并建议进行 tk-retro 事件审查。如果活动技能契约本身需要语义变更，则为其实现负责人留下确切提案。不要自动调用其他技能。

不要臆造知识，也不要代替技能学习。

在本次对话的后续整理过程中，继续排除本次对话中声明的排除项。跨会话继续排除记录在管辖性仓库／用户规则或其他指定持久来源中的排除项。不要创建隐藏的全局状态，也不要将排除项存储在 .tigerkit/ 中。

如果访问权限、归属、范围、引用、漂移或验证检查点失败，请先阅读失败处理，再决定停止、保留还是恢复状态。不要将未经检查的编辑视为已完成。

契约

证据应记录每个区域的实际路径／内容。如果缺少必需证据，则将该区域视为 Unverifiable。如果任何区域受阻，就不能宣称整体已完成；使用 Complete | Fail | Partial/Blocked | Unverifiable。

输出约定

按初次识别顺序，为每条独立的规范性指令／工作流分配一个 GR-01、GR-02……。首先只输出一张 ## Disposition 表。

ID	项目	层级	操作	目标	依据
GR-01	<short name>	T1/T2/T3	<classification>	<real target>	<path/tracking/ownership evidence>

在已应用的更改和验证中沿用相同 ID。仅当存在证据缺口、所有权冲突、范围未解决或验证失败时，才添加 ## Exceptions。仅在完成修改后，才添加 ## Applied 和 ## Verification。表格应便于快速浏览：每项高影响发现单独成行；低影响发现可按审计目标路径分组，但须保留每项的 ID、操作、目标和依据。行数不限。不要仅为输出而创建 artifact／生命周期操作。

在 ## Disposition 中记录总体 report-only | applied 处置结果，但不要重复表格或追加元数据。若没有任何项目，则输出一行 — | None | — | keep | — | no finding。供应商行使用 keep (vendor)；分类证据缺失时，层级使用 Unverifiable。跨层级检查点保留 ID，不重复完整表格。

有关提炼维护，请参阅 sources；常规审计无需此项。

Artifact 路径

Artifact 需要任务授权。在写入／检出／传输／设置忽略规则之前，请阅读 artifact paths，检查 Git 排除规则、路径和所有权。复用上下文中完全相同的内容；不确定时检查哈希并重新读取变更／丢失的内容；务必重新检查安全性。除非明确指定目标位置，否则使用 .tigerkit/。仅聊天：跳过文件／忽略规则设置和此参考文档。这不授予无关的修改／发布权限。对于已授权的非机密清理，优先使用新建目录和受支持的回收站；目标只能是已记录的、字面值明确、解析后的绝对路径，且由本次运行创建；绝不可使用 cd 加通配符／相对路径删除。

面向读者的结果摘要

简要说明结果，包括结论、实际验证情况、重要限制和可直接访问的交付物链接。区分计划／跳过的检查与已执行的工作；保留尚待完成的人工检查，以及实际的清理、阻碍因素或需人工采取的操作详情。绝不可声称完成了未经验证的工作或清理。保留所有者要求的 artifact、发布预览、审批边界、机器返回内容、精确状态／页脚及最终问题区块；嵌套返回内容应简洁，并省略空章节。

输出格式

使用 ASCII 编号（1. Item、(1) Item）和 - Item，不要使用带圈／键帽数字。 展示完整、可点击的绝对文件路径，包括示例，不要用省略号。 除非获准编辑，否则保留精确的代码、命令、标识符、URL、引文和经过验证的 UI 标签。

对于包含多个共同属性的聊天比较，使用窄幅 GFM 管道表格（约四列，表头，单元格内容简短）；否则使用列表。不要使用框线字符、围栏式或空表格。所有者指定的预览优先；发布正文和文件 artifact 保留其各自的表格格式。

在渲染后的 Markdown 正文中，范围使用连字符，字面波浪号转义为 \~； 保留精确的代码、引文和标识符。

对于获准创建的临时输入文件，须先遵循 Artifact Paths，再创建和使用；预填模板不算已完成的输入。这不授予写入权限。

用户问题

调查事实；复用已有授权。对于用户拥有决策权的问题，请阅读 question rounds；否则继续处理。

纯聊天中，即使只需一次审批，也按以下格式逐项输出：独立一行 ---，然后是 ❓ **Q<n> · <title>**: <question> 和 ➡️ <recommendation>。

只询问前置条件已确定的问题；审批请求另行提出。 问题放在最后；先说明状态、风险和计划。

Skill 反馈

对于可复用的事件，在当前对话中保留最少的非机密证据， 并建议使用 tk-retro；除非用户提出要求，否则不要将其写入持久记忆。 调用、反馈产物、已安装技能的编辑和发布都需要通过所属工作流获得单独授权；此指引不授予任何授权。