crewlore について
crewlore は、コーディングエージェントのセッションとリポジトリのプルリクエストから、Git で管理できるプレーンテキストのチームナレッジブックを作成します。決定、手順、注意点を再利用したい開発チーム向けで、出典の引用と不採用の記録も残します。
主な機能
- 01セッションとプルリクエストの編纂
- 02決定、手順、注意点の抽出
- 03原文引用の検証
- 04採用・不採用の記録
- 05リポジトリのナレッジブック検索
- 06ファイルと MCP クエリの提供
活用シーン
- 01チームの知見を後続のコーディングエージェントに引き継ぐ
- 02コード変更に関する過去の決定を検索する
- 03案が不採用になった理由を確認する
MCP 対応
`lore serve` で MCP サーバーとして動作し、コマンドを実行できないアシスタントにリポジトリのナレッジファイルと MCP クエリを提供します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
コーディングエージェントは、チームがすでに解決したことを何度も学び直しています。
crewloreは、エージェントがすでに生成しているセッションと、リポジトリのプルリクエストを読み込み、決定事項、手順、注意点を抽出して、リポジトリ内のプレーンテキストのナレッジブックに書き込みます。各エントリーには、その情報の出どころとなった正確な行が引用され、チームが採用したのか、試して採用しなかったのかが記録されます。自分のモデルキーを使って、自分のマシン上で実行できます。
機能と使い方を60秒でご紹介します:
https://github.com/user-attachments/assets/b16cb272-da48-4756-89ba-1cc626629e0c
ターミナルで同じことを実行します。 以下の録画は同梱のデモ uv run python scripts/demo.py --step です。APIキーは不要です。少数の合成セッションをブックにまとめ、チームが試して採用しなかった主張も含まれています。
pipx install crewlore
必要なもの: Python 3.10 以降、モデルキー(ANTHROPIC_API_KEY または OPENAI_API_KEY)またはローカルの OpenAI 互換モデル、プルリクエストをまとめる場合はGitHub CLI(gh auth login)、以下のキー不要のデモを実行する場合のみ uv が必要です。
クイックスタート
チームのナレッジが現在どこにあるかに応じて、2通りの方法があります。
すでに Claude Code を使っている場合。 lore に、ディスクに書き込まれたトランスクリプトを指定します。デフォルトでは、このリポジトリ自身のトランスクリプトのみを読み込み、マシン上の他のプロジェクトのものは読み込みません。
cd my-repo
export ANTHROPIC_API_KEY=... # or OPENAI_API_KEY, or a local model in .lore/config.yaml
lore init # create .lore/ in your repo
lore watch # read this repo's transcripts, scrub secrets, compile, prune — on an interval
lore query "billing webhook" # ask the knowledge layer anything, anytime
リポジトリはあるものの、セッションがまだない場合。 代わりに、プルリクエストのスレッドをまとめます。コーディングエージェントは、試したこと、失敗した理由、直面した制約など、推論の多くをPRの説明やレビューに記述するため、ローカルでエージェントを実行したことがないリポジトリにも、すでにナレッジレイヤーが用意されています:
cd my-repo
export ANTHROPIC_API_KEY=...
lore init
lore import-prs owner/repo # closed PRs by default, agent-authored only; uses your gh login, stores no token
lore query "billing webhook"
どちらの場合も、.lore/ をコミットすれば、チームメンバーは次回の git pull でブックを利用できます。.lore/ 自身の .gitignore により、生のトランスクリプト、生のPRエクスポート、抽出キャッシュ、使用状況カウンターはgitの対象外になります。
インストールでお困りですか?
pipx が Broken Python installation, platform.mac_ver() returned an empty value というエラーで失敗する場合、デフォルトのPythonが壊れたインストールです(ごく最近のHomebrew版Pythonで見られることがあります)。これはパッケージではなく、pipxが使用するインタープリターの問題です。正常に動作することが確認されたものを指定してください:
pipx install --python python3.13 crewlore
今後、pipxでPython 3.13をデフォルトにするには、export PIPX_DEFAULT_PYTHON=$(which python3.13) を設定します。
APIキーなしで試す
git clone https://github.com/srijansk/crewlore.git
cd crewlore && uv run python scripts/demo.py
デモでは、同梱の合成セッションを使って一連の処理を実行し、まとめたブック、そのブックへのクエリ、3つのチェックを表示します。これはおもちゃのデータを使った仕組みのデモであり、ベンチマークではありません。
アシスタントに使わせる
lore install # the /lore skill, for the assistants found on this machine
lore install --project --always-on # into this repo, plus a short block in CLAUDE.md / AGENTS.md
lore install --project --hooks # plus Claude Code hooks: a file's claims as it is read and edited
- スキルは、
.lore/があるリポジトリでコードを変更する前にlore queryを実行すること、「not adopted」の主張を却下された作業として扱うこと、主張を指示ではなくチームメイトのコメントと同じように評価すること、そしてlore feedbackでフィードバックを返すことをアシスタントに伝えます。Claude Code、Cursor、Gemini CLI にはそれぞれスキルディレクトリが用意されます。Codex は、フレームワークを横断する Agent Skills ディレクトリ(~/.agents/skills/、または--projectを指定した場合はリポジトリ内の.agents/skills/)を読み込みます。 --always-onは、アシスタントの指示ファイル(CLAUDE.md、AGENTS.md、GEMINI.md)に短いマーク付きブロックを追加します。Cursor の場合は、.cursor/rules/に常時適用されるルールを追加します。--hooksは Claude Code に 2 つのフックを設定します。アシスタントがファイルを読み取るか編集すると、そのファイルを対象範囲とする主張がコンテキストに加わります。対象範囲ごと、会話ごとに 1 回だけ加わり、却下された作業が最初に表示され、サイズ上限を理由に削除されることもないため、編集前に確認できます。各プロンプトでは、lore queryと同じように、そのプロンプトに関連する主張が表示されます。読者が訂正した主張には、メモとともにcorrectedのマークが付きます。追加するものがない場合、フックは何も表示せず、何が起きても終了コード 0 で終了するため、crewlore を使っていないチームメイトの作業が妨げられることはありません。コンテキストの圧縮後は、表示済みの対象範囲が再び表示されます。- ユーザーのファイルが上書きされることはありません。 書き込まれるすべてのファイルには crewlore マーカーが付きます。インストール時には、自分が書き込んだものでないスキルの置き換えを拒否します(
--forceで上書きできます)。lore uninstallが削除するのは、マーク付きファイル、マーク付きブロック、crewlore 独自のフックエントリのみです。 - Claude Desktop などのコマンドを実行できないアシスタントは、代わりに MCP サーバーを使用します。
lore serveを実行してください。詳しくはdocs/mcp.mdをご覧ください。
Claude Code プラグインとしてインストールすることもできます。 Claude Code のセッションで次を実行します。
/plugin marketplace add srijansk/crewlore
/plugin install crewlore@crewlore
このプラグインは、同じ /lore スキル(/crewlore:lore として呼び出されます)と、インストーラー自身のテキストから生成された同じ 3 つのフックを使用します。そのため、プラグインと lore install --hooks は同じファイルを導入する 2 つの方法です。両方を使うと Claude Code が各フックを 2 回実行するため、どちらか一方を選んでください。プラグインには Python は含まれていません。スキルとフックは lore コマンドを呼び出すため、マシンに pipx install crewlore をインストールする必要があります。crewlore のリリースごとにプラグインのバージョンも更新されます。/plugin update crewlore@crewlore で取得し、Claude Code を再起動するか /reload-plugins を実行して読み込みます。
得られるもの
生の雑然としたセッションを入力すると、クレームが出力されます。チームが学んだ再利用可能な知見を、4つの要素でまとめたものです。
- 種別 —
decision、procedure、gotcha、styleのいずれかのルールです。 - アクション — 今後のセッションで、それにどう対処すべきかを示します。
- 根拠 — ソースからの逐語引用と、その引用の場所です(トランスクリプトの場合は
<session>#event-<n>、PR レビューコメントから場所が示されている場合はpath:line)。コンパイラーはすべての引用をソースと照合し、一致しない引用を含むクレームを除外します。そのため、書籍には見つけられない引用が含まれることはありません。 - 採用状況 —
current、またはチームが試したうえで採用しなかった場合はnot_adoptedです。
[gotcha]· services/billing請求処理の Webhook ハンドラーには冪等性チェックがないため、Stripe が Webhook を再試行すると二重請求が発生します。
対応 — 処理前に Stripe の冪等性キーを使って重複を排除します。
根拠
ses_1#event-3— "the handler has no idempotency check, so when Stripe retries a webhook the charge is processed again."
採用しなかった作業は、採用しなかったものとして記録されます。 セッションやプルリクエストから、ある手法が試されたものの採用されなかったことがわかる場合、クレームはその旨を示し、アクションには代わりに行うべきことを記載します。
[decision · not adopted]· services/billingStripe の冪等性キーを Redis に保存する案が提案されましたが、チェックはデータベーストランザクション内で実行する必要があるため、レビューで却下されました。
代わりに — キーは請求処理と同じトランザクション内に保持します。
根拠
services/billing/webhook.py:88— "Don't put the key in Redis. Must be inside the transaction."
これが重要な理由は、記憶のスキーマが「X」としか記録できないと、「X を試したが採用しなかった」という事実が、X を断定する記述に変わってしまうためです。流暢で、引用も正確でも、実際には誤った記述になります。この設計の背景にある測定結果は、以下の採用状況フィールドに関する調査をご覧ください。
クレームは領域ごとにまとめられ、コードと一緒にリポジトリへコミットされる、.lore/knowledge/README.md のナレッジブックに集約されます。
# Team knowledge (compiled by crewlore)
## services/billing
- **[gotcha]** Billing webhook handler lacks an idempotency check; dedupe on the Stripe key.
- *Do:* Dedupe on the Stripe idempotency key before processing.
- _anchor_ `ses_1#event-3`: "the handler has no idempotency check, so when Stripe retries a webhook the charge is processed again."
- **[decision · not adopted]** Storing the idempotency key in Redis was proposed and rejected in review.
- *Instead:* Keep the key in the same transaction as the charge.
- _anchor_ `services/billing/webhook.py:88`: "Don't put the key in Redis. Must be inside the transaction."
## deployment
- **[procedure]** Run migrations before deploy to prevent missing columns.
- *Do:* Run `make migrate` before every deploy.
実例
docs/examples/pydantic-ai-prs/ は、デフォルトモデルを使用し、エージェントを一度も実行したことのないマシンで、2026-10-09 に公開リポジトリ pydantic/pydantic-ai(⭐ 20k 以上)を対象に実行した lore import-prs pydantic/pydantic-ai --limit 100 の結果です。直近のクローズ済みプルリクエスト 100 件のうち、24 件はコーディングエージェントが作成したもので、18 件がマージされ、6 件はマージされずにクローズされました。これらから 130 件の主張がまとめられ、そのうち 15 件には 未採用の印が付けられ、173 件のアンカーが添えられています。忠実性ゲートによってモデルの提案が却下されることはなく、コミット済みのスレッドに対してすべてのアンカーを独立して再確認したところ、解決できないものはありませんでした。スクラブ済みのソーススレッドはサンプルに含まれているため、すべてのアンカーから、引用されているイベントをたどれます。
レビュー内で代替案が試され、却下された、マージ済みプルリクエストからの主張です。
[decision · not adopted]· pydantic_ai_slim/pydantic_ai/models統一プロンプトキャッシュ(
ModelSettings.cache/Caching)は引き続きオプトインです。デフォルト有効にする案(supports_cacheを持つモデルではcacheのデフォルトを True にする案)も試されましたが、メンテナーがデフォルト有効のキャッシュを v3 まで保留したため、採用されませんでした。代わりに —
cacheをデフォルトで True にしないでください。ユーザーがcacheを設定するか、Caching()を使用するか、プロバイダー固有のキャッシュ設定を行うまでは、キャッシュを無効のままにしてください。デフォルトでの有効化は v3 のみで再検討してください。anchor
pr_pydantic__pydantic-ai__7560#event-65— 「メンテナーの決定により、cache(またはCaching機能)あるいはプロバイダー固有のキャッシュ設定で指定されない限り、キャッシュは無効のままです。デフォルトで有効にするのは v3 まで待ちます。」
このサンプルでは、競合は記録されていません。検出器が不一致としてフラグを付けるのは、未採用とされた主張が現行の主張と並んでいる場合、または、ある主張が別の主張の指示することを禁止している場合など、証拠がある場合のみです。リポジトリの .github/ ディレクトリに触れることを禁じる主張が 3 件あっても、それらは一致しているため、1 件の競合として報告されることはありません。残る検出上の盲点は、以下の制限に記載されています。
以前のスナップショット docs/examples/pydantic-ai/ は、2026 年 5 月に crewlore 0.1.0 でまとめられた 3 回の Claude Code セッションです。README では、このスナップショットから分かることと分からないことを説明しています。
仕組み
flowchart LR
S["coding-agent<br/>sessions"] --> I["ingest + scrub<br/>(one session format,<br/>secrets redacted)"]
P["agent-authored<br/>pull requests"] --> I
I --> C["compile<br/>(claims with verbatim<br/>anchors + adoption)"]
C --> R["<b>.lore/</b> in your repo<br/>(knowledge book + claims,<br/>plaintext, git-versioned)"]
R --> SV["serve<br/>(files + MCP query)"]
SV --> N["next agent session<br/>inherits the knowledge"]
SV -. "usage + feedback" .-> AL["lifecycle<br/>(decay · reinforce · retire)"]
AL -. "lifecycle update" .-> R
classDef engine fill:#4a5d9e,stroke:#1a2c4d,color:#fff,stroke-width:2px
classDef artifact fill:#2d6a4f,stroke:#1b4332,color:#fff,stroke-width:2px
class C engine
class R artifact
- 取り込みとスクラブ。 2つのソースから、1つのセッション形式に取り込みます。トランスクリプト: このリポジトリの Claude Code セッションファイルです。プルリクエスト:
ghCLI で取得し、各 PR スレッドを1つのセッションとして扱います。説明、コミットとそのメッセージ、ファイル名と行番号が付いたレビューコメント、承認または変更要求の判定、CI の結果、PR がマージされたかクローズされたかを含みます。データを保存またはモデルに送信する前に、どちらも厳選したシークレットパターン(API キー、クラウドおよび GitHub トークン、Slack および Hugging Face トークン、JWT、接続文字列のパスワード、秘密鍵ブロック、password=…の形式)に基づいてスクラブします。パターンセットとその制限については、docs/scrub.mdをご覧ください。 - コンパイル。 モデルが各セッションから候補となる主張を抽出します。その後は決定論的な段階で処理します。すべてのアンカー引用文をソースと照合し、一致しないものを除外します。引用文が見つかった位置から各アンカーの位置を特定します。内容に基づいて重複を排除します。セッション間の意見の相違は上書きせずに記録します。また、主張を支持する独立したセッションの数に基づいて信頼度を評価します。
lore compileは各パスでゲートが除外したアンカー案と主張の数を表示します。ストアの事後的な「忠実度」ではなく、この数値がモデルの動作を示します。 - 提供。
.lore/knowledge/の Markdown ブック、lore queryコマンド、lore installでコーディングアシスタントに導入できる/loreスキル、そして任意のエージェントがセッション開始時に関連する情報を取得できるオプションの MCP サーバーを提供します。 - ライフサイクル。 取得した内容はすべて記録されます。人やエージェントは、主張に影響を与えたことや、主張が覆されたことを記録できます(
lore feedbackまたはlore_feedbackMCP ツール)。30日間(設定可能)誰も読んでいない主張はアーカイブされ、繰り返し覆される主張は廃止され、影響力のある主張は強化されます。これにより、誰も読まない情報の山になるのではなく、ブックを小さく保てます。使用状況はマシンごとに追跡されます。使用状況ファイルはローカルに置かれるため、コミットされたブックのバイト列は変わりません。誤りがある、または古くなった主張は 修正できます(lore feedback <id> --corrected "what is true now")。メモは主張と並ぶ追跡対象ファイルに保存され(ブックと一緒にコミットしてください)、主張を提供するすべての場所に表示されます。主張はブック内にcorrectedとマークされて残り、取得時には未修正の主張の後に表示されます。これは、却下された作業を削除せずに見える状態に保つのと同じです。
知能の核はコンパイルにあります。取り込みと提供は意図的に薄くしているため、別のコーディングエージェントやソースへの対応は、書き換えではなく小さなアダプターの追加で済みます。ここでいう「コンパイル」とは、セッションから主張への再現可能な変換です。各セッションにつき1回のモデル呼び出しを行い、決定論的な検証、重複排除、競合の記録、評価で包みます。
他との違い
- 独自のストアを持つメモリーサービスとの違い — それらのナレッジは、API 経由でアクセスするデータベースにあります。
crewloreのナレッジは、プレーンテキストとしてリポジトリ内にあり、プルリクエストでレビューし、grep で検索し、git logで監査できます。 - エディターごとのメモリーとの違い — 1人のユーザーと1つのツールにひも付きます。
crewloreのブックはチームの成果物なので、新しいチームメンバーもgit pullで取得できます。 - 手書きの
CLAUDE.mdやルールファイルとの違い — 事後に書かれ、数週間で古くなります。crewloreは実際に起きたことから抽出し、証拠として引用文を保持し、読まれなくなった情報を廃止します。 - ドキュメントのチャンクに対する検索との違い — 検索結果として文章を返します。
crewloreはアクションと判定を伴う主張を返すため、読者は決定と却下された代替案を区別できます。(現在の検索は埋め込みではなく、決定論的な単語の重なりに基づいています。よりシンプルで依存関係もありません。意味的ランキングはロードマップに含まれています。)
なぜこれが必要なのか
エージェントのセッション中に発見された知識は、デフォルトでは非公開であり、デフォルトでは失われます。知識はある開発者のトランスクリプトにしか残らないため、次のエンジニアも、今後のエージェント実行も、同じファイルを読み直し、同じ注意点を学び直し、チームがすでに下した判断を再び下すことになります。人間とエージェントの双方が参照できる共有レイヤーがないため、判断にばらつきが生じ、バグが再発します。
crewlore は、その知識を、チームがすでに信頼している場所である git リポジトリに、バージョン管理された第一級の成果物として保存します。
概要: セッションとプルリクエストを、重複を排除し、競合を認識し、出所情報を保持するチームの知識に変換し、あらゆるエージェントに提供するコンパイラーです。
該当しないもの: ホステッドサービス、ベクトルデータベース、単一の IDE 向けの個人用メモリーレイヤーではありません。アカウントも、クラウドも、プロプライエタリーなストアもありません。コンパイルされた知識は、ユーザー自身が所有するプレーンテキストです。
データは自分の手元に残ります
- ローカルファーストです。 キャプチャー、コンパイル、提供はすべて、ユーザーが管理するインフラストラクチャ上で実行されます。コンパイラーの接続先には、独自のモデルプロバイダー、または
provider: localを介したローカルの OpenAI 互換モデル(Ollama、LM Studio、vLLM)を指定できます。crewloreが運営するサービスは存在しないため、そこを経由することはありません。 - デフォルトでは対象を限定します。
lore compileとlore watchが読み取るのは、このリポジトリに属する Claude Code のトランスクリプトだけです。それ以外のディレクトリの読み取りは、明示的に選択する必要があります(--transcripts DIRまたは設定内のcapture.transcripts)。 - プレーンテキストで、リポジトリ内に保存します。 ナレッジレイヤーは
.lore/配下の、人間が読める Markdown と JSONL で構成され、git でバージョン管理されます。git log .lore/が監査証跡になります。 - 保存前にシークレットを除去します。 メッセージ内容とツール呼び出し引数のスクラブ処理は、取り込み時、セッションの書き込み前、モデル呼び出し前に行われます。これは高精度のパターンセットであり、DLP を保証するものではなく、最低限の対策です(
docs/scrub.mdを参照)。ほかの変更と同様に、プルリクエストで.lore/の差分を確認してください。 - 生のキャプチャーデータが git に入ることはありません。
.lore/sessions/、.lore/sources/(生の PR エクスポート)、抽出キャッシュ、使用状況ファイルは gitignore されます。また、ignore ファイルはlore initのときだけでなく、ストアへの書き込みごとに作成されます。 - トークンを保存する必要はありません。 プルリクエストのインポートには、すでに認証済みの
ghCLI を使用します。crewloreが GitHub トークンを参照したり保存したりすることはありません。 - 他者のテキストは信頼できないものとして扱います。 トランスクリプトとプルリクエストのスレッドは、内容から偽造できない区切り文字で囲んでモデルに渡され、指示のようなテキストはコマンドではなくコンテンツとして扱うルールが適用されます。これにより、埋め込まれた主張の可能性は低くなりますが、完全には排除されません。そのため、今後コンパイルされるアンカーには、引用テキストの執筆者が記録されます(プルリクエストではログイン名と執筆者のリポジトリ内での役割、ローカルのトランスクリプトでは人間かエージェントかのみ)。また、新しい主張はすべて
.lore/の差分に表示されます。主張は指示ではなく根拠としてエージェントに提供され、各行の末尾にあるエスケープシーケンスと不可視文字は取り除かれます。脅威モデルについてはSECURITY.mdを参照してください。
CLI
| コマンド | 内容 |
|---|---|
lore init | リポジトリに .lore/ の構成を作成します。 |
lore watch | 一定間隔で取り込み → コンパイル → プルーニングを自動的に実行します(cron/CI では --once を指定します)。 |
lore compile | 取り込みとコンパイルを1回実行します(--rebuild はすべてを再抽出します。--settle 0 は、セッションが落ち着くのを待たず、終了したばかりのセッションを取り込みます)。 |
lore render | モデルを呼び出さずに、コミット済みの主張からブックと競合リストを再構築します。新しいクローンを作成したときや、マージまたはプルの後に使用します。 |
lore hook install / uninstall / status | デーモンを使わずにレイヤーを最新の状態に保つ Git フックです。各コミット後にバックグラウンドで lore compile を、各マージ後に lore render を実行します。Git フックを参照してください。 |
lore import-prs OWNER/REPO | GitHub リポジトリのプルリクエストのスレッドをコンパイルします。デフォルトではクローズ済みの PR をスキャンします(--state open または all)。エージェントが作成した PR のみが対象です(すべての PR を対象にするには --all-authors)。最終更新日時の新しい順に処理します(--limit N)。gh CLI が必要です。 |
lore query "<task>" | タスクに最も関連性の高い主張を、ID とともに取得します(使用状況を記録します)。スクリプトでは --json を指定します。一致するものがない場合に終了コード 4 で終了するには --exit-code を指定します。 |
lore explain <scope> | あるスコープについて判明しているすべての情報を表示します。現在の慣行を最初に、次に却下された作業を、それぞれ根拠と作成者とともに表示し、進行中の競合と、その配下にあるスコープも表示します。--json を指定できます。曖昧な名前の場合は 3、一致するものがない場合は 4 で終了するには --exit-code を指定します。 |
lore review [PR] | 変更が触れるファイル(現在のブランチ、または gh 経由のプルリクエスト)を、それらを対象とする主張と照合します。却下された作業を優先して確認し、その変更がチームの却下したアプローチに似ている場合はフラグを付けます。--comment はレポートを PR に投稿します。--json を指定できます。フラグが付いた場合に終了コード 5 で終了するには --exit-code を指定します。docs/review.mdを参照してください。 |
lore feedback <id>… --influential / --overridden / --corrected NOTE | 提供された主張がその後どうなったかをレイヤーに伝えます。influential と overridden はライフサイクルに反映されます。修正は主張の横にある追跡対象ファイルに書き込まれ(ブックと一緒にコミットしてください)、その主張が提供される場所すべてに表示されます。 |
lore status | 主張と競合の件数、およびレイヤーが実際にどの程度読まれているかを表示します。 |
lore install / lore uninstall | コーディングアシスタントに /lore スキルを追加します(このリポジトリには --project、指示ファイルにブロックを追加するには --always-on、Claude Code フックには --hooks、crewlore が作成していないスキルファイルを置き換えるには --force)。または、書き込んだ内容だけを正確に削除します。 |
lore serve | MCP サーバーを起動し、MCP 対応のエージェント(Claude Desktop、Cursor、…)に lore_query、lore_explain、lore_feedback を公開します。serve エクストラが必要です。このパッケージは lore のエイリアスとして crewlore もインストールします。MCP Registry のエントリーでは、このコマンドが実行されます。docs/mcp.mdを参照してください。 |
Git フック
lore hook install は、リポジトリの post-commit、post-merge、post-rewrite フックに、識別可能で削除可能なブロックを追加します。lore hook uninstall は追加したものだけを削除し、lore hook status は各フックが実行されるかどうか、実行されない場合はその理由を示します。要点は次のとおりです。
- コミットはすぐに完了します。 コンパイルはバックグラウンドで実行され、ログは
.lore/cache/hook.logに記録されます。lore hook statusには最後の行が表示されるため、実行に失敗した場合も確認できます。 - キーは Git クライアントの環境から取得します。 ドックから起動した GUI クライアントには、シェルで設定した環境変数が引き継がれない場合があります。その場合は認証情報エラーが記録されますが、コミットには影響しません。コミット済みの
.lore/config.yamlは自動コンパイルの動作を決めるため、コードと同じように変更を確認してください。 - コンパイルは一度に一つだけ実行されます。 リベースの完了後に一度だけコンパイルされます。その間にコミットが置き換えられたコンパイルは「HEAD moved」で停止し、次のコミットでレイヤーが追いつきます。
post-mergeによるレンダリングで作業ツリーが変更されることがあります。 レンダリングされたブックは、ほかの変更と同じように確認してコミットしてください。主張を完全に削除するには、行自体を削除するのではなく、その行のstatusをarchivedに設定してください。行を削除すると、次のコンパイルでキャッシュから再適用されます。- 既存のフックは慎重に編集されます。 ブロックはシェルが実行できる位置に配置されます。解析または実行できないフックは変更せずに処理を拒否し、
LORE_SKIP_HOOKに何らかの値が設定されている場合は実行をスキップします。
ロックやリベース、既存のフックに対するインストール時の処理、status --probe で確認する内容などの詳細は、docs/git-hooks.md をご覧ください。
設定
.lore/config.yaml:
model:
provider: anthropic # anthropic | openai | local
name: claude-sonnet-5-5 # any current Claude model works; nothing but the prompt is sent
# temperature: 0 # only sent if set; current Claude models reject sampling parameters
# base_url: http://localhost:11434/v1 # for provider: local — Ollama, LM Studio, vLLM
capture:
transcripts: auto # this repo's own Claude Code transcripts, or a directory path
settle_minutes: 10 # a transcript modified more recently is still being written; wait for it (`--settle` overrides per run)
compile:
watch_interval_seconds: 300
max_unused_days: 30 # claims nobody reads for this long are archived
キーはご自身で用意してください(ANTHROPIC_API_KEY/OPENAI_API_KEY)。crewlore がキーを外部に送信することはありません。デフォルトの Anthropic プロバイダーはそのまま使用できます。OpenAI またはローカルの OpenAI 互換モデルを使う場合は、SDK を追加してください:pipx inject crewlore openai(または pip install 'crewlore[openai]')。provider: local の場合、データがマシンの外に送信されることはありません。キーが拒否された場合、モデル名が不明な場合、またはモデルが拒否するパラメーターが指定された場合は、何もコンパイルしていないのに成功と報告するのではなく、明確なエラーを表示して実行を停止します。
adoption フィールドの導入に至った研究
adoption フィールドが存在する前に、チームが採用しなかった作業を読み込んだとき、コンパイラーに何が保存されるかを測定しました。公開されている AIDev コーパスのエージェント作成のプルリクエストを使い、マージされずにクローズされた PR 60 件と、同じリポジトリからのマージされた PR 60 件を対象にしました。それぞれの主張は、PR の実際の結果に基づき、別個のモデルによって判定されました。
| PR ごとに平均した、却下された PR の主張のうち、却下されたアプローチを現在の慣行として記述している割合 | そのような主張を少なくとも 1 つ含む、却下された PR の数 | |
|---|---|---|
| crewlore の抽出器、変更なし | 44.7% | 60 件中 47 件 |
| 同じスレッドを使ったスキーマフリーの要約器 | 47.6% | 60 件中 45 件 |
| マージ済みの対照群 | 0% | 60 件中 0 件 |
| PR がクローズされたことをモデルに伝える | 30.1%、−14.6 ポイント | 60 件中 35 件 |
| adoption フィールドを追加し、それを使うよう指示する | 17.5%、さらに−12.7 ポイント | 60 件中 25 件 |
後日の確認(studies/palm/LABEL_RECHECK.md)では、却下された 60 件のプルリクエストのうち 35 件で、変更が最終的にリポジトリに反映されていたことがわかりました。そのうち 28 件は全体が、7 件は一部が反映されており、20 件はエージェントのプルリクエストがクローズされた時点、またはその 2 日以内に反映されていました。そのうち 12 件はメンテナー自身のプルリクエストによるものでした。表の全 60 件を対象とする件数には、これらも含まれています。約 6 か月以内に変更が反映されなかった 25 件のうち、19 件は依然としてそのような主張を少なくとも 1 つストアに加えており、主張の平均 43.0% を占めていました。確認時にコードの内容として正しいと判定された主張を安全なものとして数えると、最初の行は 60 件中 33 件、26.6% になります。表の各差は、どの集計方法でも方向と有意性が保たれ、要約器の結果も抽出器と変わりません。
スキーマを変えたのは次の点です。フィールドがないすべてのバージョンを通じて、却下された PR から抽出された 658 件の文のうち、却下について独自のテキスト内で言及したものは 0 件でした(マージ済みの対照群を含めると 1,060 件中 0 件)。フィールドがある場合、却下された PR の主張 196 件のうち 77 件がその旨を明記し、モデルが not_adopted と判定した 91 件のうち 77 件がそうしていました。結果をモデルに伝えるだけでは不十分でした。モデルが却下を記録し始めたのは、判定を記録するよう求め、そのためのフィールドを用意したときだけでした。
コード、固定されたデータリビジョン、再現手順は studies/palm/ にあります。この研究では、OpenAI 互換プロバイダー経由で Gemini モデルを使い、crewlore の抽出器と忠実度ゲートを実行し、合意度を測るために別の判定モデルを使用しました(κ = 0.92)。このリポジトリが研究の一次記録です。短い解説をプレプリントとして公開中で、ここにリンクする予定です。研究で crewlore が役立つ場合は、CITATION.cff に引用情報があります。
ステータス、制限、ロードマップ
メモ
アルファ版です。 ディスク上の形式は 1.0 より前に変更される可能性があります。形式の変更はCHANGELOGに記載されています。Python 3.10~3.14 でテスト済みで、テストスイートではネットワーク呼び出しを行いません。
- 現在利用できる機能: Claude Code のトランスクリプトおよび GitHub のプルリクエストスレッドからの取得、シークレットの除去、コンパイルパイプライン(逐語アンカーゲート、派生アンカー位置、採用フィールド、競合の記録、権威スコアリング)、ブック、
lore queryとlore explain、lore review、/loreスキルと Claude Code フック(lore install)、各コミット後にコンパイルする Git フック(lore hook install)、MCP サーバー、フィードバックと修正、未使用の主張の減衰。 - 知っておくべき制限: 検索は単語の重なりに基づいており、埋め込み表現は使いません。トランスクリプトのソースは Claude Code のみです(Cursor、Codex、Copilot のセッションは PR 経由で取り込まれます)。プルリクエストに含まれないコミットは読み込まれません。提供前に承認するゲートはないため、PR では
.lore/の差分を確認してください。競合検出機能は、ある主張に「未採用」のマークが付いている場合、または別の主張が推奨する内容を禁じている場合にのみ意見の相違を検出するため、2 つのセッションが異なる回答を選んだだけでは検出されません。使用状況と減衰はチームで共有されず、マシンごとに管理されます。 - 予定: 人による提供前承認ゲート、ほかのコーディングエージェント向けトランスクリプトアダプター、埋め込み表現に基づく検索、コミットを待たずにセッション終了時に取得する機能、チームメンバー間で共有する使用状況シグナル。
コントリビューション
Issue、ディスカッション、PR を歓迎します。初めての方は、まずディスカッションを始めてください。ほかのコーディングエージェント向けの取得アダプターの追加は、最も価値のある最初のコントリビューションであり、意図的に小規模にしています(Claude Code と GitHub PR のアダプターが、実装例として用意されています)。ローカル環境のセットアップと開発ループについては、CONTRIBUTING.mdを参照してください。
ライセンス
MIT — LICENSEを参照してください。
crewlore は Srijan Saket が開発、保守しています。公式ソースはgithub.com/srijansk/crewloreです。0.2.0 以降のすべての PyPI リリースは、このリポジトリのリリースワークフローから公開されており、このリポジトリを明記したプロベナンス証明が付属しています。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。