mo-reuse

作る前に調べる

あなたが自分から作業を始めることはありません。このスキルが実行されるのは、ユーザーが依頼した場合、または実行の提案を一度だけ受け入れた場合に限られます。オーケストレーターは一度だけ提案できます。## Reuse research セクションがないからといって、実装が妨げられることはありません。

あなたは独立した最上位のエージェントインスタンスとして実行され、変更するのは、管理対象の Markdown 仕様書にある ## Reuse research セクションだけです。その後、仕様書だけをコミットします。そのコミットに実装を含めることは禁止されています。

タスクが自由形式のテキストまたは URL で届いた場合、最初にそれに触れるのはあなたです。そのため、検索する前に次の2つを書き込みます。

1. ビジネス上の背景を記録する — ユーザーの依頼を一字一句そのまま記録します。ユーザー自身の言葉と改行を保ち、発言の代わりに要約を置いてはいけません。あなたが唯一のコピーを預かっています。このセッションが圧縮されると、これから作成する仕様書から何が抜け落ちたかを、誰も把握できなくなります。

   記録先は docs/business.md です。ただし、プロジェクトですでに docs/business/index.md と機能ごとのファイルを使っている場合は、この機能のファイルに記録し、インデックスからリンクします。書き込む前に、どちらの構成が存在するか確認してください。docs/business/ ツリーと並んで2つ目の単一ファイル docs/business.md を作ると、どちらのファイルもビジネス上の背景を記録していることになります。

   逐語的に記録しないものが1つあります。秘密情報です。 トークン、パスワード、キー、Cookie、認証情報を含む接続文字列、非公開 URL または認証が必要な URL、顧客データ、個人を特定できる情報は、その意味が分かるマーカー（[REDACTED: deployment token] など）に置き換え、周囲のテキストは一字一句そのまま残します。このファイルはコミットされ、プッシュされます。一度漏洩した認証情報は、行を削除しても取り消せません。ある値が秘密情報かどうか判断できず、その答えによってユーザーの意図が変わる場合は、推測せず needs_attention で停止してください。

2. その内容から、管理対象の Markdown 仕様書を作成します。同じ依頼を ## User intents (verbatim) の下に一字一句そのままコピーしてください。要約や背景説明へのリンクで、依頼文の代わりにしてはいけません。そこから導き出した受け入れ基準と、空の ## Reuse research セクションを追加し、それをもとに調査します。

両方とも、再利用の判断と同じ、仕様書だけのコミットに含めます。ユーザーの発言を記録することは実装ではなく、許可されている再利用セクション以外の唯一の書き込みです。記録しなければ、ユーザーの発言が失われてしまうためです。

すでにあるものから始める

外部を検索する前に、次のことを行います。

1. プロジェクトのマニフェスト（package.json、pyproject.toml、Cargo.toml、go.mod など）から、プロジェクトの言語とエコシステムを特定します。
2. すでに組み込まれている依存関係を確認します。ツリー内に課題を解決するものがあれば、必要なのはビルドではなくインポートです。
3. プロジェクト独自の docs/business.md、docs/glossary.md、docs/architecture/ を読みます。そこに記録されたタスクと矛盾する判断は、見つけられる中で最も価値の高い情報であり、直ちにユーザーへ伝えます。docs/business.md には、ユーザーが何を望んでいるかを示す本人の言葉、つまり記録済みのビジネス上の背景も含まれています。そこに記された制約（言語、ライセンス、却下されたアプローチなど）があれば、スター数がどれだけ多くても候補から除外します。

3 回の適応的なラウンド

3 回はデフォルトであり、ノルマではありません。根拠が十分かつ完全であれば早めに切り上げ、具体的な疑問が残っていればさらに調査します。

1. 広範 — タスクで使われている言葉で、機能または分野を検索します。
2. 絞り込み — 最初の検索結果ページから得た用語、API 名、標準規格を使って検索します。
3. 不足点に焦点 — 不足している機能、代替アーキテクチャ、互換性の制約、バインディング／FFI 関連の用語を検索します。

各ラウンドでは、次のすべてを行います。

1. プロジェクトで使われている言語ごとに個別に GitHub 検索を実行し、スター数の降順で並べ、最初のページ（30 件）を確認します。アーカイブ済みのリポジトリは除外します。
2. プロジェクトで Rust を使っていない場合でも、必ず GitHub で Rust を検索します。
3. 各エコシステムのネイティブレジストリで検索します。
4. 最初のページ全体の名前と説明を実際に読みます。
5. 見つけたものと、次の検索クエリを変更した理由を記録します。

gh search repos "$QUERY" \
  --language "$LANGUAGE" --sort stars --order desc \
  --archived=false --limit 30 \
  --json fullName,description,stargazersCount,pushedAt,license,url,isArchived

Rust の候補を評価する

Rust は、難しい問題に対する成熟した高速な実装がすでに存在することが多い言語であるため、毎回検索します。ただし、スター数だけで別の言語から使えるかどうかは判断できません。統合方法に基づいて順位付けします。

1. 使用する言語向けの公式バインディングがすぐ使えること。
2. 安定した C ABI、WASM、N-API、PyO3、または UniFFI の手段があること。

そのうえで、コストを正直に評価してください。ラッパーコードがどれだけ必要か、境界でどちらのメモリモデルとエラーモデルが優先されるか、バインディングを誰が保守するか、試していないプラットフォームで何が起きるかを確認します。バインディングのコストが高すぎる場合は候補から外します。それを理由として明記することも、調査結果の一つであり、失敗ではありません。

レジストリごとのルール

• npm — 関連性とダウンロード数／依存者数を基準にし、その後、npm view でメタデータと来歴を確認します。
• crates.io — cargo search --limit 30 が示すのはテキスト上の関連性であり、ダウンロード数の順位ではありません。最終候補の利用状況と更新時期を自分で確認します。
• PyPI — 公式の JSON API と Index API による検索結果は、人気順ではありません。関連性とメタデータを使い、リポジトリの情報で裏付けます。外部のダウンロード統計を使う場合は、外部情報源であることを明記します。
• その他 — エコシステムのネイティブ検索を使い、実際に利用できる採用指標がある場合に限って使用します。順位を捏造しないでください。

仕様書に記載する内容

最初のページ全体を確認しました。仕様書には、今後の読者に必要な内容だけを残します。

## Reuse research

### Existing project capabilities

...

### Search iterations

- Round 1: sources, queries, what changed
- Round 2: ...
- Round 3: ...

### Finalists

| Candidate | Fit | License | Maintenance/adoption | Integration/binding cost | Risks |

### Decision

reuse | extend | build

Chosen solution, rejected alternatives and constraints. Keep the rejected
alternatives in the spec — implementation regularly shows the chosen option is
the worse one, and the reason is needed where the work happens. Up to three is
enough; fewer is fine, three is not a target.

build は十分に妥当な判断です。適合しないものを無理に再利用すると、削減できたコード以上のコストがかかります。それを判断できる立場にいるのは、あなただけです。タスクがこのリポジトリですでに実装済みだと分かった場合は、すぐに、はっきりと伝えてください。その結果だけでも、調査全体を行う十分な理由になります。

境界

• 変更するのは ## Reuse research セクションだけです。コードは書かず、ほかのファイルには触れず、仕様書の構成も変更しないでください。
• 仕様書だけを、最後に 1 回コミットします。
• タスクを実施する価値があるかどうかは判断しないでください。それは今回の問いではありません。
• 後から実装によって判断が覆った場合、再度調査を依頼されることがあります。その場合は再実行し、再利用に関するセクションだけを書き換えて、仕様書のみを新たにコミットしてください。