あなたのモデルとハーネスはもう重要ではありません。
もっと重要なのは......
あなたのパーソナルコンテキスト / 共有メモリーです。
はじめに
今回は、コーディングエージェント用の共有メモリーを構築する方法をご紹介します。これにより、次のツールがあなたが既に行った判断を見つけられるようになります。
Claude でのアーキテクチャに関する会話、Codex でのデバッグセッション、Cursor に埋もれた説明... これらは、ツールを切り替えたり、別のセッションを開始したり、1 か月後にプロジェクトに戻ってきたときにも、引き続き利用できるべき有用な作業です。
TLDR; 3,845 語すべてを読みたくない場合は、この GitHub リポジトリをエージェントに渡すだけです ➡️ https://github.com/codejunkie99/agentic-stack-desktop
私はこれをすべて Codex Harness の Kimi K3 を使って構築しました。動画は Kimi K3 と Cua（Computer Use 用）を使って作成・編集しました。
これは、最初のインポートから、エージェントが以前の判断を回復し、それを現在のコードと照合し、制限された変更を加え、有用なものを残すことができるワークフローまでを解説する、Agentic Stack Desktop のビルダーズガイドです。
このガイドで得られるもの:
- 基盤: ツールを切り替えても生き残るもの
- 最速のパス: 評価可能なワークスペースを構築する
- 実用的なセットアップ: 調査と実装を分離する
- プロジェクト演習: 繰り返し発生するバグをサイクル全体で処理する
- 共有レイヤー: 他のツールに検索機能を持ち込む
- 永続的なレイヤー: 教訓として残す価値のあるもの
- 運用ルール: 簡潔に、制限して、検査する
- カスタムビルド: 実際の摩擦点に合わせてワークスペースを変更する
- スケーリング: 前のサイクルで露呈したギャップをカバーする
- ビルドシート
1. 基盤: ツールを切り替えても生き残るもの
あなたが午後をかけて、ある機能がどのように動作すべきかを検討したと想像してください。代替案を探り、制約を見つけ、明白な解決策を却下し、最終的に適合するものにたどり着きました。
実装はコミットされます。説明は会話の中に残ります。
1 週間後、別のエージェントがコードを見て、あなたが既に却下したのと同じアプローチを提案します。それは、そのエージェントが利用できる情報からすると、もっともな提案かもしれません。欠けているのは、あなたが別の選択をした理由となった議論です。
推論を回復可能にする
ここから始めてください: その議論を回復可能にし、次のエージェントが行動する前にそれを確認するようにします。
Agentic Stack は、Claude Code、Codex、OpenCode、Cursor からの検索可能で選択された履歴を備えたネイティブ macOS ワークスペースを提供します。Claude Code と Codex は公式 CLI を通じて実行も行います。Cursor と OpenCode は現在、コンテキストのみを提供します。リポジトリ概要
以下のワークフローは、私がこれらの機能を使用する方法です。ブリーフ、責任の分担、プロジェクト演習は、適応可能な推奨運用プラクティスです。
2. 最速のパス: 評価可能なワークスペースを構築する
あなたが理解しているリポジトリから始めてください。重要なファイルを知っていて、最近の判断を覚えていて、悪い推奨を認識できるものを選んでください。
使い慣れたプロジェクトは基準点となります。 馴染みのないコードと馴染みのない履歴から始めると、ツールの検証とシステムの学習を同時に行おうとすることになります。
ソースビルドの場合、必要な環境は macOS 14+、Python 3.10+、Xcode Command Line Tools、Swift 6 ツールチェーンです。実行したいコーディング CLI をインストールしてサインインしてください。必要条件
1git clone https://github.com/codejunkie99/agentic-stack-desktop.git2cd agentic-stack-desktop3./install.sh desktop --build
アプリでリポジトリを開き、ガイド付きセットアップを完了してください。これはアドホック署名付きのプレビューであるため、初回起動時に macOS が確認を求める場合があります。セットアップ
最初の受け入れチェックを設定する
何かをインポートする前に、最初のエージェントに答えてもらいたい質問を書き留めてください。例えば、なぜエクスポートジョブはレコードをバッチで処理するのか、現在の実装はまだその制限を必要としているのか、などです。
その質問が最初の受け入れチェックになります。あなたは、正しい判断、正しいサポートコード、そしてエージェントが確立できないことについての正直な説明を探しています。
2.1 最初のインポート: 見つける価値のある判断を与える
Knowledge Graph → Graph → Import memory を開き、ソースをプレビューし、含めたいマテリアルを選択します。
グラフは SQLite 全文検索を使用し、トピック、リポジトリリンク、来歴に基づいて接続します。元のチャットストアは変更されません。インポート動作
あなたが覚えている判断を含む、完了した会話から始めることをお勧めします。特に、最終的なコードからは明らかではない制約のために、魅力的な何かを却下したものが良いでしょう。
インポート後にその判断を検索してください。結果を開き、ソースを検査してください。意図した会話が、何が起こったかを理解するのに十分な説明とともに取り込まれていることを確認してください。
再度見つけられるかテストする
次に、来月自然に使うであろう語彙を使って 2 回目の検索を試してください。機能名は覚えているかもしれませんが、会話では内部モジュール名が使われていたかもしれません。この不一致を今見つけておくことで、後でマテリアルをどのように検索するかを理解するのに役立ちます。
最初のコレクションは、手動で検査できる程度に小さく保つことをお勧めします。既知のソースからの正しい答えは、ワークフローが機能するという有用な証拠です。
インポート数が多いと、どれだけのマテリアルがシステムに入力されたかはわかりますが、その有用性はテストされるまでわかりません。
別のタスクが理由を与えたときに、コレクションを拡張してください。
2.2 最初の作業セッション: 実験を完了できる程度に小さくする
別の設定画面を開く前に、初期セットアップにゴールラインを設定することをお勧めします。セッションの終わりまでに、既知の判断を回復し、それをリポジトリと照合し、他の人に説明できるレビューを作成できている必要があります。
範囲が狭い例を選んでください。単一のエクスポート動作は、データプラットフォーム全体を検査するよりも簡単です。コンポーネントに関する以前の選択は、アーキテクチャが良いかどうかという広い質問よりも検証が容易です。
演習の横に短いメモを残してください: 質問、期待されるソース、現在の実装、判断が必要な部分。これは回答を評価するための基準点となります。
適切な失敗を診断する
- レビューアが間違った会話を回復した場合は、検索に取り組みます。
- 正しい会話を見つけたがコードを誤って解釈した場合は、調査に取り組みます。
- 調査結果は妥当だが実装が要件を満たしていない場合は、引き継ぎを改善します。
この分離は重要です。なぜなら、各失敗は異なる修正を必要とするからです。 より多くのメモリーを追加しても、不明確なブリーフが必ずしも修正されるわけではなく、ブリーフを書き直しても、インポートされなかったソースは回復できません。
最小の完全なサイクルを終了し、何が失敗したかを記録し、その証拠を使用して次の改善を選択してください。
3. 実用的なセットアップ: 調査と実装を分離する
私が提案する最初のセットアップは、読み取り専用のレビューアと、プロジェクト編集アクセス権を持つ実装者です。それぞれに明確な成果物を与え、変更を開始する前にあなたが読める引き継ぎを行います。
エージェントプロファイルは、ランナー、モデル、努力量、指示、ファイルアクセスをサポートします。会話はプロジェクトに属し、フォローアップは基盤となる CLI セッションを再開します。会話モデル
- エージェント 1: レビューア は最初の質問を受け取ります: 私たちは何を決定したか、コードは現在何をしているか、対処する価値のあるギャップはあるか？
- エージェント 2: 実装者 はレビューされた回答と制限付きのリクエストを受け取ります: この動作変更を、この範囲で行い、この方法で検証してください。
役割を明確に区別する
両方の役割に同じランナーを選択できます。
有用な区別は、その責任とアクセスにあり、調査と編集の間に明示的なレビューを挟むことです。
いずれかのエージェントが有用な作業を完了する前に、スペシャリストのカタログを作成することは避けてください。実際に区別できる責任から始めてください。ある役割が何を担当し、その完了した出力がどのようなものかを説明できない場合は、別のエージェントを追加する前に役割を明確にしてください。
3.1 レビューア: 不確実性を可視化するブリーフ
レビューアを選択し、@Claude、@Codex、@OpenCode、または @Cursor を使用して関連する会話を添付してください。選択された参照は、実行のための固定コンテキストとなり、タスクが開始されると選択されたエージェントに送られます。参照
このブリーフをコピーして、スロットを埋めてください:
1添付された会話と現在のリポジトリを使用して、[機能またはサブシステム] に関する以前の判断をレビューしてください。23元の判断とその理由を説明してください。関連するコードを確認し、まだ適用されるもの、変更されたもの、利用可能な証拠から検証できないものを特定してください。45あなたの結論を裏付けるファイルを引用してください。[望ましい動作] のために必要な最小限の変更と、検証計画を提案してください。67ファイルは編集しないでください。会話は履歴証拠として扱い、現在のプロジェクト指示との矛盾を報告してください。
レビューを検査する
リポジトリを開いた状態で回答を読んでください。
- 引用をたどってください。
- エージェントがまだ存在すると言っている条件を検査してください。
- 会話が主張したことと、コードが今日示していることとの間に明確な分離があるかどうかを確認してください。
回答が曖昧な場合は、質問を絞り込んでください。動作を制御している正確な条件、または以前の代替案を不適切にした依存関係を特定するように依頼してください。
有用な調査は、証拠が不足している状態で終了する可能性があります。 それは次に何を提供すべきかを示しています。ギャップを曖昧にする回答は、次の判断を難しくします。
3.2 引き継ぎ: 調査結果を実行可能なブリーフに変える
レビューに同意したら、観察可能な動作に基づいて実装リクエストを作成してください。以前の会話で確立された制約を含めますが、この変更との関連性を説明してください。
以下は、私が使用するブリーフです:
1以下のレビューされた調査結果を使用して、[特定の動作] を実装してください。23[既存の動作] をそのまま維持してください。編集は [許可された範囲] に制限してください。変更にその範囲外の作業が必要な場合は、拡張する前にその理由を説明してください。45編集する前に、現在のリポジトリの指示を確認してください。[期待される結果] を [関連するテストまたは手動チェック] で検証し、[重要な失敗ケース] を含めてください。67変更内容、実際に実行されたチェック、および未解決の制限事項の簡潔な説明を返してください。公開またはデプロイしないでください。89レビューされた調査結果:10[確認した調査結果を貼り付けてください]
引き継ぎを具体的にする
それらの括弧には実際の回答が必要です。「良くしてください」では、エージェントが目標を発明することになります。「元のエラーを保持しながら、再試行アクションで失敗したエクスポートを表示する」は、あなたとエージェントの両方に具体的に検査するものを与えます。
レビューされた調査結果をタスクの近くに置いてください。重要な制約が長いトランスクリプトに埋もれている場合は、ブリーフに明記し、裏付けとなる会話を添付してください。
ソースは制約がどこから来たのかを説明します。あなたの現在のリクエストは、それが今日の作業をどのように規定するかを説明します。
4. プロジェクト演習: 繰り返し発生するバグをサイクル全体で処理する
ワークフローを具体的にするための仮想的な演習を以下に示します。あなたのプロジェクトで、ネットワーク中断後に重複したエクスポートが時々作成され、古い会話に再試行動作に関する調査が含まれていると想像してください。
- ステップ 1: まず、その会話を取得します。レビューアに、以前の調査で何が確立されたかを特定するよう依頼し、次に現在の再試行パスをそれと照合します。
- ステップ 2: 古い議論が、不確実な応答の後にリクエストが繰り返される可能性があると述べているとします。レビューアは、現在の実装がまだそれを許可しているかどうか、どのコードがそれを制御しているか、そして重複を防ぐことを目的としたメカニズムが既にあるかどうかを確立する必要があります。
- ステップ 3: 証拠が変更をサポートしている場合は、失敗ケースに焦点を当てて実装者にブリーフを送ります。繰り返されたリクエストが何をすべきか、どの既存のエクスポート動作を維持しなければならないか、そして中断された応答をどのように検証するかを指定します。
- ステップ 4: 次に、変更を検査し、関連するパスを実行します。成功したエクスポートと、不確実性の後の再試行の両方を確認してください。環境が中断を再現できない場合は、その制限を記録し、どのようなさらなる検証が必要かを決定します。
- ステップ 5: 最後に、保持する可能性のある教訓をレビューします: 重複を引き起こした条件、それに対処するメカニズム、修正を裏付ける証拠。
この例は提案された演習であり、Agentic Stack のバグに関する主張ではありません。自分のプロジェクトの実際の失敗に置き換えて、同じ順序を維持してください。
5. 共有レイヤー: 他のツールに検索機能を持ち込む
デスクトップは、Tools → Connections → Use @ in tools → Enable in all four tools を通じて統合をインストールできます。コマンドでの同等の操作は次のとおりです:
1agentic-stack context install
その後、ツールを再起動してください。MCP エントリは、会話検索、選択されたチャットの読み取り、共有メモリー検索を公開します。統合
ピッカーの動作はクライアントに依存します。リソース補完が利用できない場合、エージェントは検索し、一致する会話を提示できます。クライアントの動作
ツール間の継続性をテストする
私の最初のチェックは、別のツールにあなたがレビューしたばかりの同じ判断を見つけるように依頼することです。トピックを与え、一致するソースを提示するように依頼し、分析を依頼する前に選択を確認します。
次に、結果をデスクトップで検査したソースと比較します。ツール間のコンテキストの継続性をテストしているので、質問を安定させたまま、質問する場所を変えてください。
また、判断が作業に実質的に影響を与える場合はいつでも、最終的なタスクのブリーフにソースを含めることをお勧めします。「これについては以前に議論しました」は、エージェントに検索問題を与えます。「このレビュー済みの会話を使用し、この条件を検証してください」は、特定の責任を与えます。
6. 永続的なレイヤー: 教訓として残す価値のあるもの
検索は古いマテリアルを再び視界に入れます。あなたはまだ、そのマテリアルがどのような権威を持つべきかを決定する必要があります。
会話には、放棄された計画、誤った診断、またはプロジェクトが変更される前は妥当だった回答が含まれている可能性があります。それを保存することで、後で推論を検査できます。教訓を受け入れることは、別個の決定です。
Tasks は実行記録を保持します。Knowledge → Lessons は、理由を付けて教訓のステージング、受け入れ、拒否、再検討をサポートします。インポートされた履歴は、受け入れられた教訓とは別に保たれます。レビューライフサイクル
挑戦できる教訓を書く
挑戦できる十分な詳細を含む提案された教訓を書くことをお勧めします: それが適用される条件、推奨する動作、理由、証拠。
仮想的なエクスポートバグの場合、「常に安全に再試行する」は曖昧すぎて役に立ちません。有用なメモは、何が再試行を不確実にするか、そしてこのプロジェクトの実装がどのように繰り返し作業を認識すべきかを特定します。
次に、何がその教訓を時代遅れにするかを尋ねてください。異なるバックエンド、変更された契約、または置き換えられたサブシステムは、元の制約を取り除く可能性があります。将来のレビューが開始する場所を持つように、その境界を含めてください。
これが、有用な修正が、その理由を超えて存続するルールになるのを防ぐ方法です。
6.1 メモリー構造: それぞれの種類の知識を適切な場所に置く
デスクトップの背後では、ポータブルな .agent/ アーキテクチャが、作業状態、過去のエピソード、永続的なパターン、個人の好みを分離します。Skills は再利用可能な手順を提供し、Protocols は権限と委任を記述します。アーキテクチャ
- 現在の調査は、進行中の作業に属します。
- その完了した記録は、何が起こったかの証拠になります。
- 検証されたパターンは、永続的な教訓になる可能性があります。
- 結果をどのように提示してほしいかについての好みは、あなたの好みに属します。
これらの意味を明確にしておくことで、後のレビューが容易になります。一時的な回避策は、いつ削除できるかを説明する必要があります。個人的な文章作成の好みが、誤ってアーキテクチャルールになるべきではありません。
検証された手順をスキルに変える
同じことがスキルにも当てはまります。手順が繰り返すのに十分有用で、従うのに十分具体的である場合に、スキルを作成することをお勧めします。必要な入力、重要なステップ、期待される出力、および別の決定を必要とする条件を含めてください。
エクスポートの例では、調査により有用な回帰チェック手順が生成される可能性があります。その手順があなたのプロジェクトで機能することを確認した後にのみ保存してください。コピーされたトランスクリプトは次のエージェントにストーリーを与えます。レビューされた手順は、評価できる方法を与えます。
7. 運用ルール: 簡潔に、制限して、検査する
以下は、最初のプロジェクトからワークフローに適用するルールです。
- ルール 1: すべてのブリーフは成果物を指定する。 レビューは証拠とともに調査結果を返します。実装はチェックとともに動作変更を返します。教訓の提案は、受け入れるか拒否できる主張を返します。
- ルール 2: アクセスは仕事に従う。 調査は読み取り専用アクセスで開始します。実装は、合意された変更に必要なスコープを取得します。公開、デプロイ、およびその他の結果を伴うアクションは、リクエスト内で明示的にしてください。
- ルール 3: 実際の検証を求める。 レポートは、何が実行され、何が起こったかを示す必要があります。チェックが利用できなかった場合は、欠落した結果を静かに成功として扱うのではなく、それを可視化してください。
- ルール 4: 履歴コンテキストは、現在の証拠および該当するプロジェクト指示に従属させる。 取得された会話は、時代遅れであっても以前の判断を説明できます。
- ルール 5: 結論を保持する前に、結果をレビューする。 エージェントによる自身の作業の説明は、差分および観察された動作と並べて検査するものです。
これらは、私が説明しているセットアップのための運用プラクティスです。プロジェクトに合わせて調整してください。ただし、別の人がタスクがそのブリーフを満たしたかどうかを判断できるように、責任を明確に保ってください。
7.1 レビューキュー: 作業を受け入れやすく、差し戻しやすくする
すべての実装が同じ形式で終了するように依頼することをお勧めします:
- 何が変更されたか、
- 何が検証されたか、
- 何が不確かなままか、
- そして、再利用可能な教訓を提案するかどうか。
これにより、毎回会話全体を再構築することなく、完了した作業を一貫した方法で読むことができます。サポートの詳細は、検査する必要がある部分のために利用可能なままにしておくことができます。
何かを差し戻すときは、修正を見逃した要件に添付してください。「これは間違っています」は、別の推測ラウンドを開始します。「再試行はこの条件下で 2 番目のエクスポートを作成します。元のリクエスト ID を保持し、このチェックを再実行してください」は、ギャップを特定します。
何が生き残る価値があるかを決定する
修正が合格した後、それが繰り返し発生する制約を表すのか、そのタスクの詳細を表すのかを決定してください。前者は、その背後に証拠がある場合に保存します。後者は、タスクの履歴に残すことができます。
すべてのレビューコメントを永続的なメモリーに変えることは避けてください。一部の修正は一度だけ有用です。他の修正は、後の作業を形作るべきルールを明らかにします。 この区別を行うことは、システムを維持するための一部です。
レビューの終わりに役立つ質問は次のとおりです: 将来のエージェントが同様のタスクを試みる前に何を知っておくべきか、そしてその知識はどこで検証できるか？
7.2 コスト規律: すべての実行に停止条件を与える
拡大し続ける可能性のあるタスクには、停止条件を含めることをお勧めします。レビューの場合、それは関連する動作と未解決の質問の文書化された説明かもしれません。実装の場合、それは合意された変更が指定されたチェックに合格することかもしれません。
エージェントがより大きな問題を発見した場合は、その調査結果と元のタスクとの関係を説明するように依頼し、その作業を現在の変更に吸収する前に判断してください。
これが現在のタスクに属するかどうかを決定してください。
結果を比較し、制限を適用する
アカウントで実際に利用可能なオプションを使用してランナーとモデルを選択し、独自の制限された例でそれらを評価してください。1 つの設定をデフォルトにする前に、調査結果の品質、必要な修正、提供された検証を比較することをお勧めします。
タスクとソースマテリアルを固定して、実験を公平に保ってください。すべての試行で質問、コンテキスト、受け入れ基準が変更される場合、比較の解釈は困難になります。
そして、支出管理は、ツールまたはプロバイダーによって実際に強制される場所に配置してください。 エージェントに経済的であるように求める文は好みです。制限に依存する前に、利用可能な管理機能を検査してください。
8. カスタムビルド: 実際の摩擦点に合わせてワークスペースを変更する
基本サイクルを完了すると、デスクトップ自体に何を求めるかについて、より良いアイデアが得られるでしょう。おそらく、繰り返されるナビゲーションステップが気になるか、タスクビューがフィールドを必要以上に検査しにくくしているかもしれません。
機能を提案する前に、摩擦を書き留めてください。実行しようとしているアクション、どこで時間をロスしているか、改善された動作によって何ができるようになるかを説明してください。
次に、ソースリポジトリを開き、エージェントに制限された変更リクエストを与えてください。アプリで結果をどのように検査するつもりかを含めてください。
変更をビルドして検査する
リポジトリは、以下の開発およびパッケージングコマンドを文書化しています:
1python3 -m pytest -q2swift build --package-path apps/macos -c release3python3 scripts/check-desktop-connection.py4bash scripts/build-macos-app.sh --output ./apps/macos/dist
SwiftUI の変更を検査するには、リビルドと再起動が必要です。デスクトップワークフロー
変更の動機となったインタラクションと、壊れる可能性のある近いケースをテストすることをお勧めします。タスクフィルタリングを改善する場合は、フィルタリングされた結果、空の結果セット、および完全なリストに戻るパスを検査してください。
エクスポート演習に適用したのと同じ基準を使用してください: 具体的な変更前、制限された変更、観察された変更後。
8.1 リモートオプション: 作業をどこに置くかを決定する
ローカルワークフローが機能した後、永続的なサーバーでの実行を希望するかもしれません。セルフホスティングパスは、ネイティブアプリを、プロジェクト、メモリー、タスク履歴、CLI サインインを所有するシングルオーナーサービスに接続します。ホストを切り替えても、Mac のデータや資格情報は自動的に転送されません。ホスティングガイド
具体的な理由があってこそ、その移行を行うべきです。例えば、すでに管理しているマシン上でプロジェクトとその実行環境を維持するため、といった理由です。デプロイ作業に着手する前に、その理由を書き留めておきましょう。
サポートされている構成、認証、および検証手順については、ホスティングガイドに従ってください。サーバーを、独自の状態を持つもう 1 つの作業環境として扱い、検査を行いましょう。
選択した環境を検証する
次に、そこで使い慣れたタスクを繰り返します。選択したプロジェクトを確認し、エージェントが意図したソースにアクセスできることを確認し、その結果が自分が選んだサーバー環境に属していることを検証します。
使い慣れたタスクを使用することで、移行の評価が容易になります。ホスト、プロジェクト、ワークフローを同時に変更すると、どの変更が予期しない結果を引き起こしたのかを特定するのが難しくなります。
コアパターンを学ぶには、ローカル環境で十分です。作業に理由が生じたときに、インフラを拡張しましょう。
9. スケーリング：前のサイクルでギャップが明らかになった部分にカバレッジを追加する
実際のタスク中に遭遇する不足しているコンテキストに応じて、このセットアップを拡張します。
- レビューに以前のアーキテクチャに関する議論が必要だった場合は、その議論をインポートします。
- 実装で同じ手順が繰り返し必要になった場合は、スキルを開発して検証します。
- ある決定が何度も再検討される場合は、それを裏付ける証拠とともに、範囲を限定したレッスンを作成します。
すでに答えがわかっている質問をいくつか保持しておきましょう。インポートやワークフローを変更した後に、それらを使用します。つまり、この決定を見つける、この制約を説明する、それを実装するコードを特定する、そして現在は適用されなくなった部分を指摘する、といった質問です。
作業が正当化するときに拡張する
別のエージェントロールを追加するのは、その責任範囲が作業から明確になった場合のみにします。定期的なドキュメントレビューは、専用のブリーフィングを正当化するかもしれません。単発の依頼は、既存のロールに完全に適合する場合もあります。
その地位を獲得した部分を拡張しましょう。 問題が発生したときに理解できるよう、残りの部分はシンプルに保ちましょう。
9.1 メンテナンスの習慣：システムが変更されたときにナレッジを見直す
サブシステムが、その前提を変えるほど十分に変更された場合は常に、関連するレッスンを見直します。変更自体をトリガーとして使用します。新しい依存関係、置き換えられたストレージ層、異なるデプロイ環境、または改訂された製品要件などです。
古い動作に依存している既存のレッスンを特定し、それらのソースを変更内容と一緒に検査します。依然として有効なものは保持し、より狭い範囲が必要なものは修正し、利用可能なレビューワークフローを通じて、もはや適用されないものは廃止します。
重要なのは、説明を保存することです。将来のビルダーは、以前のルールがなぜ存在したのか、そして何が変わってそれを置き換える必要が生じたのかを理解できる必要があります。
手順を更新し、競合を解決する
スキルについては、その入力やコマンドに影響を与える変更の後、手順を再度実行します。ステップが機能しなくなった場合は、観察された障害に基づいて手順を更新し、関連するチェックを繰り返します。
これにより、メンテナンスをプロジェクト内の実際のイベントに結びつけることができます。現在の証拠がすでに目の前にある状態で、最も陳腐化している可能性が高いナレッジをレビューしていることになります。
タスク中に矛盾するメモが見つかった場合は、その矛盾の解決をレビューの一部にします。現在のバージョンに適用されるステートメントを特定し、次のエージェントが調査全体を繰り返すことなく推論を追跡できるように、結果を明確に残します。
有益な引き継ぎを残す
次のセッションの前に、検証済みの結果、未解決の質問、そして別のエージェントが最初に読むべきソースを説明する短い引き継ぎメモを残します。実際に検査したプロジェクトの状態に特化したものにします。
これにより、明日の作業に、たどることができる開始点が与えられます。特に、別のツールを通じて、または時間が経ってから戻ってきた場合でも、元の推論が利用可能です。
10. ビルドシート
- 使い慣れたリポジトリと、認識できる決定事項を 1 つ選びます。
- デスクトップを構築し、セットアップを完了し、その決定事項を含む完了した会話をインポートします。
- それを検索し、ソースを検査し、現在のコードの読み取り専用レビューに添付します。
- 自分で調査結果を確認し、可視的な受け入れ条件を備えた、範囲を限定した実装をブリーフィングします。
- 差分を検査し、作業の動機となった失敗ケースを含む、関連する検証を実行します。
- 結果がそれをサポートする場合にのみ、範囲と理由を記録してレッスンをステージングします。
- 繰り返す価値があると検証した場合にのみ、手順をスキルに変換します。
- 別のツールから同じ検索を試し、実際のタスクで必要になった場合にのみ、コンテキストまたはインフラを拡張します。
今週、1 つの決定事項から始めて、履歴全体をインポートする前に、サイクル全体を実行してみてください。
次のエージェントは、あなたの判断を引き継ぐべきです。
