CyrilLeMat/temper-skills

Temper-Skills (ライブラリモード)

エージェントスキルやプロンプトの決定ロジックを、決定論的なPythonに変換します — 推論時にLLM呼び出しはゼロ。インストールされたtemper-skills CLIを駆動することで実現します。CLIをオーケストレーションし、その出力を中継します。ライブラリがテンパリング（硬化）を行います。自分で決定木を書く必要はありません。

このスキルは、ループを自分で実行するためのネイティブなサブエージェント/タスクプリミティブがない場合に使用してください。Claude Code内では、サブエージェントモードのスキルを優先してください（キー不要でライブパネル付きで動作します）。このモードは代わりにCLIにシェルアウトします。

使用するタイミング

• .md スキル、システムプロンプト、またはプレイブックに、テスト可能で、PRで差分表示でき、モデル更新に対して堅牢であるべきルーティング/決定ロジック（構造化入力に対するif-this-then-that）が含まれている場合。
• 適しているもの: チケットルーティング、分類ルール、適格性チェック — 事前計算可能な特徴量に対するカテゴリカルな決定。
• 適さないもの: 連続スコアリング、テキスト生成、またはモデルが到達できるドキュメントがないロジック。

絶対的なルール

1. 常にCLIを介してライブラリを呼び出すこと。決定ロジックを自然言語で再実装して、実行の代わりとしないこと。
2. スキーマの承認を決してスキップしないこと。 あなたが承認するスキーマは、ループがその後共進化させるナイーブなシードです（schema_criticがそれを成長させ、earn-a-branchガードが剪定します）。そのため、シードでの静かな抽出エラーはすべてを台無しにします。ターミナルが接続されていない場合でも、以下のファイルベースのゲート（--propose-schema）を使用してください。共進化したスキーマと、CLIが最後に出力するschema gaps / schema grew のメモを確認してください。
3. 決して静かにインストールしないこと。 ゲート（Step 0）がライブラリまたはバックエンドがないと報告した場合は、pip install を実行したり環境を変更したりする前にユーザーに確認を取ってください。
4. 決定木が「正しい」と決して主張しないこと — 決定論的で監査可能であることのみを主張してください。正しさはユーザーが責任を持ち、承認された例によって確立されます（validate、Step 4）。
5. CLIのゲートと判定結果をそのまま中継すること — 監査判定、ペルソナパネル、グレーゾーン、承認待ちのケースなど。これらを要約して省略しないでください。

Step 0 — インストールとバックエンドの確認

python scripts/check_install.py を実行し、終了コードで分岐します:

• 0 — 準備完了、続行。
• 10 — インストール済みだがモデルバックエンドがない。ユーザーに伝える: temper-skills にはバックエンドが必要です — ログイン済みの claude または opencode CLI、または環境変数 ANTHROPIC_API_KEY が必要です。どのように提供したいかユーザーに尋ねてください。バックエンドが存在するまで続行しないでください。
• 11 — インストールされていない。 尋ねる: 「temper-skills がインストールされていません。今すぐインストールしますか？ (pip install temper-skills)」 明示的な確認があった場合のみインストールします。

Step 1 — guide でトリアージ（ここが起点）

決定ロジックを含む .md ファイルまたはプロンプトを見つけ（曖昧な場合はパスをユーザーと確認）、ワンコマンドツアーを実行します:

temper-skills guide <path/to/skill.md> --json

ユーザーがディレクトリを指定した場合（スキルライブラリ）、1つのファイルをガイドする代わりにそれをスイープします — 監査はそれ自体で報告する価値のあるレポートです:

temper-skills audit <dir> --json --report audit.md

ランク付けされた結果を中継します（JSONはスキルごとのレポートのリストで、最もアクションが必要なものが先頭）。トップピックを guide することを提案します。audit.md はPR用の共有可能なMarkdownバージョンです。

常に --json を渡してください。 guide と ingest は機械可読なマニフェストをstdoutに、人間向けのRichパネルをstderrに出力します。マニフェストを読み、パネルをスクレイピングしないでください。guide のマニフェストは以下の通りです:

{ "audit": { "verdict": "...", "recommended_action": "...", ... },
  "action_taken": "temper|decompose|...",
  "status": "compiled|stopped_for_ratification|action_not_auto_run",
  "final_skill_path": "...", "artifacts": ["..."] }

guide はスキルを監査し、その後 recommended_action に従います。監査の判定結果とアクションをユーザーに中継してください:

• temper — 1つのツリー形の決定。guide がテンパリングします（高速）; status: compiled。
• decompose — フロー（2つ以上の決定）。guide は決定ごとのスキーマを出力し、停止します; status: stopped_for_ratification。
• externalize_data / build_normalizer / delegate_prose — テンパリングの対象外です。status: action_not_auto_run; アクションヒントを中継して停止します。

guide はツアーです: quick プロファイルを実行し、推論されたスキーマを自動承認します。これは「これが何をするのか見せる」には問題ありませんが、ユーザーが依存する決定木の場合はStep 2に進み、スキーマが承認されるようにしてください。

Step 2 — 保持可能な決定木を生成する（承認フロー）

2a. スキーマをドラフトし、承認のために停止する

temper-skills ingest <path/to/skill.md> --propose-schema --json

これにより schema.proposed.py が書き込まれ、停止します — ループは未承認のスキーマでは実行されません。stdoutのJSONから {proposed_schema_path, fn_name, features:[{name,type,description}], constraints} が得られます。提案された特徴量をユーザーに表示し、次の1つだけを尋ねてください: これらの特徴量を承認しますか、それともリストを編集しますか？ ユーザーの編集を schema.proposed.py に適用します。

ここでユーザーに他のことを尋ねないでください — 特徴量の幅やどのブランチを保持するかなど。剪定はループの仕事（オーバーエンジニアリング批評家）であり、ユーザーの仕事ではありません。

2b. 承認されたスキーマに対してコンパイルする

temper-skills ingest <path/to/skill.md> \
  --schema schema.proposed.py \
  --profile standard \
  --json

プロファイルをユーザーと選択してください — quick | standard | audit-grade、デフォルトは standard。推奨する前に references/profiles.md を参照してください。--json は非インタラクティブを意味します: ループは収束するまで実行され（この方法で駆動されるとラウンドごとのゲートで一時停止できません — そのゲートは人間ターミナル機能です）、結果のマニフェストをstdoutに出力します。それを読み、パネルをスクレイピングしないでください。（--require-fit は監査判定が skip の場合に終了コード3で早期停止します。適合しない場合にループを無駄にしないために追加してください。）

2c. アクションが decompose の場合

フローは最初に分割する必要があります。各決定を個別にテンパリングします:

temper-skills decompose <path/to/skill.md> --temper-each --out-dir out/

これにより決定ごとに1つのスキーマが出力され、承認のために停止します。スキーマを提示し、ユーザーに編集させてから、同じコマンドを再実行して各決定をツリーとオーケストレータースキールにコンパイルします（--yes-unratified は停止をスキップします — ユーザーが要求しない限り避けてください）。

Step 3 — 成果物を報告する（マニフェストから）

ingest --json のマニフェストが真実の情報源です — これらのフィールドを読み、スクレイピングしないでください:

{ "tree_path": "...", "tempered_skill_path": "...",
  "validation_dataset_path": "..." , "validation_case_count": 0,
  "gray_zones": [{"node": 1, "condition": "...", "note": "..."}],
  "features": ["..."], "node_count": 0, "profile": "...", "cost_usd": 0.0 }

3つの成果物すべてをユーザーに提示してください:

• tree_path — 決定木: 何もインポートせず、推論時にLLM呼び出しゼロで、generated_at + モデルヘッダーとノードごとの出典コメントが付いています;
• tempered_skill_path — テンパリングされた skill.md: 元のスキルが、再決定する代わりに凍結されたツリーを呼び出すように書き換えられています。成果物の半分です; これを落とさないでください;
• validation_dataset_path — ループがグレーゾーン用に構築したコミット済みの .validation.jsonl、承認待ちです（validation_case_count）。"agrees": false の行は、ユーザーが判断する最も価値の高い不一致です。それと並ぶ動作ロックテスト（test_<stem>.py）はグリーンのままです; 承認されたラベルのみがテストをレッドにできます。

パス、プロファイル、cost_usd、gray_zones をユーザーに伝えてください。ルール4を再確認してください: 決定論的で監査可能であり、「正しい」わけではありません。

Step 4 (オプション) — CIに組み込む

ユーザーがラベル付きセットを承認したら、それに対して決定木を検証します:

temper-skills validate decision_tree.generated.py ratified.json --min-agreement 1.0

不一致があると非ゼロで終了します — これで決定木がCIに固定されます。各不一致はツールのバグか誤ったラベルの例のいずれかです; 承認のためにそれらを中継してください。

参考

プロファイルを推奨する前に、ラウンド数/収束/ペルソナパネル/プロファイルあたりのコストについて references/profiles.md を参照してください。

禁止事項

• ライブラリを実行する代わりに、ツリーのロジックを自然言語で書かないこと。
• quick デモであってもスキーマ承認をスキップしないこと（quick は出典コメントを削除しますが、ゲートは削除しません）。
• 明示的な確認なしにインストールや環境の変更を行わないこと。
• 生成されたツリーが「正しい」と主張しないこと。