tk-to-spec について
tk-to-specは、明示的に起動した場合のみ、読み取り可能な根拠を現在のリポジトリ内の自己完結した仕様書にまとめるスキルです。根拠の出所と不確実性を保ち、承認境界で停止し、実装やリモート状態は変更しません。
主な機能
- 01手動起動のみ
- 02.tigerkit/spec.mdへの書き込み
- 03主張と根拠の対応付け
- 04事実・決定・未確認の主張を区別
- 05不足する根拠と矛盾の記録
- 06明示的な承認後にReadyへ変更
活用シーン
- 01issueやリポジトリ調査を仕様書に整理
- 02受け入れ基準と検証根拠の記録
- 03実装前に不足・矛盾する要件を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/tk-to-specを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
agents/openai.yamlevals/evals.jsontriggers.json詳細
エビデンスを spec に変換
/tk-to-spec または $tk-to-spec が明示的に選択された場合にのみ実行します。入力は、
会話、issue、artifact、repository の調査結果など、実際に読み取れる source evidence です。
他の skill を呼び出したり、実装・ticket・リモート状態を変更したりしません。
出力契約
有効な source evidence がある場合にのみ、現在の repository root にある .tigerkit/spec.md に書き込みます。
まず git rev-parse --show-toplevel で root を確認し、結果にはその root から導出した
実際の絶対パスを報告します。ドキュメントは、次の内容を直接含む self-contained な Markdown である必要があります。
Status: Pending（ユーザーが明示的に承認するまでは、downstream は消費しません）- 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として記載します。矛盾がある場合は、両方の根拠と解決 owner をConflictとして記載し、状態をBlockedまたはUnverifiableにします。 - goal/scope/除外事項/制約/acceptance/verification/lineage を記述します。技術的なリテラル、変更 path、失敗条件も原文のままにします。
- 保存前に self-contained であることと、承認の境界があることを確認します。ユーザーが承認した場合は、その明示的な承認のみで
PendingをReadyに変更できます。
情報が不足していても self-contained なドキュメントを作成し、不足項目と絶対パスを明記したうえで、
Status: Unverifiable で停止します。conflict が解消されていない場合は、両方の根拠を保持して
Status: Blocked で停止します。.tigerkit/ 以外に state、
archive/current pointer/global 設定を作成しません。
境界
一般的な計画の作成、実装、ticket の分解、単純な質問では起動しません。事実を 推論へと昇格させず、Pending のドキュメントを downstream の入力として渡しません。