prior-work-retrieval

過去の作業の検索

上記のトリガーがある場合に限り、本格的な制作に着手する前に実行します。読み取り専用の現状確認は、ユーザーが履歴を求めない限り直接行います。目的は、別の要約を生成することではありません。答えるべきなのは、すでに何が存在するか、どの情報源が最新か、何を再利用すべきか、そして本当に新しい作業として残っているものは何かです。

対象外：現在のファイルの確認、通常のバグ修正、機械的な検証、または最終回答がたまたまレポート／要約になるだけのタスク。現在／既存のテスト、README、ファイル、実装、動作、検証への言及は、それだけでは過去の作業の検索を求めていることにはなりません。新しい作業が何かと重複する可能性があるというだけで、トリガーがあると推測しないでください。そのリスクだけでは、明示的な依頼にはなりません。

完了条件

検索プロセスは、次の5つをすべて満たした場合にのみ完了です。

1. タスクの本来のビジネス上の成果を、1文で記述している。
2. マニフェストで宣言された関連する情報保持先がすべて、searched、manual_completed、または明示的な失敗／カバレッジ不足を報告している。
3. 候補として挙がった主張は、検索結果の抜粋だけで判断せず、元のパスまたは記録を開いて確認している。
4. 採用した各項目について、現在のタスクに結びついた理由とともに、reuse または adapt の判断を記録している。何も採用しなかった場合は、記録に具体的な no_reuse_reason を記載している。
5. scripts/prior_work.py check が、このセッションの記録を受け付ける。

retrieved は verified ではなく、verified は reused ではありません。「検索した」ことを「最適な過去の作業を活用した」こととして扱わないよう、これらの状態を分けてください。

ワークフロー

1. まずローカルの運用コンテキストを読む

検索する前に、現在のプロジェクトの AGENTS.md／CLAUDE.md、ナビゲーションインデックス、およびそれらが指定する North Star／現在の決定に関するファイルを読んでください。過去の資料が、より新しい明示的な決定に優先することはありません。

2. 明示的な情報源マニフェストを検証する

マニフェストで定められた範囲のみが検索対象です。慣例上あるはずだという理由だけで、ディレクトリが存在するものとみなさないでください。デフォルトのパス：

uv run --no-project python scripts/prior_work.py \
  --manifest <path> validate-manifest

デフォルトは ~/.config/daymade/prior-work/sources.json です。プロジェクトで別のパスを指定することもできます。グローバルオプションはサブコマンドより前に指定します。スキーマと情報保持先の例は references/source-manifest.md にあります。

3. 宣言されたキャリア全体を対象に検索する

ユーザーの求める成果と、提案する実装は分けて記述します。そのうえで、次の2種類の用語を指定します。

• --outcome-term：すでに完了した成果（受理済みの成果物、正本のトランスクリプト、デプロイ済みのサービス、決定、運用上の証跡）を特定できる、成果物／イベント／エンティティ／日付の用語1～5個。
• --term：実装に関する用語（コードシンボル、過去のワークフロー名、技術用語、障害の症状）1～8個。

ランタイムは、業務上の成果に関するクエリをドキュメント、会議、アーカイブ、会話に送信し、実装に関するクエリをコードおよびSkillキャリアに送信します。成果の候補が優先して順位付けされます。そのため、コード検索だけで、求められた成果がすでに存在するかどうかの確認を済ませることはできなくなります。「做 / 优化 / 系统」のような一般的な動詞だけを渡さないでください。

uv run --no-project python scripts/prior_work.py retrieve \
  --business-outcome 'the observable result the user actually needs' \
  --outcome-term 'accepted artifact, entity, event, or date' \
  --query 'the implementation or workflow currently being considered' \
  --term 'distinctive entity' \
  --term 'old workflow name' \
  --term 'failure symptom' \
  --session-id "$CODEX_SESSION_ID"

出力を保存するためにリダイレクト（> /tmp/run.txt）しないでください。設計上（2026-08-27に test_unquoted_redirection_even_after_ route_stays_gated でリグレッションを検出するテストにより固定）、ファイルへのリダイレクトを行うと、読み取り専用のルートコマンドでも書き込みゲートが作動します。そのため、リダイレクトした検索はブロックされ、実行 JSON は指定した場所に保存されません。出力はそのまま表示させ、トランスクリプトから読み取ってください。永続的なコピーは、マニフェストの state_dir にある実行 JSON です（run_path は最終行に表示されます）。

--session-id は retrieve、complete、check でのみ使用してください。validate-manifest はこれを受け付けません。Codexでは $CODEX_SESSION_ID を使用してください。Claude Codeにはそのような環境変数がないため、以前の作業に関するフックメッセージ（UserPromptSubmit inject / PreToolUse deny / Stop block）にそのまま記載された正確なIDを使用します。その横に表示されるレシートのファイル名はIDそのものではなく、そのIDのsha256です。推測したIDでレシートを完了すると、check が読み取らないファイルが書き込まれ、ゲートは引き続き拒否します。ハッシュのようなファイル名をIDの代わりに使わないでください。

通常は任意のライブキャリアがリクエストに関係する場合は、--require-source live-wechat を明示的に指定して必須にしてください。その手動ルートが記録されるまで、レシートは完了できません。

このコマンドは rg でファイルシステムのキャリアを検索し、明示的に宣言されたコマンドアダプター（たとえば、正式なClaude履歴検索ツール）を呼び出し、ライブのWeChatなどの手動ルートを提示します。コンテンツ検索は常に宣言されたglobの範囲内に限定されます。パス全体の列挙は、成果または実装に関する用語が明示的にパス形式（ファイル名、パス、またはISO日付）になっている場合に限って実行されます。project_doc_max_bytes のようなシンボルだけでは、ワークスペース内のすべてのファイル名をたどる理由にはなりません。このコマンドは、マニフェストの state_dir に変更不可の実行 JSON を書き込み、その run_id を返します。

必須のキャリアが manual_required を示した場合は、指定されたSkillルートを実行し、完了前にその結果を記録してください。ローカルのWeChatアーカイブを検索しても、ライブのWeChatをカバーしたことにはなりません。会話インデックスがあっても、会議やコードをカバーしたことにはなりません。

4. 候補を正規の情報源で確認する

デプロイ済みの成果物を探す依頼では、まず対象のシステムと、求められている状態（過去の版、特定の時点で使われていたもの、または現在のデプロイ）を特定します。関連する設計文書は候補の一つであり、探しているファイルそのものとは限りません。名称が似た実験を選ぶ前に、プロジェクトの成果物やデプロイの管理者を確認してください。実行時の証拠を確認できる場合は、回答する前に取得してください。「未検証」という但し書きを添えても、検索を完了したことにはなりません。ユーザーが過去の草稿を明示的に求めている場合は、稼働中のものかどうかを確認せず、その版を返します。

有望な候補は、元のパスで開いてください。以下を確認します。

• 一致性：単に同じ単語が含まれているだけでなく、同じビジネス上の課題を解決するものですか？
• 権威性：現在の実装や SSOT は過去の提案より優先されます。生の会話記録は、何が話されたかの証拠にはなりますが、それが今も正しいことの証拠にはなりません。
• 鮮度：現在の Git HEAD、ファイルの更新日時、決定日、置き換え済みを示すマーカーがあれば比較します。アーカイブを使って現在の動作を上書きしないでください。
• 結果の証拠：完了したように見えるプロセスよりも、コード、テスト、受け入れ済みの成果物、運用結果を優先します。

ヒットの一群を退けること自体が、一つの主張です。 キャリアが多数の一致結果を返し、そのすべてが無関係だと判断した場合――「ドキュメント内でその用語が引用されているだけ」「無関係なモジュールだ」など――その判断は、目的の結果にたどり着くまでの絞り込みではなく、これから報告しようとしている所見です。退ける形状の種類ごとに、少なくとも1件のヒットを開き、どの種類をどの証拠に基づいて除外したかを報告に記してください。47件の一致結果を返しながら回答には何も寄与しないキャリアも、結果を何も返さないキャリアと同じ観察結果です。他の否定的な結果と同様に、同じ慎重さで扱う必要があります。結果を生み出した実行は問題なくても、その読み取り方が間違っている可能性があります。

5. 再利用レシートを完成させる

アーカイブされたリクエストに実際のファイル読み取りが含まれている場合は、まず verify_artifact.py を使用して、近くにある参照資料ではなく、選択した成果物を、関連付けられたツール結果と照合します。

uv run --no-project python scripts/verify_artifact.py \
  --candidate /tmp/agent-backup.zip --member skills/editor/SKILL.md \
  --archive /tmp/request.json.gz --read-path /agent/skills/editor/SKILL.md

チェッカーは、request_id、タイムゾーン付きの timestamp、および Anthropic のツール呼び出し形式の request.body.messages を含む JSON／gzip バンドルを受け付けます。通常のファイルの場合は --member を省略してください。終了コード 0 は、候補のバイト列が記録時刻に成功した相関先の read に現れたことを意味します。生バイトを返す読み取り元（read／read_file）ではバイト単位で完全一致し、Claude Code の Read では、絶対行番号がファイル全体を網羅していることを証明でき、その行からファイルを再構成できる結果である必要があります（部分的な offset／limit 読み取りでは決して合格しません。JSON の match_basis に該当する証明方法が示され、rejected_read_reconstructions には網羅性の前提条件を満たさなかった行番号付き読み取りの件数が記録されます）。1 は一致する証明がないこと、2 は証拠が無効または曖昧であることを意味します。パスへの言及、失敗した読み取り、関連する古いファイルは合格しません。ほかの証拠形式はソース固有のリーダーで引き続きサポートされます。サポートされていない形式を否定的な主張に変換しないでください。

アーカイブは、検証済みシステムのソース固有のリーダーまたは可観測性ツールから取得する必要があります。このチェックでは、アーカイブの真正性を認証したり、ユーザーの意図したシステムを判断したり、現在のデプロイ状況を確認したりすることはできません。また、すべての依存関係が回収されたことも証明しません。引き継ぎでは、これらの違いを保ってください。成果物を取得した場合は、選択した成果物／メンバーと、それに一致する証拠を採用理由に記録します。ロケーター文書だけに関するレシートでは、最終成果物が正しいことを確認できません。

実際に確認した項目を分類します。

uv run --no-project python scripts/prior_work.py complete \
  --run <run_id> \
  --reuse '<candidate_id>=reuse unchanged because ...' \
  --adapt '<candidate_id>=adapt boundary X because ...' \
  --session-id "$CODEX_SESSION_ID"

該当するものがない場合は、検証済みの不一致を --no-reuse-reason に指定してください。「該当なし」は理由ではありません。検索時の観察結果であり、検索語を広げたり、失敗したキャリアを解決したりする必要がある場合があります。必須キャリアの候補がゼロ件であっても、言い換えによって「存在しない」と報告することはできません。インデックスプロバイダーの対象範囲と鮮度を確認し、インデックス検索の語句を絞り込み、残るギャップを報告してください。インデックス化されていない履歴全体に対するラベルの一括調査は実行しないでください。

信頼度が低い結果は、結果がゼロということではありません。 キャリアが terms_passed: false とともに result_count > 0 を返した場合は、レシートを作成する前に、ランク付けされた結果を開いて確認してください。terms_passed: false が示すのは、上位 K 件の中にクエリ語句が文字どおり現れなかったことだけです。結果に関連性がないという意味ではありません。ハイブリッド検索や BM25 ランキングでは、上位のヒットが探していた同義語そのものであることもよくあります。結果を読んでからレシートを作成してください。

この要件は、レシートで何を示せる必要があるかに関するものです。no_reuse_reason では、名前を挙げた結果と、それぞれがなぜこのタスクを解決しないのかを示す必要があります。「この3件を読み、別のシステムを対象としていることを確認した」は理由になります。一方、キャリアが12件のヒットを返したのに誰も開いていない場合、「ユーザーがこれについて話した記録がない」は理由になりません。これを上記の候補ゼロ件の条項と組み合わせてください。前者は何も返さなかったキャリアを対象とし、後者は返された結果をまだ却下する根拠を得ていない場合を対象とします。どちらの方向も解決する必要があります。そうしなければ、未確認の結果群がいつの間にか不在を主張する根拠になってしまいます。

完成したレシートでは business_outcome と outcome_terms が保持されます。check は、どちらかのフィールドが欠落した古い形式や手作業で作成されたレシートを拒否します。レシートの鮮度は、必須キャリアの定義に紐付いています。任意キャリアを編集しても、検証済みの必須カバレッジは無効になりません。必須ルート、ルート、モード、権限、または上限を変更すると無効になります。完全なマニフェストハッシュは出所情報として保持されます。続いて、次のコマンドで検証します。

uv run --no-project python scripts/prior_work.py check \
  --session-id "$CODEX_SESSION_ID"

この検証に合格してから、本格的な本番作業を始めてください。実装や計画に採用した候補 ID を記載し、レシートが形式だけの書類にならず、成果物と結び付くようにします。

関連フック

マニフェストが有効で、セルフテストが成功した後にインストールします。

scripts/prior-work-retrieval.sh --selftest
scripts/prior-work-retrieval.sh --install

バージョン管理されたラッパーは、同期フックランタイムの SSOT です。Python インタープリターを直接解決し、パッケージマネージャー／キャッシュのライフサイクルには入りません。上記の uv run ... prior_work.py コマンドは、フックの起動用ではなく、明示的な検索およびレシート操作として扱ってください。

インストーラーは、無関係なフックを置き換えることなく、Claude と Codex の両方に必要なハンドラーを追加します。

• UserPromptSubmit は、過去の作業／再利用／履歴を明示的に示すシグナルがある場合にのみ、プロンプトにスコープされた要件を作成し、スキルのルートを挿入します。フィルターにより、ユーザーが求めていない内容でこのシグナルが作動するのを防ぎます。
  • ユーザーの発言ではないもの。 内部テンプレート（You are a/an …、# Overview）、ハーネスのエンベロープ（<agent-message …>、<task-notification …>、<system-reminder …>）、貼り付けられた会話ログの行（⏺ …）は、すべてプロンプトとしてこのハンドラーに届きます。要件が設定されることはありません。
  • 実行者がゲートを満たせない場合。 スキルの読み取りやシェルの実行を禁じるプロンプトでは、レシートの作成に必要な機能が使えません。ゲートを設けると、解除する手段のないまま作業を妨げることになります。過去の作業の検索を明確にオプトアウトするプロンプトは、skip／disable だけでなく、実際に使われる表記（Do NOT perform prior-work retrieval、opts out of prior-work retrieval）でも尊重されます。
  • 再利用を否定する表現。 「不要复用 X」、「别沿用」、「don't reuse」は過去の作業を使わない意思を示します。また、何かを古いものとして述べる表現（「很久之前写的」）は、それが古くなっていることを示すもので、検索を求めるものではありません。どちらもマッチング前に除外されるため、同じ文にある実際の依頼は引き続き認識されます。一方、再利用を求める「别重复造轮子」／「不希望你重新造」は、引き続き要件を設定します。
  • 婉曲な記憶の確認には、離れた対象を指す語が必要です。 上次／好像是／我记得是／记不清 は、離れた対象または不特定のものを指す限定詞（那个／某个／哪个 脚本）を伴う場合にのみ要件を設定します。なぜなら、这个脚本 は目の前にある対象だからです。「这个脚本好像是死循环」はバグ報告であり、過去の記憶を尋ねる表現ではありません。同様に、history 単独の場合も、それを指す語句が必要です（conversation history は対象になりますが、git history は対象になりません）。
  • 有効なレシートがすでにこのセッションをカバーしている場合。 婉曲な記憶の確認では、完了済みのレシートが宙に浮くような新たな要件は設定されなくなります。過去の作業を明示的に新しく依頼した場合は、引き続き要件が設定されます。

scripts/prior_work.py audit を実行して、ゲートが適切に動作しているか確認してください。トリガーの内訳、空ゲート率（要件が設定されたもののレシートが作成されなかった割合。対応できない内容にゲートを設けたことを示す指標）、宙に浮いたレシート、ユーザー以外の入力による要件設定、要件を設定し続けている各項目のマッチしたトークンが報告されます。機械処理可能な出力には --json を指定してください。ゲート自身のテストが通るかではなく、この数値でゲートを評価してください。

• PreToolUse は、明示的な要件の適用がまだ完了しておらず、有効なレシートもない場合に限り、重要な書き込みをブロックします。通常の書き込みを検索の義務に変えることはありません。要件が有効な間も、読み取り専用の調査や小規模な機械的編集は引き続き可能です。
• Stop は、適用がまだ完了していない明示的な要件を検証します。出力の長さ、コード、ツールの使用、一般的な本番向けの依頼から要件を新たに作り出すことはありません。検証が成功すると、レシートは保持したまま、このバッチに対する適用範囲が終了します。その後、明示的に検索を依頼すると、新しい要件が開始されます。それまでは、通常の追加依頼や継続を示す表現によって自動的に解除されることはありません。明示的に解除するには、既存のユーザーオプトアウトを使用してください。

より限定的な未バージョンの recall-first-evidence UserPromptSubmit ハンドラーを、この上位互換のハンドラーに移行します。復旧用に、そのスクリプトはディスク上に残します。以前のトリガー群（「我们之前」、「什么来着」、曖昧な記憶）は回帰テストです。インストール後、マシンのプロファイル設定同期ツールを実行し、すべての Claude プロファイルにメイン設定を反映してください。Codex では /hooks から人間による信頼確認が一度必要です。インストーラーがこれを偽装することはありません。 ユーザーは、現在のプロンプトに対して過去の作業を検索しないよう明示的に指示できます。 そのオプトアウトはプロンプトスコープの状態となり、環境変数によるバイパスではありません。 認識される言い回しは、拒否動詞（不用/不要/不需要/跳过、または skip/disable/opt out/do not perform）と検索名詞（查历史/历史检索/ prior-work/prior work/history retrieval）を同じ文中で組み合わせたものです — キャリアフレーズを伴わない単なる 「不需要检索」は一致しないため、ゲート途中でユーザーに助言する際は、「本任务不需要 prior work 检索」のような完全な有効形を引用してください。 マニフェストまたはレシートの状態が不正/欠落している場合、実質的な本番でのみフェイルクローズします。読み取り専用の調査と、まさにマニフェストのパスを対象とした書き込みは引き続き可能であり、エージェントはゲートをバイパスせずに修復できます。

検索ルーティング

ニーズ	ルート
プロジェクトのコード/ドキュメント内の既知の正確な文字列、シンボル、パス	ファイルシステムキャリア（rg）。そのプロジェクトに限定し、会話ストアを再帰的に grep しない
意味は覚えているが、言い回しが変わっている	宣言されたセマンティックアダプター（gbrain または索引化された履歴リコール）。まずプロバイダーのスコープと鮮度を確認する
意味は覚えているが、プラットフォームが Codex の可能性がある	インデックスが Codex をカバーしている場合は history_index.py recall --provider codex。そうでなければギャップを報告する
過去の Claude のツール/思考/ファイル履歴の正確な証拠	索引化された候補の発見、続いて正確なセッションリーダー。生のコーパススキャンなしで候補を選択できない場合は unknown を報告する
プラットフォームが不明、複数、または Claude 以外である過去の会話の証拠	local-conversation-history。各プロバイダーは別々のストアであるため、Claude のみの回答では「それは議論していない」を裏付けられない
会議の決定または発言者の主張	プロジェクトの文字起こしキャリア。生の発言者のターンを開く
アーカイブされた WeChat のテキスト/音声の文字起こし	宣言された WeChat アーカイブキャリア
ライブ/最新の WeChat	read-wechat-messages。手動カバレッジを記録する
現在のコードの挙動	現在の Git リビジョンで実装/テストを開く
作業がリモートボックスまたは外部のチェックアウト（デプロイディレクトリ、上流フォーク）を対象とする	そのリポジトリ自身の docs/、Makefile、デプロイ README を最初に — それらはマニフェストキャリアではないため、手動カバレッジとして記録し、そのボックスがすでに文書化しているビルド/デプロイコマンドを決して再構築しない

境界

• マニフェストは明示的であり、可変のインデックス状態とは別にバージョン管理されます。
• 検索結果は仮説です。レシートは検証と再利用を記録します。
• プライベートなプロジェクトデータを公開の例や Skill フィクスチャにコピーしないでください。
• 失敗した必須キャリアから暗黙にフォールバックしないでください。ギャップを記録してください。
• 外部の Web リサーチは、ユーザーが最新の外部事実を明示的に求める場合、またはローカルの証拠では回答できない場合を除き、ローカルの過去の作業の後に開始します。
• この Skill がワークフローです。コンパニオンフックは Write/Edit の前に新しいレシートを要求する場合があります。Stop は同じ既存の義務を強制する場合がありますが、最終回答の形が新しい義務を生み出すことはできません。フックはどの候補が良いかを決定しません。

サーフェス契約

セッションでの初回使用時: python3 scripts/surface_version.py を一度実行し、12 文字のフィンガープリントに注目してください — これはこの skill の scripts/**/*.py コードサーフェスの sha256 です。この skill について最後に見たフィンガープリントと異なる場合、コードがあなたの下で変更されています。コンテキスト内のエコーに基づいて行動する前に、この SKILL.md と参照をディスクから再読してください。フィンガープリントはコードのみを対象とします。ドキュメントの編集はこれを変更しません。

メンテナー検証

uv run --no-project python -m unittest discover -s tests -p 'test_*.py'
uv run --no-project python scripts/prior_work.py \
  --manifest tests/fixtures/manifest.json validate-manifest
scripts/prior-work-retrieval.sh --selftest

リグレッションケースには、実際の失敗ファミリーを含める必要があります。すなわち、クロスプロジェクトルールが読み込まれない、既存のプロバイダー契約が無視される、古い決定が North Star に優先する、アーティファクト機能が存在しないと宣言される、隣接するエージェントの証拠が見落とされる、そして会話/会議/WeChat キャリアのギャップがグローバルな「検索済み」主張によって隠される、です。