recursive-decomposition

recursive-decomposition スキルの概要

recursive-decomposition スキルは、作業を小さな単位に分割して個別に処理し、最後に結果を統合することで、大規模・複数ファイル・多段階のタスクを解きやすくします。単一プロンプトでは浅すぎる、あるいは不安定になりやすい場面、たとえば Workflow Automation 向けの recursive-decomposition、コードベース全体のレビュー、複数ドキュメントからの抽出で特に有効です。

このスキルは何のためのものか

recursive-decomposition スキルは、仕事の目的が「質問に答えること」ではなく、「大量の情報を確実に分析すること」であるときに使います。典型的には、多数のファイルを走査する、コードベース全体でパターンを比較する、多数の文書から構造化された事実を抽出する、分散したソースから統合レポートを作る、といった用途に向いています。

通常のプロンプトと何が違うのか

通常のプロンプトでは、モデルにすべてを一度で保持させようとします。これに対してこのスキルは、段階的に情報を開示する進め方に寄せます。まず探索範囲を絞り、次に関連部分へ再帰的に入り、最後に統合する。この流れが、文脈の劣化、ファイルの取りこぼし、集約の不一致によって出力品質が落ちるのを防ぐ大きな強みです。

向いている代表的なケース

recursive-decomposition スキルは、10件以上のファイル、5万トークン超の対象、あるいは手早い要約よりも体系的な網羅性が必要なタスクに強く向いています。一方で、範囲が狭く局所的な質問では、直接処理したほうが安く速いので、相対的に向きません。

recursive-decomposition スキルの使い方

インストールして有効化する

recursive-decomposition install では、Claude Code または skills 対応のワークフローにこのスキルを追加し、単一パスのコンテキストを明らかに超えるタスクで呼び出します。リポジトリの SKILL.md には references/ 配下の補助資料への案内があり、実運用での判断基準はそこにまとまっています。

入力は最初から適切に絞る

スキルには、対象、範囲の境界、出力形式を与えてください。良い入力例は、src/api、src/services、src/utils にまたがるエラーハンドリングを分析し、パターン、抜け、推奨事項を表で返す、のようなものです。弱い入力例は、「このリポジトリをレビューして」です。

先に読むべきファイル

recursive-decomposition の使い方をつかむには、まず SKILL.md を読み、その後に references/cost-analysis.md、references/codebase-analysis.md、references/document-aggregation.md、references/rlm-strategies.md を確認してください。これらのファイルには、いつ再帰させるべきか、どう分割するか、構造を崩さずに結果をどう集約するかが示されています。

より良い結果につながる進め方

次の順序で進めると効果的です。範囲を定義する → 候補のファイルや文書を特定する → 厳しく絞り込む → 残った項目をバッチ化する → 並列サブタスクを実行する → ひとつのスキーマにまとめて知見を統合する。recursive-decomposition のガイドは、何を除外するか、何を証拠とみなすか、最終出力をどう整理するかを明示すると、最も力を発揮します。

recursive-decomposition スキル FAQ

いつ recursive-decomposition を使うべきか

多くのファイル、多くの文書、あるいは大きなトークン予算にまたがるタスクで、速度よりも完全性が重要なときに使います。作業が局所的で、範囲が狭く、すでに十分絞れているなら、直接処理で十分なことが多いです。

recursive-decomposition はコードベース専用ですか？

いいえ。同じパターンは、コードベース、調査メモ、PRD、長文レポート、その他の文書群にも使えます。重要なのは、そのタスクがフィルタリング、分割、集約の恩恵を受けられることです。

いちばん起こりやすい失敗は何ですか？

もっとも多い失敗は、要件が曖昧なまま recursive-decomposition を使うことです。対象集合、出力形式、受け入れ基準を定義していないと、スキル自体は効率よく再帰できますが、焦点のぼやけた結果になりがちです。

このスキルは初心者向けですか？

はい。ただし、具体的なゴールと範囲の境界を説明できることが前提です。初心者は、広く探る依頼よりも、ギャップ分析、棚卸し、比較のように成果物がひとつに定まる依頼のほうがうまく使えます。

recursive-decomposition スキルを改善するには

検索の枠をもっと狭くする

recursive-decomposition を最も活かせるのは、最初から境界のある問いを置いたときです。「リポジトリをレビューして」ではなく、「src/api と src/services にあるエラーハンドリングのパターンをすべて抽出し、不整合を指摘し、モジュール別に要約して」といった形にしてください。枠を絞るほどノイズが減り、再帰処理にかかるオーバーヘッドに見合うだけの価値が出ます。

抽出スキーマを先に渡す

構造化された出力がほしいなら、各項目に何を含めるかを明示します。たとえば、file、pattern、severity、evidence、recommendation です。こうしておくと、並列サブ結果がそれぞれ違う語り口になるのを防ぎ、比較しやすくなります。

しきい値と除外条件を明確にする

リポジトリの判断ロジックでは、トークン数、ファイル数、そして速度より品質を重視するかどうかが重要です。制約が分かっているなら、はっきり伝えてください。たとえば「テストは除外する」「アーカイブ済みの文書は無視する」といった指定です。