session-to-skill

セッションからスキルへ

このスキルを使うと、セッション全体の履歴を、焦点を絞ったスキルの草案にまとめられます。

目的は、トランスクリプト全体を機械的に変換することではありません。セッションやチェックポイントを資料として扱い、ユーザーが繰り返したいと考えている再利用可能なワークフローを抽出します。

応答形式

このスキルの呼び出しに対する最初の応答は、次の行から始めてください。

Entire Session To Skill:

その後に空行を入れ、続けて本文を記述します。

• このヘッダーを適用するのは、呼び出しに対する最初の応答のみです。同じ呼び出し内の後続ターンでは再掲しないでください。
• Entire がインストールされていない場合、現在のディレクトリが Git リポジトリではない場合、関連するセッションが見つからない場合、またはユーザーが再利用したい動作を特定していない場合など、エラー時や早期終了時の応答にはヘッダーを含めないでください。

ルール

1. まず、スキルで再利用可能な動作として取り上げるものを特定します。ユーザーがスキルに何をさせたいか伝えていない場合は、トランスクリプトを読む前に質問してください。
2. Entire の履歴を根拠として使います。ユーザーに古いトランスクリプトの貼り付けを求めるのではなく、entire search、entire session current、セッションのメタデータファイル、entire checkpoint explain を優先してください。
3. スキルの草案は、セッションの要約ではなく、今後の作業に焦点を当ててください。再利用可能なワークフロー、リポジトリの規約、ユーザーによる修正、コマンド、検証方法、避けるべきことを残してください。
4. 関連するセッションが複数ある場合は、繰り返されるワークフローのパターンを要約し、トランスクリプトをさらに確認する前に、参照するセッションの候補を示してユーザーに確認してください。
5. ユーザーが保存先を明示的に承認しない限り、スキルファイルの書き込み、インストール、上書きを行わないでください。既定では、応答内に SKILL.md の草案を提示します。
6. 生成するスキルには、秘密情報、プライベートな認証情報、生のログ、不要なトランスクリプトの詳細を含めないでください。

ワークフロー

1. スキルの対象を明確にする

ユーザーが対象を明確に示している場合は、そのまま進めてください。例：

• 「ブログ公開のワークフローをスキルにまとめて」
• 「セッション 019 からスキルを作って」
• 「リリースノートの草案を何度も作っているので、再利用できる形にして」

対象が曖昧な場合は、次のように尋ねてください。

What should this skill help you do repeatedly?

ユーザーがスキル名を指定した場合は、その名前を使ってください。指定がなければ、対象から短いハイフン区切りの名前を考え、ファイルを書き込む前にユーザーに確認してください。

2. 繰り返しのパターンを推測する

ユーザーがチェックポイント ID を指定した場合は、チェックポイントの展開に進みます。

ユーザーがセッション ID を指定した場合は、次の場所から一致するセッションのメタデータを読み取ります。

.git/entire-sessions/<session-id>.json

ユーザーが繰り返しのワークフローを説明しているものの、セッションもチェックポイントも指定していない場合は、対象に関連する用語を使って Entire の履歴を検索します。

entire search "<workflow terms>" --json

ユーザーがリポジトリ、ブランチ、作成者、または日付を指定した場合は、それらのフィルターを使用します。

entire search "<workflow terms>" --json --repo owner/name --branch branch-name --author "Name" --date month

検索結果は慎重に解釈してください。

• entire search が "total": 0 または空の results 配列を含む有効な JSON を返した場合、認証エラーだと判断しないでください。インデックスに一致するものが見つからなかったと伝えたうえで、ローカルのセッションメタデータに切り替えます。
• コマンドの出力に認証、ログイン、または認証情報が必要だと明記されている場合に限り、認証が必要だと伝えてください。
• 検索がその他の理由で失敗した場合は、エラーの概要を簡潔に伝え、利用可能であればローカルのセッションメタデータに切り替えます。

ローカルに切り替える場合は、.git/entire-sessions/*.json を調べ、last_prompt、description、files_touched、started_at、last_interaction_time、agent_type、およびユーザーが示したワークフロー用語を照合します。

上位の検索結果を確認し、生のセッション候補を提示する前に、繰り返しのワークフローパターンを推測します。ID ではなく、パターンを最初に提示してください。

次の内容を提示します。

• ユーザーが記録したいと考えている繰り返しのワークフロー
• 使用を推奨する、最も有力なソース群
• 「コアワークフロー」「画像処理」「検証」「コピー編集パターン」など、各ソースが何を補足するかを平易な言葉で説明したもの
• メタデータのみ、重複、または単発の内容に見えるため、使用を見送る予定のセッション

セッション ID とチェックポイント ID は補足情報として扱い、主な判断材料にしないでください。詳細なトランスクリプトを展開する前に、パターンとソース群を確認するようユーザーに依頼します。

例：

I found a repeated workflow: publishing blog posts in entire.io from drafts, using repo-specific front matter, slugged asset folders, user-provided images, and website checks.

I recommend using the strongest matching sessions as source material:
- core workflow: <session-id>
- image handling: <session-id>
- validation mechanics: <session-id>

I will ignore metadata-only or one-off edit sessions unless you want them included. Should I continue with this source set?

3. ソース資料を読む

チェックポイントの場合は、次を実行します。

entire checkpoint explain --checkpoint <checkpoint-id> --full --no-pager

出力全体の取得に失敗し、ユーザーがさらに詳しい情報を求めている場合は、次の方法に切り替えます。

entire checkpoint explain --checkpoint <checkpoint-id> --raw-transcript --no-pager

アクティブなセッションまたは現在のセッションでは、次の方法を優先します。

entire session current

インストール済みの Entire CLI が単数形の session グループをまだサポートしていない場合は、セッションメタデータに直接切り替えます。.git/entire-sessions/*.json を調べ、last_interaction_time、started_at、agent_type、またはユーザーが指定したエージェントに基づいて関連するセッションを選び、transcript_path を抽出します。

生のトランスクリプトを読む場合は、会話とツール呼び出しの関連行を抽出し、ユーザーにそのまま大量に提示しないでください。

grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | cut -c1-2000

大きなトランスクリプトの場合は、まず最初のプロンプトと最終状態を確認します。

grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | head -40 | cut -c1-2000
grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | tail -160 | cut -c1-2000

セッションメタデータに変更対象のファイルが記載されている場合は、長期的に活用できる規約を理解するために必要なファイルだけを調べます。スキルの対象に必要でない限り、リポジトリ全体を広く調査することは避けてください。

4. 長期的に活用できる教訓を抽出する

草案を作成する前に、次の点を内部で特定します。

• 将来のスキルが達成すべき、繰り返しの目標
• スキルを有効にするべきトリガー
• 将来のエージェントがユーザーに確認すべき必須の入力情報
• リポジトリ固有のパス、ファイル形式、フロントマター、命名規則、アセットの配置場所
• ワークフローが機能したことを確認できたコマンドとチェック
• セッション中のユーザーによる修正や好み
• 失敗した方法や避けるべき行動
• 単発の内容であり、スキルに含めるべきでないもの

複数のセッションを選んだ場合は、繰り返されている教訓、または明らかに再利用できる教訓だけをまとめます。矛盾する指示を平均化しないでください。セッション間で指示が食い違う場合は、ユーザーに選択を依頼します。

5. スキルを草案化する

必須のフロントマターを含む、完全な SKILL.md の草案を作成します。

---
name: <hyphen-case-skill-name>
description: Use when <specific trigger and task>.
---

本文には次の内容を含めます。

• 短い目的の説明
• 明確なルールまたはガードレール
• 手順を追ったワークフロー
• 再利用可能な動作に含まれる場合に限り、正確なコマンド
• 想定される出力と検証手順
• 失敗時の対応、またはユーザーに確認すべき状況

スキルは簡潔に保ってください。将来の利用に不可欠でない限り、セッションの要約、トランスクリプトの抜粋全文、チェックポイント ID、実装メモは含めないでください。

6. 配布してインストールを提案する

ユーザーが書き込み先を明示していない場合は、まず SKILL.md のドラフトを提示します。

ドラフトを提示した後、グローバルにインストールするかどうかを尋ねます。エージェント間で共通して使える次のパスを推奨します。

~/.agents/skills/<skill-name>/SKILL.md

インストールを尋ねる際は、次の形式を使用します。

Do you want me to install this skill globally?

Recommended:
- Cross-agent: ~/.agents/skills/<skill-name>/SKILL.md

Other options:
- Codex only: ~/.codex/skills/<skill-name>/SKILL.md
- Write to a repo-local draft: skills/<skill-name>/SKILL.md
- Leave as draft only

ユーザーが保存先を選択するまでは、ファイルを書き込まないでください。保存先がすでに存在する場合は、上書きする前に確認してください。

ユーザーが開発用リンク付きのインストールを明示的に希望しない限り、シンボリックリンクを作成しないでください。シンボリックリンクを希望された場合は、作成する前にリンク元とリンク先のパスを説明してください。

スキルファイルを書き込んだ後、次の内容を要約します。

• 書き込んだ場所
• 参考にしたセッションまたはチェックポイント
• 前提や未解決の質問