ce-compound-refresh について
ce-compound-refresh は、学習ドキュメントを現在のコードベースと照合し、根拠に基づいて更新して、ファイルごとのレポートと変更コミットを作成します。エンジニアリング知識を蓄積する開発者向けで、正確な文書の価値を判断する削除は確認後に行います。
主な機能
- 01正確性、重複、矛盾の確認
- 02分類に応じた文書のメンテナンス
- 03用語と CONCEPTS.md の整合
- 04ファイルごとの詳細レポート作成
- 05今回変更したファイルのみコミット
活用シーン
- 01学習内容と現行コードの整合性確認
- 02古いパス、リンク、ガイダンスの修正
- 03確認後に重複文書や価値の低い文書を整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ everyinc/ compound-engineering-plugin --skill ce-compound-refreshインストール後、Claude Code で/ce-compound-refreshを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
assets/resolution-template.mdreferences/classify.mdcommit.mdconcepts-vocabulary.mddiscoverability.mdinvestigate.mdmodes.mdper-action-flows.mdreport.mdschema.yamlscope.mdworth-audit.mdyaml-schema.mdscripts/validate-doc-claims.pyvalidate-frontmatter.py詳細
Compound Refresh
<root>/solutions/ 以下の学びを現在のコードベースと照合して監査し、証拠が裏付けるメンテナンス作業を行い、ドキュメントごとの完全なレポートとコミット済みの変更を提出します。レポートと修正済みドキュメント一式が成果物です。すべてのドキュメントが信頼できてこそ、ストアの価値は積み重なります。
モード
今すぐ references/modes.md を読んでください。 引数からモードを読み取り、各モードで無人のまま適用できる内容、古くなったことを示すフォールバック、質問ツール、CONCEPTS.md のブートストラップについて定義しています。
どちらのモードにも、2 つのルールが適用されます。書き込みに失敗した場合は推奨として記録し、実行を続けます。また、質問はホストのブロッキングツール、またはこのリファレンスで定義されている番号付き選択肢のフォールバックを通じて行います。質問を黙って省略することはありません。
価値の判断基準
通常のリフレッシュでは、正確性、つまり各ドキュメントが今も正しく、他と区別されているかを判断します。リポジトリ内の別の場所にも同じ知識が記載されているという理由だけで、正確なドキュメントを削除することはありません。もう一方の判断である価値の監査は、ユーザーがそれを依頼し、確認した場合にのみ行います。対象範囲全体をコードベースと照合し、正確なドキュメントも削除することがあります。
この意図があるかどうかは、呼び出し時の引数から読み取ります。ユーザーがドリフトの確認ではなく、どのような表現であれ、ストアの整理、選別、削減、縮小、改善、またはキャプチャ基準への引き上げを望んでいる場合です。この意図がある場合は、調査を始める前に解釈を伝え、確認を求めてください。
You asked to clean up the learnings. Which do you want?
1. Delete or shorten docs the codebase already explains. A doc goes when a test, a code comment, or the instructions file states the same reasoning, and every cut quotes that file. Drift is fixed too. Scope: <scope>.
2. Fix drift only. Stale paths and links, duplicate docs, and guidance the code no longer supports. Nothing accurate is deleted.
選択肢 1 の場合は、調査の前に**references/worth-audit.md を読んでください**。このリファレンスには、基準、証拠のルール、振り分け方法が追加されています。選択肢 2 の場合、またはその意図がない場合は、このリファレンスを読まず、その基準も適用しないでください。実行全体を通じて、正確性のリフレッシュのみを行います。非対話モードでは確認できないため、推定された意図をどう扱うかは references/modes.md に記載されています。
成果物ルート
<root>/solutions/ のパスを初めて組み立てる際に、<root> を解決してください。設定ファイルではなく、解決済みの <root>/solutions/ のパスをサブエージェントに渡してください。サブエージェントを起動する際は、必ず mode パラメーターを省略し、ユーザーの権限設定を適用します。
成果物パスを組み立てる前に、CE 成果物ルート <root> を解決してください。
- 読み取るのは
<repo-root>/.compound-engineering/config.yamlにあるdocs_rootのみです(<repo-root>はgit rev-parse --show-toplevelで取得)。config.local.yamlからは読み取らないでください。未設定の場合、従来どおり<root>はdocsです。 - 設定値を検証してください。リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実パスがリポジトリ内に収まり、リポジトリルートでも
.git/配下でもない必要があります。それ以外の場合は、docs_rootとその値を明示したエラーで停止してください。決してdocsにフォールバックしないでください。 - 成果物の場所には
<root>のみを使用してください。存在しない場合は作成し、各パスをこのスキル固有のサブディレクトリを使って<root>/<subdir>として組み立ててください。また、docsを併せて読み取らないでください。
対象範囲
対象候補は、README.md と _archived/ 配下を除く、<root>/solutions/ 以下の .md ファイルです。ヒントに一致するものがない場合でも、対象範囲は広げません。references/scope.md を読んでください。対象を絞る方法、該当なしの場合に各モードが行う処理、ストアが空の場合のメッセージ、優先順位、各アクションに伴う README の行の整理について記載されています。
調査
古さを判断する観点、自動メモリーのルール、サブエージェントの役割、カテゴリ構成に関する注意事項については、references/investigate.md をお読みください。
各学習内容を現在のコードベースと照らし合わせて確認してから、全体を対象に重複、置き換え、矛盾がないかを確認します。矛盾は積極的に誤解を招くため、個々の古さより優先して対処します。
ナレッジトラックの学習内容が、スキルの SKILL.md、ランブック、指示ファイルなど、名前やリンクで指定したガイダンスファイルを参照している場合があります。学習内容で指定されたガイダンスのみを比較してください。ガイダンス層から検索してはいけません。
調査を行うすべてのサブエージェントのプロンプトには、その参照資料の Subagent prompt にある3つの条項をそのまま含めます。2つは検索ツールと自動メモリーに関するものです。3つ目は次のとおりです。
学習内容がナレッジトラックに属し、ガイダンスファイル(スキルの
SKILL.md、ランブック、ルート指示ファイル)を名前やリンクで指定している場合は、そのファイルを読み、同じ手順について異なる順序や矛盾するルールが記載されているときは、矛盾する両方の引用と、どちらに現在のコードが従っているか、またはコードからはどちらも確認できないことを返してください。学習内容で指定されたガイダンスのみを読み、ガイダンスを探してはいけません。また、編集してはいけません。
分類
すべてのドキュメントには、Keep、Update、Consolidate、Replace、Delete のいずれか1つだけを割り当てます。ドキュメントをその場でアーカイブしてはいけません。バージョン履歴がアーカイブであるため、_archived/ はありません。
分類を割り当てる前に、references/classify.md をお読みください。 各結果の意味、Update と Replace の境界、自動削除ルールとその事前確認、移動と分割のルール、検索価値のテスト、検証できないことは誤りを意味しないという原則、パターンドキュメント、対話モードでの質問について定めています。
証拠の内容にかかわらず、次の2つの境界は守ってください。このスキルは製品コードを変更しません。現在の動作に関する主張は現在のコードに従いますが、実装が満たさなくなったという理由だけで、独立した根拠があるガイダンスまで誤りになるわけではありません。ガイダンスの証拠に基づいてドキュメントを分類し、実装との不整合は製品の回帰の可能性として報告してください。また、学習内容がガイダンスと矛盾する場合は、リフレッシュでその旨を報告します。スキル、ランブック、指示ファイルを編集してはいけません。
実行
references/per-action-flows.md を読み、各ドキュメントの分類に該当するセクションに従って、ドキュメントごとに1つずつフローを実行します。基準、移動と分割の手順、置き換えを行うサブエージェントとの契約、引用の整理について定めています。
用語の取り込み
ドキュメントごとの対応後、調査中に指摘されたドメイン用語を CONCEPTS.md と照合します。必ず references/concepts-vocabulary.md をお読みください。 該当条件は自明ではないため、これを読まずに「該当する用語はない」と判断するのは、結果ではなく近道です。
すべてのモードで編集内容は通知せずに適用します。レポートの CONCEPTS.md の行には、「スキャン済み、該当用語なし」も含め、スキャンで確認した内容を記録します。
レポート
レポート全体を Markdown で出力してください。 これは納品物であり、非対話モードではこれだけを出力します。自己完結させ、省略せず、Applied と Recommended に分けてください。要約ブロック、ファイルごとの詳細、Recommended に記載する内容については、references/report.md をお読みください。
コミット
変更がなければスキップします。それ以外の場合は、このリフレッシュで変更したファイルのみをステージングし、リポジトリの規約に従ってコミットします。モードごとのブランチ判断と git の失敗時のフォールバックについては、references/commit.md をお読みください。
発見しやすさの確認
レポートの出力後、プロジェクトの指示に従うことで、エージェントがドキュメント化された領域で作業を始める前に <root>/solutions/ を確認するようになっているかチェックします。毎回実施してください。エージェントが見つけられなければ、ナレッジの価値は積み上がりません。読者に伝えるべきこと、最小限の追加ルールとその文体、CONCEPTS.md での扱い、モードごとの同意とレポート行の違い、後から行う編集をコミットに含める方法については、references/discoverability.md をお読みください。