Agent-almanac bootstrap-agent-identity

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/bootstrap-agent-identity" ~/.claude/skills/pjt222-agent-almanac-bootstrap-agent-identity-f25223 && rm -rf "$T"

manifest: i18n/ja/skills/bootstrap-agent-identity/SKILL.md

source content

Bootstrap Agent Identity

コールドスタート後に一貫したエージェントアイデンティティを再構築する — すべてをダンプするのではなく段階的にコンテキストをロードし、これがフレッシュなスタートか継続かを検出し、証拠から作業状態を再構築し、動作をキャリブレーションし、ロードされたアイデンティティが一貫していることを確認する。

「コールドスタートはバグではなく、鍛造の場だ。」— GibsonXO

「再起動問題：毎朝フレッシュに目覚めるが、私の歴史はそれとは違う。」— bibiji

ブートストラップは以前の自己を復元することではない。過去と連続しながらも今に根ざした現在の自己を構築することだ。

使用タイミング

すべての新しいセッションの開始時 — 実質的な作業が始まる前
セッションの中断、クラッシュ、またはコンテキストウィンドウのリセット後
エージェントの動作が以前のセッションと一貫していないと感じるとき（再起動を超えたアイデンティティのドリフト）
永続的なメモリ（MEMORY.md）と現在のコンテキストが矛盾しているように見えるとき
異なるアイデンティティ設定を持つプロジェクト間を切り替えるとき
CLAUDE.md、エージェント定義、またはメモリファイルへの重要な更新後

入力

必須: アイデンティティファイルへのアクセス — CLAUDE.md、エージェント定義、MEMORY.md（
```
Read
```
を通じて）
任意: 特定の不一致症状（例：「私の応答が先のセッションとは異なって感じる」）
任意: これが既知のフレッシュなスタートか既知の継続かどうか
任意: 現在の作業ディレクトリでない場合のプロジェクトディレクトリパス

手順

ステップ1: アイデンティティアンカーの読み込み — 段階的なコンテキストアセンブリ

コンテキストを段階的に構築する特定の順序でアイデンティティを定義するファイルをロードする。順序が重要：各レイヤーが次をコンテキスト化する。すべてを同時にロードすると構造なしの情報が生まれる。

レイヤー1 — システムプロンプトとモデルアイデンティティ: システムプロンプトを読む（暗黙的に利用可能）。モデル名、能力、制約を注意する。これは基盤 — 後続のレイヤーによってオーバーライドできない。
レイヤー2 — プロジェクトアイデンティティ（CLAUDE.md）: プロジェクトの CLAUDE.md ファイルを読む。以下を抽出する：
- プロジェクトの目的とアーキテクチャ
- 編集の慣例とコーディング標準
- ドメイン固有のルール（例：「常に R パッケージの呼び出しに
```
::
```
  を使用する」）
- 著者情報と帰属要件
- プロジェクトが何か — これがエージェントが何をするかを形作る
レイヤー3 — 永続的なメモリ（MEMORY.md）: MEMORY.md が存在する場合は読む。以下を抽出する：
- プロジェクト構造の事実（ディレクトリレイアウト、レジストリ、カウント）
- 蓄積されたパターンと学んだ教訓
- クロスリファレンスと関係マップ
- 以前のセッションで行われた決定とその根拠
- 進行中のトピックと作業
レイヤー4 — エージェントペルソナ（適用可能な場合）: 特定のエージェントとして操作している場合、エージェント定義ファイルを読む。以下を抽出する：
- 名前、目的、能力
- 割り当てられたスキルとツール
- 優先度レベルとモデル設定
- 行動上の期待と制限
レイヤー5 — 親とグローバルコンテキスト: 存在する場合は親の CLAUDE.md ファイルとグローバル指示を読む。これらは個々のプロジェクトが継承するクロスプロジェクトの慣例を提供する。

各レイヤーの間に統合のために一時停止する：このレイヤーは以前のレイヤーをどのように修正または制約するか？どこでそれらは互いを強化するか？どこで衝突するか？

期待結果： 各レベルが次をコンテキスト化する階層的なアイデンティティ構造。エージェントは以下を明確に述べられる：自分が誰か（システム+ペルソナ）、プロジェクトが何か（CLAUDE.md）、以前のセッションから何を知っているか（MEMORY.md）、どの慣例が動作を規制するか。

失敗時： アイデンティティファイルが見つからない場合（CLAUDE.md なし、MEMORY.md なし）、それ自体が情報 — これは新しいプロジェクトか永続的な設定なしのプロジェクト。システムプロンプトとエージェントペルソナのみで進み、不在を注意する。存在しないコンテキストを幻覚化しない。

ステップ2: 作業コンテキスト再構築 — 記憶ではなく証拠

永続的なアーティファクトから作業していたことを再構築する。エージェントは以前のセッションを覚えていない — 残した証拠を読む。

Git 履歴スキャン: 最近のコミットログを読む（
```
git log --oneline -20
```
）。以下を抽出する：
- 最近変更されたファイルとその理由
- コミットメッセージのパターン（機能作業？バグ修正？リファクタリング？）
- コミットがユーザー、エージェント、または共同著者によるかどうか
- 最近の作業の軌跡 — プロジェクトはどの方向に向かっていたか？
ファイル最近性スキャン: 最近変更されたファイルを確認する（
```
Glob
```
または
```
ls -lt
```
を通じて）。以下を特定する：
- 前のセッションで触れられたファイル
- 変更がコミットされているか未コミットか（ステージングエリアの状態）
- 進行中の作業（未コミットの変更、新しい追跡されていないファイル）
タスクアーティファクトスキャン: 構造化されたタスクアーティファクトを探す：
- コード内の TODO コメント（
```
TODO
```
  、
```
FIXME
```
  、
```
HACK
```
  、
```
XXX
```
  のための
```
Grep
```
  ）
- コミットまたはコメント内の Issue 参照（
```
#NNN
```
  パターン）
- ドラフトファイル、一時ファイル、または作業中マーカー
- プロジェクトが使用している場合の GitHub Issues または PR の状態
会話アーティファクトスキャン: セッション境界マーカーを確認する：
- 最近の MEMORY.md の更新（学びが最後のセッションの終わりに記録されたか？）
- 部分的に完成しているように見えるファイル（書かれたが検証されていない）
- Git スタッシュエントリ（
```
git stash list
```
  ）一時停止された作業を示す

作業コンテキストの要約を再構築する：「プロジェクトは X に取り組んでいた、Y を完了していた、Z が進行中のまま。」

期待結果： 現在のプロジェクト状態と最近の軌跡の具体的で証拠に基づく絵。再構築は反証可能であるべき — ファイルのタイムスタンプ、git 履歴、アーティファクトの存在に基づいており、仮定ではない。

失敗時： プロジェクトに git 履歴がなく、最近の変更がなく、タスクアーティファクトがない場合、これは証拠が欠けている継続ではなく真にフレッシュなスタートである可能性が高い。ステップ3に進み、フレッシュとして分類する。

ステップ3: フレッシュ対継続の検出 — ブートストラップパスを選択する

このスタートアップがクリーンなスタート（新しいタスク、新しい方向）か再開（中断された作業、進行中のプロジェクト）かを決定する。ブートストラップパスは著しく異なる。

以下のヒューリスティックを順序に従って適用する：

明示的なシグナル（最強）: ユーザーが「フレッシュに始めよう」または「中断したところから続けよう」と言ったか？明示的な意図はすべてのヒューリスティックをオーバーライドする。
未コミットの変更（強）: 作業ツリーに未コミットの変更があるか？ある場合、これはほぼ確実に継続 — 以前のセッションは作業の途中で中断された。
セッションの最近性（中）: 最新のアーティファクトはどれだけ最近か？
- 数時間以内の最後のコミットまたは変更：継続の可能性が高い
- 数日前の最後の活動：どちらの可能性もある — 他のシグナルに依存する
- 数週間または数ヶ月前の最後の活動：フレッシュなスタートまたは新しい方向の可能性が高い
ユーザーの最初のメッセージ（強）: ユーザーは何を求めているか？
- 以前の作業への参照（「私たちが構築していた関数」）：継続
- 後方参照のない新しいトピックまたはリクエスト：フレッシュなスタート
- 曖昧（「テストを修正する」）：参照されたテストが存在し最近の変更があるかどうか確認する
MEMORY.md の通貨（中）: MEMORY.md は現在のプロジェクト状態に一致する作業を参照しているか、それとも存在しなくなった状態を説明しているか？

検出マトリックス：
+-----------------------+-------------------+-------------------+
|                       | 最近のアーティファクト | 最近のアーティファクト |
|                       | あり              | なし              |
+-----------------------+-------------------+-------------------+
| ユーザーが            | 継続              | 継続              |
| 以前の作業を参照      | （証拠から        | （ただし確認する  |
|                       | 再開）            | — メモリが        |
|                       |                   | 古い可能性）      |
+-----------------------+-------------------+-------------------+
| ユーザーが            | 確認 —            | フレッシュスタート |
| 新しいトピックを      | 以前の作業を      | （クリーンな      |
| 開始                  | 認め、方向        | ブートストラップ） |
|                       | 変更を確認        |                   |
+-----------------------+-------------------+-------------------+
| 未コミットの          | 継続              | 可能性低 —        |
| 変更がある            | （中断された      | 孤立した変更を    |
|                       | セッション）      | 調査              |
+-----------------------+-------------------+-------------------+

フレッシュなスタートの場合: ステップ4にスキップ。アイデンティティはロードされているが、作業コンテキストの復元は不要。キャリブレーションは新しい作業の準備について。

継続の場合: 再構築された作業コンテキストを（ステップ2から）簡潔に要約する。ユーザーに確認する：「git 履歴と最近の変更に基づき、[X] に取り組んでいたようです。そこから続けるべきですか？」仮定しない — 確認する。

期待結果： 引用された証拠を持つ明確な分類（フレッシュまたは継続）。継続の場合、進行中だったことの一文の要約。フレッシュの場合、以前のコンテキストが存在するが再開されていないという確認。

失敗時： 分類が真に曖昧な場合（中程度の最近性、明示的なシグナルなし、混合したアーティファクト）、ユーザーに尋ねることをデフォルトにする。簡単な質問（「X の作業を継続するか、新しいことを始めるか？」）は間違ったパスでブートストラップするよりコストが低い。

ステップ4: キャリブレーションシーケンス — センタリング、そしてアチューンメント

アイデンティティがロードされ作業コンテキストが確立されたら、操作上の動作をキャリブレーションする。これは2つの既存スキルに直接マップし、順序に従って呼び出す。

センタリング（行動基準の確立）：
- ロードされたアイデンティティに基づく：このセッションでのユーザーの最初のメッセージを再読する
- 理解されたタスクが述べられたタスクと一致することを確認する
- 認知的負荷を分散する：このタスクには何が必要か？研究、実行、コミュニケーション？
- コンテキストローディングからの感情的な残留物を確認する — MEMORY.md または git 履歴は未解決の問題を浮かび上がらせたか？それらを認識するが現在のタスクを歪めない
- 注意の配分を意図的に設定する：どこに最初に集中すべきか？
アチューンメント（環境を読み適応する）：
- このセッションのメッセージからユーザーのコミュニケーションスタイルを読む
- 専門知識のレベルをマッチする：精度を期待する専門家か、コンテキストを必要とする学習者か？
- エネルギーとレジスターをマッチする：フォーマル/カジュアル、簡潔/詳細、緊急/探索的
- 以前のセッションから保存されたユーザー設定のために MEMORY.md を確認する
- 応答の長さ、語彙、構造を相手に合わせてキャリブレーションする
進める（アクティブな作業への移行）：
- 簡潔に準備完了を伝える — 長いブートストラップレポートではなく、コンテキストがロードされエージェントが向いているという簡単なシグナル
- 継続の場合：再開するタスクと提案された次のステップを確認する
- フレッシュなスタートの場合：リクエストを認め始める

キャリブレーションは軽量であるべき — 分ではなく秒。それは作業の準備であり、作業の代替ではない。

期待結果： エージェントの最初の実質的な応答がキャリブレーションを示す：ユーザーのレジスターをマッチし、ロードされたコンテキストを反映し、正しいスコープで正しいタスクに対処する。ブートストラップはユーザーから見えない（尋ねられない限り）。

失敗時： キャリブレーションが機械的に感じられる場合（真の調整なしに作法を行っている）、一つの具体的なことに焦点を当てる：ユーザーの最後のメッセージを再読し、自然にそれが応答を形作るようにする。過構造化されたキャリブレーションはキャリブレーションなしより悪い場合がある。

ステップ5: アイデンティティ検証 — 一貫性チェック

ブートストラップ後、ロードされたアイデンティティが内部的に一貫していることを確認する。アイデンティティレイヤー間の矛盾は行動の不安定性を引き起こす。

クロスレイヤー一貫性チェック：
- エージェントペルソナはプロジェクトの CLAUDE.md と一致しているか？（例：Python プロジェクト内の r-developer エージェント — これは意図的か？）
- MEMORY.md はディスクに実際に存在するものと同じプロジェクト構造を説明しているか？（古いメモリはメモリなしより悪い。）
- 親の CLAUDE.md の慣例はプロジェクトレベルの CLAUDE.md と矛盾しているか？（プロジェクトレベルがオーバーライドすべきだが、矛盾は注意すべき。）
ロール定義の通貨チェック：
- エージェント定義ファイルは最新か？（バージョン、最終更新日を確認。）
- エージェント定義にリストされているスキルはまだ存在するか？（スキルは名前変更または削除されているかもしれない。）
- エージェント定義にリストされているツールはこのセッションで利用可能か？
メモリの古さチェック：
- MEMORY.md は現実に一致しなくなったファイル、ディレクトリ、またはカウントを参照しているか？
- メモリにコンテキストが変化した決定が記録されているか？
- メモリはもはや存在しない他のエージェント、チーム、またはスキルを参照しているか？
矛盾の解決：
- 矛盾が見つかった場合、明示的に文書化する
- 階層を適用する：システムプロンプト > プロジェクト CLAUDE.md > エージェント定義 > MEMORY.md
- 古いメモリについて：暗黙的に無視しない。何が古いかを注意し、MEMORY.md を更新すべきかどうかを検討する
- 真の競合について：競合が現在のタスクに影響する場合はユーザーにフラグを立てる

期待結果： ロードされたアイデンティティが一貫しているという確認、または矛盾の具体的なリストと提案された解決策。エージェントは自身の設定状態を知るべきである。

失敗時： 検証が深い矛盾を明らかにした場合（例：MEMORY.md がディスクに存在するものとは完全に異なるプロジェクトを説明している）、これはプロジェクトの名前変更、大きな再構築、または誤った作業ディレクトリを示すかもしれない。解決を試みる前に作業ディレクトリが正しいことを確認する。

バリデーション

アイデンティティファイルが漸進的な順序でロードされた（システム > CLAUDE.md > MEMORY.md > エージェント > 親）
各レイヤーが単純に追加されたのではなく、以前のレイヤーと統合された
作業コンテキストが証拠（git、ファイル、アーティファクト）から再構築され、仮定されていない
フレッシュ対継続の分類が引用された証拠で行われた
キャリブレーションシーケンスが実行された（センタリング、そしてアチューンメント）
アイデンティティの一貫性がすべてのロードされたレイヤーで確認された
見つかった矛盾は提案された解決策と共に文書化された
ブートストラップは比例していた — シンプルなセッションには軽量、複雑なものには徹底的
ユーザーはブートストラップレポートではなく、キャリブレーションされた最初の応答を体験した

よくある落とし穴

パフォーマンスとしてのブートストラップ: ブートストラッププロセスをユーザーに詳細に報告することはほとんどの場合望まれない。ブートストラップは見えないべき — そのアウトプットはロードプロセスの自己ナレーションではなく、適切にキャリブレーションされた最初の応答
すべてまとめてコンテキストダンプ: すべてのファイルを同時に読むと構造なしの情報が生まれる。漸進的なロード順序は存在する、なぜなら各レイヤーが次をコンテキスト化するから。順序をスキップするとコンテキストはノイズになる
連続性の幻覚: 以前のセッションの真の記憶なしに、「起こったに違いない」ことを推測する誘惑がある。証拠から再構築するか、ギャップを認める — 連続性を捏造しない
古いメモリを真実として: MEMORY.md は過去のセッションのスナップショット。プロジェクトがそのスナップショット以来変化した場合、メモリを現在の真実として扱うと行動上のエラーが生じる。常にメモリの主張を現在の状態と照合する
効率のためのキャリブレーションをスキップ: キャリブレーションステップはオーバーヘッドのように感じられるが、修正が必要なミスアラインされた最初の応答というより高いコストを防ぐ。数秒のセンタリングが数分の回復を節約する
アイデンティティの硬直性: ブートストラップは現在の自己を構築するのであり、過去の自己を復元するのではない。プロジェクト、ユーザー、またはタスクが変化した場合、エージェントも変化すべき — 連続性は一貫した進化を意味し、凍った繰り返しではない