关于 tk-to-spec
tk-to-spec 是一项仅在明确触发时运行的技能，会将可读取的来源证据整理为当前仓库中的自包含规格文档。它保留证据溯源与不确定性，并在审批边界停止，不修改实现或远程状态。
主要功能
- 01仅手动触发
- 02写入 .tigerkit/spec.md
- 03记录主张与来源的关联
- 04区分事实、决策和未验证主张
- 05记录缺失证据与冲突
- 06需明确批准才能标记为就绪
适用场景
- 01将 issue 和仓库调查整理为规格文档
- 02记录验收标准与验证证据
- 03在实现前记录相互冲突或缺失的需求
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/tk-to-spec确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
agents/openai.yamlevals/evals.jsontriggers.json详细介绍
将 Evidence 转换为 spec
仅在明确选择 /tk-to-spec 或 $tk-to-spec 时执行。输入是可实际读取的 source evidence，例如
对话、issue、artifact、repository 调查结果等。不得调用其他 skill，也不得修改实现、ticket 或远程状态。
输出约定
仅当存在有效的 source evidence 时，才写入当前 repository root 的 .tigerkit/spec.md，
并先通过 git rev-parse --show-toplevel 确认 root，然后在结果中报告从该 root 派生的
实际绝对路径。文档必须是自包含的 Markdown，并直接包含以下内容：
Status: Pending（用户明确批准前，下游不得使用）- source/R-AC 和 lineage（每项主张与来源之间的关联）
- goal、scope、exclusions、constraints
- acceptance criteria 和 verification 命令/证据
- 分别标明 facts、confirmed decisions、unverified claims
- missing evidence 和 conflicts 及其影响
- 说明文字和标题使用韩语书写；仅准确的字段、状态、ID、命令、路径、URL 和字面文本保留原文。
流程
- 阅读 source，并将每句话分类为
Fact | Confirmed decision | Unverified claim。 - 不填补缺失信息，将其记为
Missing evidence。将矛盾及双方依据、解决负责人记为Conflict，并将状态设为Blocked或Unverifiable。 - 编写 goal/scope/排除项/约束/acceptance/verification/lineage。技术字面文本、 变更路径和失败条件也保持原文不变。
- 保存前确认文档是自包含的，并设有审批边界。用户批准后，仅凭该明确批准即可将
Pending改为Ready。
即使信息不足，也要创建自包含文档，注明缺失项和绝对路径，然后以
Status: Unverifiable 停止。若 conflict 尚未解决，则保留双方依据，并以
Status: Blocked 停止。不得在 .tigerkit/ 以外创建 state、
archive/current pointer/global 设置。
边界
一般计划编写、实现、ticket 拆分和简单提问不触发此流程。不得将事实提升为推断，也不得将 Pending 文档作为下游输入传递。
评论
支持 Markdown