run-history-skill-builder

実行履歴スキルビルダー

言語ポリシー

ユーザー向けの出力はすべて、ユーザーの言語で記述します。言語が不明な場合は、中国語を既定とします。

役割

依頼が既存のスキルに関するものである場合は、実際の実行履歴を新しいスキルパッケージ、設計のみのスキル案、またはアップグレードの引き継ぎ資料に変換します。

移植性

このスキルはエージェントに依存しません。SKILL.md と、必要に応じて references/、scripts/、evals/、agents/ を読み込める Codex、Claude Code、OpenCode、OpenClaw、Hermes、および同様のローカルエージェントホストで動作する必要があります。

• <skill-dir> は、この SKILL.md を含むディレクトリとして解決します。
• <python> は、ホストで利用可能な Python ランチャー（python3、python、または py -3）を指します。
• 固定のスキルルート、シェル、ホームディレクトリ構成、またはパス区切り文字を前提としないでください。
• <skill-dir>/scripts/... のようなプレースホルダーパスは、必須の区切り文字スタイルではなく、パスの各要素を示します。Windows では、シェルまたはハーネスが受け付ける区切り文字スタイルを使用してください。
• ファイルを書き込む前に、出力ディレクトリを確定してください。ユーザーが指定しない場合は、現在のリポジトリの skills/ ディレクトリや、ホストエージェントの公式ドキュメントに記載されたローカルスキルディレクトリなど、中立的なローカル保存先を提案し、確認を待ってください。

ワークフロー

1. 意図を確定します。依頼が plan_only、new_single_skill、router_skill、skill_suite、existing_skill_upgrade_handoff のいずれに当たるかを判断します。
2. 根拠の範囲を確定します。参照してよい会話ターン、ファイル、ログ、成果物、差分、ブラウザ操作フロー、またはトランスクリプトを確認します。
3. ファイルを書き込む前に、出力先を確定します。
4. 許可された根拠からワークフローを再構成します。ユーザーの目標、実際の手順、失敗、修正、成功の証拠、承認ゲートを特定します。
5. ワークフローをより確実にパッケージ化するうえで役立つ場合に限り、ローカルまたはオープンソースのパターンを調査します。
6. 再利用可能な不変要素と、一度限りのパス、アカウント名、特定の日の製品上の癖、一時的なユーザーの好みなどのローカル固有要素を切り分けます。
7. ワークフローを状態ゲート、検証ゲート、スクリプト、リファレンス、例、評価に抽象化します。主観的な推測に依存する不確かな経路は削除します。
8. 正確性を保てる最小のパッケージを選びます。
9. 前述のゲートを満たした後にのみ、スキルを書き込みます。
10. 検証を行い、残る前提条件を報告して、パスとチェック結果を添えてパッケージを引き渡します。

「実行の成功を見た」だけで「スキルを書いた」と先へ進まないでください。移植性、プライバシー、一般化を判断するうえで欠かせないのは、その間の工程です。

アーキテクチャの選択肢

• plan_only：ユーザーが求めているのは、ファイルではなく、レビュー済みの設計または監査です。
• new_single_skill：安定した単一のワークフロー、または密接に結び付いたワークフローファミリーです。
• router_skill：複数の既存スキルまたはフェーズに処理を振り分ける単一のエントリーポイントです。
• skill_suite：個別に起動するものの、まとめてリリースすべき複数の独立したワークフローです。
• existing_skill_upgrade_handoff：実際のタスクが既存スキルの改善である場合です。このスキルをここで編集する代わりに、$run-history-skill-upgrader に渡すための整理された引き継ぎ資料を作成します。

パッケージの肥大化を避けるため、置き換え、統合、省略を優先してください。

根拠と範囲

意図の確定後、既定で参照できるもの：

• 現在表示されている会話。
• ユーザーが提供したパス、成果物、ログ、スクリーンショット、トランスクリプト。
• 現在のワークスペースのファイル、差分、テスト、生成物。
• パッケージ化のパターンを調べるために参照する、類似の公開スキルや公式ドキュメント。

次を参照する前に、明示的な承認を得てください。

• 現在のタスクと無関係な、広範なローカルセッションアーカイブ。
• ブラウザーの Cookie、ローカルストレージ、セッションのエクスポート、アカウントキャッシュ。
• パスワード、トークン、API キー、確認コード、MFA データ、その他の認証情報。
• 合意した範囲外の、無関係なプライベートフォルダーや個人の履歴。

事実、推論、未解決の前提を分けてください。公開するスキルやその例に、秘密情報、隠されたプロンプト、非公開のアカウント識別子、無関係な個人情報を決して記載しないでください。

設計ルール

• SKILL.md は、トリガーの境界、役割、ワークフロー、安全性のゲート、参照先の案内に焦点を絞ります。
• 分岐ごとの詳細なガイダンスは references/ に配置します。
• 決定論的なチェックや繰り返し行うチェックは scripts/ に配置します。
• ワークフローが長期にわたる、高リスクである、または過剰適合しやすい場合は、トリガーと回帰テストのサンプルを evals/ に配置します。
• 例は、複雑な動作、障害からの復旧、境界条件を示す場合に限って使用します。各例では、不変条件と対象外の事項を明記する必要があります。
• ユーザーが所有する判断はユーザーに委ねます。機械で検証可能な事実は、スクリプト、テスト、スキーマチェック、差分、ファイルの存在チェック、バリデーターで確認します。
• ユーザーまたはリリース先から明示的に求められない限り、スキルごとの README、インストールスクリプト、変更履歴、装飾用ファイルは作成しません。
• agents/openai.yaml は任意の UI 拡張として扱い、コアロジックには含めません。

検証

このスキルに同梱されているパッケージバリデーターを実行します。

<python> <skill-dir>/scripts/validate_skill_package.py <target-skill-dir>

この同梱バリデーターは、パッケージ構造、ポータブルな Agent Skills のフロントマター項目セット、参照先のパス、JSON の形式、Python の構文、一般的な非公開パスの混入をチェックします。依存関係のないフロントマターの事前チェックでは、スカラー項目、ブロックテキスト、1 階層の文字列メタデータを受け付けます。ほかの YAML 形式は推測せずに拒否します。ホストによっては異なる構文や、より限定された項目セットが受け付けられる場合があるため、そのホストへのインストールでは、ホスト固有の正規バリデーターを優先します。いずれの構造チェックも評価ケースを実行せず、スキルが正しくトリガーされることや、動作が改善されることを証明するものではありません。

現在のホストに正規のスキルバリデーターが用意されている場合は、それも実行します。Codex に類似したホストでは、多くの場合、プラットフォームのスキルツールに含まれる quick_validate.py コマンドを実行します。

また、関連する最小限の技術チェックも実行します。

• 変更した Python スクリプトに対して python -m py_compile を実行します。
• 編集した JSON ファイルに対して python -m json.tool を実行します。
• 最小限の有効なセットを使ってトリガーを確認します。このセットには、トリガーすべきケース、近接するトリガーすべきでないケース、境界ケースを含めます。リスクや不安定さに応じて、必要な場合にのみケースを追加します。
• 非公開の絶対パス、認証情報、非表示のプロンプト、環境固有の不要物が混入していないかスキャンします。

検証を省略した場合や失敗した場合は、完了したと報告しないでください。不足している検証と残っているリスクを報告します。

最終回答

次の内容を報告します。

• 選択したパッケージの種類
• 最終的なスキルのパス
• 作成したファイル、または意図的に省略したファイル
• 実際に使用した根拠資料
• 実際に実行した検証コマンドとその結果
• ユーザーによる確認が必要な未確定の前提
• 結果が plan_only、新しいスキルパッケージ、アップグレーダーへの引き継ぎのいずれであるか

参考資料

• references/history-mining.md
• references/open-source-pattern-mining.md
• references/skill-design-protocol.md
• references/self-repair-and-evals.md
• references/examples.md
• scripts/validate_skill_package.py
• evals/evals.json