imozuru

知らない分野を、言葉を知らないところから原文にたどりつくまで掘る。 芯は2つ。原文を要約せずに落とすことと、止めどきを確信度ではなく証拠で決めること。

なぜこの形か（先に読む）

• 要約しない理由: 調べ始めの混乱した段階で詳しくまとめると、早すぎる閉じ（premature closure）を招いて過程を妨げる（Kuhlthau 1991）。エージェントが早い周で要約すると、エージェントの見方で閉じ、ユーザーが判断に使う細部が落ちる。このスキルは「自分の感覚と AI の調査結果がかみあわない」という経験から生まれた。判断するのは原文を読むユーザーで、エージェントは原文の場所を指すだけ
• 決め打ちしない理由: AI の検索は、方向がいくつもありうる段階で1つを選び、その後の検索が同じ道を強めて失敗する（Zhou ら 2026 HypoSearch）。迷ったら枝を分けて並べ、比べてから進む
• 言葉が無いときの道: 引用をたどる方法は、主題を言葉で言い表す問題を丸ごと避けられる（Bates 1989）。検索語が出てこないときは引用と著者でたどる
• 理論と原文の場所は references/theory.md

置き場

既定は ~/.local/share/imozuru/<話題>/（話題は英小文字とハイフン。例 search-methods）。git リポジトリの中で頼まれ、調べものがそのリポジトリの作業（実装・設計・不具合の調査）のためなら <リポジトリのルート>/.tmp/docs/research/<話題>/ に置く。.tmp/ が gitignore されていないリポジトリでは、原文がコミットされうるので置く前にユーザーに聞く。ユーザーが別の場所を言えばそこに置く。以下ではこの置き場を <topic_dir> と書く。

map.md      … 問い・要る主張・用語・人・場・原文の表・次の手がかり（書式は下）
log.md      … 来た道。周ごとに、誰が何を探して何が出たか・判断とその理由。起動した検索役は、戻らなかったものも含めて1本ずつ書く（何を頼んだか・戻ったか・止めたか）
sources/    … 原文。PDF とその .txt、HTML は .md。要約ファイルは置かない
extracts.json … 抜き書き（止めたあとに書く・下の「抜き書きのページ」）
report.html … 抜き書きのページ（report.py が作る）
watch.tsv   … 見張る先（見張りのモードを使ったときだけ）
watch/      … 見張りの結果。<日付>.md

検索役のサブエージェント

0周目と各周の探索は、検索役のサブエージェントに任せる（以下「検索役」）。広く掃く探索は途中で判断が要らないので、軽いモデル（Haiku など）で足りる。読み取りと Web 検索だけ使える定義があればそれを使う。サブエージェントを使えない環境では、エージェントが自分で同じ頼み方の中身を順に検索する。

流れ

0. 問いと「要る主張」を書く

map.md を下の書式で作り、問いと、答えるのに要る主張を3〜6個並べる（例: 「この分野で〇〇をどう呼ぶか」「定番の手法は何か」「どこで失敗するか」）。主張は止めどきの物差しになる（HALT・Roh & Han 2026）。

主張は自分で甘く作れてしまう。試しでは5つ全部が「〜がある」で、1周で埋まって止まり、依頼の芯（「AI で生成した画像を」）が確かめられないまま残った。だから次を守る。

• 少なくとも1つは、依頼の言葉の条件をそのまま入れる（例: 依頼が「AI で生成した画像を編集できるデータに」なら「AI 生成画像に当てた結果や事例がある」）
• 「〜がある」だけで埋めない。半分以上は「どれくらい効くか」「どこで失敗するか」「何が足りないか」のように、原文を読まないと答えられない形にする
• 要る主張の1つ目は、いつも「この分野の知見はどこに集まっているか（場）」にする。どこを当たるかを、固定の一覧ではなく調べて決めるため（下の「1. 地図づくり」）
• コツや定番のやり方を聞く問いでも、1つは「そのコツの元になった原典・研究はあるか」にする。無ければ「探した範囲では無かった」と書く。チュートリアルだけで答えると、元にある研究に届かないまま「規則は無い」と結論しやすい（2026-10-12 の比較で、素の頼み方は3回とも「規則は無い／理論ではない」と結論した。原典を問いに入れずに掘った imozuru も Rood 1879 に届かなかった）

問いは途中で変わってよい（berrypicking）。変わったら map.md の問いと主張を書き直し、log.md に理由を書く。

1. 地図づくり（0周目）

検索役を違う探し方で2本並べる。既定は英語と日本語。片方で足りる分野なら「用語で検索」と「定番の総説と教科書を探す」に分ける。違う探し方の2本で同じものが出るほど、地図が埋まってきた印になる（capture-recapture の考え方・Kastner 2007）。

検索役への頼み方:

• 返してほしいのは4つ＝用語（それが出た URL）・人（所属・代表作）・場（学会・雑誌・一覧・リポジトリ）・定番の資料（題名・著者・年・無料で読める URL）
• 報告は「見つけた／探したが無い／探していない」の3つに分けてもらう。「探していない」がそのまま次の手がかりになる
• 要約は頼まない。名前と URL を正確に拾うことを優先させる
• ファイルを書かせない。ダウンロードは親の仕事。試しで検索役が curl で一時ファイルを書いた
• 場は一覧から選ばず、0周目で探させる。「この分野の詳しい人はどこに書いているか」「定番の資料はどこで公開されているか」を検索役への問いとして渡し、挙がった場を map.md の「場」に足す。どの場から何件挙がったかを log.md に残す（分野ごとの場の偏りを記録に溜める）。論文と個人の発信のどちらに知恵があるかは分野しだいで、0周目では決めつけない。次の一覧は、場の見当がまったくつかないときの例にとどめる＝学会・雑誌・arXiv、個人ブログ、Qiita・Zenn・note、YouTube、GitHub、X、pixiv・FANBOX の講座、フォーラム。固定の一覧だけで当たると、日本語の技術記事に寄る（固定の一覧で当たると、作り手の癖に寄る）
• 入口の言葉が分からない分野では、粒度の粗い順に当たらせる＝百科事典（英語版 Wikipedia の References）→ 専門事典 → 教科書・講義資料 → サーベイ論文 → 原著（横井 2017）。論文の無い分野なら、用語集・入門記事 → その分野で名前の挙がる人 → その人自身の実践の記録、の順
• 日本語で入口の言葉が無い分野は英語で入る（「berrypicking ベイツ」は果物狩りの記事ばかりだった）
• 検索の深さを切り替えられるなら、まず普通の検索で探させ、欲しい種類が0件のときだけ深い検索で引き直させる。「薄い」は全体の件数ではなく種類で見る（記事は出るが動画が0件、日本語が0件など）。大陸塗りの試しでは普通の検索の8本がほぼ空振りで、深い検索の1本目で note・YouTube・ブログが一斉に出た。MIX の試しでは記事は出たが、普通の検索だと YouTube が0件だった。深い検索は費用が数倍なので、最初からは使わない

戻ったら、報告の中身を map.md の用語・人・場に足し、検索役の「探していない」を次の手がかりに移す。

検索役の報告はたいてい検索結果の抜粋がもとで、原文を開いていない（試しでは2本とも開いた回数0）。人の所属・「公開済み」・数字は外れていることがある。map.md に入れるときは末尾に （未確認） を付け、原文で確かめたら外す。

2. たどる（各周）

次の手がかりから、匂いの強いもの（何度も名前が出る・総説や教科書・定番として引かれる・何人もが「この人の記事を見て」と挙げる）を選んでたどる。たどり方は6つ（Bates 1989・Ellis 1987）。論文の世界でも個人の発信の世界でも同じ動きで、たどる先が違うだけ:

動き	論文なら	個人の発信なら	道具
後ろへ	参考文献	記事の中のリンク、「〇〇さんの記事を参考に」	chain.py refs、手元の本文を grep
前へ	被引用（多い順）	その記事を紹介・引用している記事や投稿、はてブ	chain.py cites、検索役
著者で追う	著者の他の論文	その人のブログの過去記事、Zenn・Qiita・note の投稿一覧、YouTube のチャンネル	chain.py author、検索役
場を通しで見る	中心の学会・雑誌	Qiita・Zenn のタグ、pixiv の講座タグ、Discord・Reddit、awesome リスト	検索役
近くを眺める	同じ号・同じ一覧	関連記事、同じタグ、同じ人がまとめた再生リスト	検索役
言葉で引き直す	地図に増えた用語で検索	同じ。界隈の俗称・略語でも引く	検索役

論文の無い分野ほど、知恵は個人の発信にある（塗り方・MIX・ツールの使いこなしなど）。権威のある場所だけに絞らない。

• 論文は DOI で引く。題名で引くと別の記録や解説記事を掴むことがあるので、chain.py find の候補を年と題で確かめてから使う
• 出て1年ほどの論文は chain.py が0件を返す。OpenAlex に引用の登録が追いついていない（試しでは出て1年以内の論文で refs も cites も0件）。0件は「無い」ではない。後ろへは、落とした本文の参考文献の節を grep する（試しではこれで目当ての論文が見つかった）。前へは、検索役に「<題名> を引いている論文」を探させる
• 方向が2つ以上ありえるときは決め打ちしない。検索役を2本、別の仮説で並べ、戻ってから比べる
• 当たりは fetch.py で落とす。OK が出たものだけ map.md の原文の表に足す。FAIL は理由と URL を log.md に残す（有料・404・ログインの壁）
• FAIL や有料で取れなかった定番は、届かなかったと書く前に別の置き場を探す。著者や研究室のページ、その分野のまとめサイト、元になった技術報告、大学のリポジトリを当たる。2026-10-14 には、DTIC で 403 だった Mann & Thompson と Hovy の原典が、SFU の RST サイトに置いてあった。海賊版サイトは使わない
• 落としたら、要る主張に関わるところを .txt / .md で grep して行番号を確かめる。map.md の主張の行に「どのファイルの何行目か」を書く。ここで書くのは原文の場所と短い引用で、まとめや結論は書かない
• 行番号には短い引用（英語なら数語）を添える。2段組の PDF は pdftotext で左右の段が1行に混ざり、行番号だけでは読み手が見つけられない。引用があれば grep で引ける

3. 周の終わりの判断（親）

起動した検索役が全部戻ってから判断する。待たずに先へ進めた検索役は、その場で止める。

0周目は、検索役を並べて地図を作るまで（原文はまだ落とさなくてよい）。1周＝手がかりから原文を落とし、そこから少なくとも1回たどる（後ろへ・前へ・著者で追うのどれか）まで。検索役を並べ直すかどうかは問わない。論文の無い分野では、落とした記事の中のリンクを後ろへたどれば1回と数える。検索役が空振りして親が自分で探した周も1周に数える（その周は飽和を数えない）。空振り＝検索役の挙げた中に、落として当たりだったページが1つも無いこと（検索結果の件数ではない。検索役はページを開かずに報告するので、当たりかは親が落として初めて分かる）。

各周の終わりに、次のどれかなら止める。理由を log.md に書く。

• 要る主張の全部に原文の場所が付いた（主張ごとに file:行＋短い引用）
• 飽和した: この周に検索役が挙げた人と資料のうち、7割以上がすでに map.md にあった。新しい用語もほとんど出ない。分母と分子を log.md に書く（例「挙がった14件中11件が既知」）。7割は試しで決めた目安で、まだ根拠は弱い
  • 数えるのは、同じ問いを違う探し方で探した検索役だけ（英語と日本語、用語検索と総説探し）。別の仮説を追わせた2本は、話題が違うので重なりが低く出るのが当たり前で、飽和の物差しにならない（試しで別の枝は 2/14）。仮説の枝ごとに、その枝の主張が埋まったかで見る
  • 「既知」には親が自分で拾ったものも入れる。検索役に既知の一覧を渡すときも同じ一覧を渡す（親の拾った分を入れ忘れ、分子が小さく出たことがある）
• 4周やった: 届いていない主張と、その理由（有料・見つからない）を書いて止める
• 壁で止まった: 残りの主張の原文が、どれもログインの壁（X・pixiv・小紅書・会員制のサイト）か有料の向こうにある。壁の手前で取れるものはもう無い。URL を並べて止め、ユーザーにブラウザで開いてもらう（下の「渡す」）
  • 「一部だけ」の主張も、足りない部分の原文がどれも壁の向こうなら、壁で止まったと数える。足りない部分を壁の手前でまだ探せるなら止めない
  • 無料公開なのに出版社のボット対策（Cloudflare の確認画面・403）で取れないだけなら、止める前に、ユーザーにブラウザで開いてもらうよう頼む。人のブラウザなら確認画面は自然に通る。ユーザーのブラウザを操作できる道具（DevTools をつなぐ MCP など）があるなら、ユーザーに確かめてから使ってよい。確認画面をすり抜ける細工はしない。「コピーを請求する」形や有料のものは壁のまま
• 約束で打ち切った: 依頼に時間・回数の上限があり、上の4つに届く前にそこへ着いた。どの物差しがどこまで進んだか（主張の何個に原文が付いたか・飽和の分子と分母）を書いて止める。物差しを満たしたふりはしない

1周目が終わるまで止めない。0周目で主張が全部埋まって見えても、当たりの論文から前へたどるか著者で追うのを1回はやってから判断する。早くやめて外す under-search は、AI の検索のもう1つの典型（Zhang ら 2026）。止めないときは、次の周にたどる手がかりを2〜4個選んで log.md に書いてから進む。

4. 渡す

返す前に、自分が起動した検索役や裏で走らせた処理が残っていないか確かめ、残っていれば止める。止めたものは log.md に書く。2026-10-12 の試しでは、調べものを任せたエージェントが報告を返したあとも、中で起動したものが動き続けていた（何だったかは log.md に無く、分からなかった）。

止めたら、ユーザーに次を返す。

1. 止めた理由（上の5つのどれか）
2. 主張ごとの原文の場所（sources/<file> の何行目）。1主張1〜2行
3. 届かなかったもの（有料で取れない定番など）
4. 抜き書きのページ（report.html・下の節）のパスを最初に示し、ほかに一番読んでほしい原文を2〜4本選んで、パスと「どこを読むか」を1行ずつ添える
5. 壁の向こうで大事そうなものは、URL と「なぜ大事そうか」を1行で並べる。ユーザーがログイン済みのブラウザで開いて読む。エージェントはアカウントを作らない・ログインしない
6. 流れのほうで気づいた穴（道具の不具合・検索役のはみ出し）
7. ユーザーに「感覚と合った？」と一言だけ聞き、答えを <topic_dir>/log.md の末尾に原文のまま残す（言い換えない）。止めどきの7割や周の上限を変えるかは、この記録を何回分か並べて決める（記憶では決めない）

返事に要約や解説を書かない。ユーザーに「まとめて」と頼まれたら、そこで初めて書く。

抜き書きのページ（読むための形）

原文を何十本も落としただけでは読まれない（英語の PDF や1時間の字幕のまま）。かといって要約すると早すぎる閉じに戻る。だから止めたら、抜き書き（Ellis の extracting）でページを作り、それを最初に渡す。

1. <topic_dir>/extracts.json を書く。要る主張ごとに節を立て、原文からそのまま切り出した文を並べる（ファイル・行・必要なら end）。英語には ja に訳を添える（訳だと分かる印がページに付く）。印（〔本人〕自動字幕 など）は mark に。2段組の PDF のように左右の段が1行に混ざる所は、抜き書きを「…」で区切ると区切りごとに順に照合される（省いたことはページにも「…」で見える）。食い違いは disagreements に並べるだけで、どれが正しいかは書かない。届かなかったものは unreached に。形の手本はリポジトリの examples/demo/extracts.json 形（report.py の冒頭と同じ。? は省いてよい）:

   {"title", "question", "stopped",
    "claims": [{"claim", "status": "付いた|一部だけ|付かなかった", "note"?,
                "quotes": [{"file", "line", "end"?, "text", "ja"?, "mark"?}]}],
    "disagreements"?: [{"topic", "quotes": [{"file", "line", "text", "who", ...}]}],
    "unreached"?: ["..."]}
   

2. scripts/report.py <topic_dir> を回す。抜き書きが原文の指定の行にそのまま在るかを機械で照合し、1つでも合わなければ HTML を作らずに止まる（言い換えが紛れ込むのを防ぐ）。合えば report.html ができる。各抜き書きは「前後を読む」で原文の前後を開ける
3. エージェントが書いてよいのは、見出し・状態（付いた／一部だけ／付かなかった）・1行の注記・訳だけ。注記にも結論や評価は書かない（「順番は記事ごとに違う」はよい、「この順が正しい」は書かない）。注記は、誰が何をどうしたかが分かる平らな文で書く
4. 自動字幕の誤変換は直さずにそのまま切り出す（直すと言い換えになる）。印に「自動字幕」と書けば、読む人が動画で確かめられる

見張る（watch モード）

掘ったあとの地図の「場」を、新着を追う先にする（Ellis の monitoring）。「〇〇の新着見て」「今週の〇〇まとめて」「/imozuru watch <話題>」で入る。ユーザーが頼んだときだけ回す。定期に自動で回すかは、何回か思いどおりに動いてから決める。

1. 地図があるか見る。<topic_dir>/map.md が無いとき（いきなり「React の新着」と頼まれたとき）は、2つの入り方がある
   • 急ぐとき（既定）: 定番の場所をそのまま足して先に見張る。公式のブログ・GitHub の releases、Qiita のタグ、Zenn のトピック、名前の知れた個人ブログ。地図は最小（問い・場・人だけ）で作り、あとで育てる。React の試しでは 0周目の検索役2本に約2分かかり、結果は定番を直接足したのとほぼ同じだった
   • 場所の見当がつかない分野: 上の「1. 地図づくり（0周目）」だけ回して場を作ってから見張る
2. 見張る先を足す。map.md の「場」と「人」から、新着を出す場所を選んで scripts/watch.py add <topic_dir> <url> で足す。Qiita のタグ・ユーザー、Zenn のトピック・ユーザー、note のユーザー、Reddit、YouTube のチャンネル、RSS を出しているブログ、arXiv の検索（http://export.arxiv.org/api/query?search_query=...&sortBy=submittedDate&sortOrder=descending）が足せる。X と pixiv は RSS を出していないので足せない＝見張れないことを返事に書く
   • RSS があるかは検索役の言葉ではなく watch.py add で決める。検索役は RSS の URL を推測で書き、「無い」と言った react.dev のフィードが実際は取れた。逆に「更新が止まっている」という検索役の言葉は、check の「最新の1件」で確かめる
3. 新着を引く。scripts/watch.py check <topic_dir> で前回から新しいものを出す（初回のフィードは直近14日・--days で変える）。結果は watch/<日付-時刻>.md に残る（同じ日に何度回しても前の結果は消えない）
   • 新着の無い場所にも、窓に関係なく最新の1件が出る。公式の大きな出来事が窓の外に落ちても見える
   • 窓を広げて出し直すときは --fresh。初回の窓の外の記事も「見た」と記録されるので、記録を無視して窓だけで選び直す
4. 渡す。新着の一覧を見せる。1件ごとに題名・日付・場所と、フィードに入っている原文の冒頭を1行（> の引用）。エージェントの要約や点数は付けない（原文の冒頭なら書き手の言葉のまま選ぶ手がかりになる）。ユーザーが選んだもの、または要る主張に関わると見たものだけ fetch.py で原文を落とし、原文の表に印つきで足す
   • 件数が多いとき（目安20件超）は、依頼に合わせて種類で絞って見せてよい（「個人ブログと海外も」なら Qiita・Zenn の数を減らす）。絞ったことと、全件のファイルの場所を書く。絞るのは選び方だけで、要約はしない
   • 新着の無かった場所の「最新の1件」は、一覧の最後に短く添える
5. 新着の中に、地図に無い人・場・用語が繰り返し出ていたら、map.md の「次の手がかり」に足し、見張る先に加えるかをユーザーに聞く。見張りから掘りへ戻る入口になる

map.md の書式

# map: <話題>

問い: <1〜2行>
入口の言葉: <最初に使った言葉>

## 要る主張

- [ ] <主張1> — <原文の場所。付いたら [x]>

## 用語

- <用語>（<日本語の呼び方>）— <出た URL か sources/ のファイル>

## 人

- <名前>（<所属>）— <代表作>

## 場

- <学会・雑誌・一覧・リポジトリ> — <URL>

## 原文（sources/）

| 論文・資料 | ファイル | 元の URL | どこから来たか（周・動き） |
| ---------- | -------- | -------- | -------------------------- |

## 次の手がかり

- <まだたどっていないもの> — <なぜ匂うか>

節の順番は変えない。追記は各節の末尾に足す（周をまたいで表が散らばるのを防ぐ）。原文の表は1論文1行で、PDF と .txt、抄録の .md のように複数のファイルがあれば同じ行に並べる。検索役由来で原文を開いていない行には（未確認）を付ける。

原文の表の「論文・資料」の欄には、頭に種類の印を1つ付ける。点数はつけない。どれを信じるかはユーザーが原文を読んで決める。

• 〔論文〕査読や会議を通ったもの、arXiv のプレプリント
• 〔本人〕やった本人の記録（自分で試した・作った・測った過程が書いてある記事・動画・README）
• 〔観察〕他人の作品ややり方を見て、特徴を書き出したもの（「この絵師たちはこう塗っている」）
• 〔まとめ〕他人の知見を集めた・言い換えた記事（「調べてみた」系、まとめサイト、解説の解説、百科事典・用語辞典）
• 〔公式〕道具や製品を作った側の文書・発表

〔本人〕は個人の発信でも一次情報になる。〔観察〕は、観察した相手が名前で分かるならその人を「次の手がかり」に足す（その人自身の記録が本当の一次情報）。〔まとめ〕は入口としては便利でも、たどる先（後ろへ）を拾うのに使い、主張の根拠にはなるべく〔本人〕か〔論文〕を当てる。

印のあとに、分かる範囲で添える。

• 作例あり: 書き手自身の作品が載っている。「上手い人のやり方」が知りたいときは、作例のあるものを先に読んでもらう。上手いかどうかはユーザーが作例を見て決める
• 測定あり: 書き手が自分で測った数字や比べた結果が載っている（ベンチマーク、実写の色の実測、設定値の比較）
• AI 補助: 本人が「AI に書いてもらった」と書いている
• 宣伝あり: 書き手が売っている物やサービスへ誘う記事・出品ページ。中身は〔本人〕のこともあるが、読む側が割り引けるように添える
• （未読）: 落としたが、エージェントもサブエージェントもまだ中身を読んでいない
• 自動字幕: YouTube の自動字幕から起こした。誤変換が多い（「線画」→「洗画」）ので、引用は読み取れる範囲に絞り、主張の根拠にするときは動画で確かめてもらう

道具

スクリプトは Python 3.10 以上の標準ライブラリだけで動く。外部コマンドは、あれば使う（無いときの動きは各行に書いた）。

• scripts/fetch.py <sources_dir> <name> <url> — 落として本物か確かめる。PDF は .pdf と .txt（pdftotext -layout・poppler）、HTML は .md、YouTube は字幕を [分:秒] 文 の .md（yt-dlp・動画は落とさない）。文字の層が無い PDF は tesseract で OCR する。HTML は ax があれば ax で、無ければ標準ライブラリで本文を文字にする（見出しや表の形は ax のほうが残る）。取ってきたものは作業用のフォルダで検査し、通ったものだけを sources_dir へ移す。404・壁・短すぎる本文は FAIL（同じ名前の原文がすでにあれば、そのまま残る）。X は本文が取れないので取りに行かず FAIL＝URL と、検索役が拾った抜粋を（未確認）で map.md に残す
• 動画の場所は行番号の代わりに時刻で指す（sources/x.md [12:34]）
• scripts/report.py <topic_dir> [--check] — extracts.json の抜き書きを原文と照合し、合えば report.html にする。--check は照合だけ
• scripts/watch.py add|list|check — 見張り。RSS / Atom を引いて前回からの新着を出す。検索を使わないので費用はかからず結果も揺れない。DOCTYPE・ENTITY を含むフィードは安全のため読まない
• scripts/chain.py find|refs|cites|author — OpenAlex で引用と著者をたどる。1日 1,000 回まで無料の枠で、プリペイド残高が 0 なら超えても止まるだけ。API キーや支払いの登録はしない。古めの論文に強く、新しい論文と同名の多い著者に弱い（author は同名の別人を掴むことがある）
• ファイル名は <著者>-<年>-<短い題>、arXiv は arxiv-<番号>-<短い題>

境界

• 検索役の同時起動は2本まで（違う探し方の2本で飽和を数える設計のため。増やすと費用が増え、重なりも読みにくくなる）
• 機密や個人データが絡む調べものは外部に出さない。検索役は Web を検索するので、問いの中身が検索語として外に出る
• 有料の論文を回避する手段（海賊版サイト等）は使わない。届かなかったものとして報告する
• 落とした原文は手元で読むための写し。再配布はしない

Derived from MaryCache/imozuru (skills/imozuru) at commit bfd99e5e72d8e8ec3297a71fafa1eafbb49787b2 (MIT). See LICENSE in this directory.