reconstruct

Reconstruction：あらゆるリポジトリ、またはアイデアを、ビルド可能な PRD スイートへ

エンジンの根拠とカバレッジの限界については、engine-evidence をお読みください。

依存関係のない Node スクリプトが、決定論的な足場（事実と候補の ヒント）を作成します。 あらゆるスタックに対応する、フレームワークを踏まえた理解、つまりインターフェースの範囲、データモデル、実際の機能は、あなたが提供します。出力は、エージェントが元のプロジェクトにもこの会話にもアクセスせずに再構築できる PRD フォルダーです。

Markdown がプログラムです。 エンジンが推論することはありません。このスキルにおける判断はすべて、あなたが行います。

リクエストを振り分ける

ユーザーの要望	パス	まず実行すること	次に読むもの
リポジトリを再構築／クローン／リバースエンジニアリングする。コードを仕様に変換する	code	node scripts/analyze.mjs --repo <REPO> --out <OUT>	procedure.md §Path A
アイデアを PRD／ビルド計画にする（コードはまだない）	greenfield	まずインタビュー — コマンドは不要	scratch-playbook.md、procedure.md §Path B
何を作るか決める。コンセプトを検討する	brainstorm	node scripts/analyze.mjs --brainstorm --out <DIR>	brainstorm-playbook.md
既存の再構築を続行／更新する	resume	node scripts/analyze.mjs --check --out <OUT>	procedure.md §Path D
エージェントに渡して実装させる単一ファイルを作る	bundle	node scripts/analyze.mjs --specs --out <OUT>（--repo は指定しません）	scale-and-context.md §6
再構築したプログラムを、ローカルのケースで元のプログラムと比較する	behavior	フィクスチャを確認し、まずコマンド実行の許可を得る	behavior-compare.md

インストール済みのスキルフォルダー内にある scripts/analyze.mjs の絶対パスを使用してください。すべてのフラグは --help で確認できます。小規模な単一ファイルのスクリプトや、計画よりも今すぐ動作するアプリをユーザーが求めている場合は、このスキルを省略してください。

確認する入力（code パス）：対象のリポジトリ · 出力ディレクトリ · モード preserve（アーキテクチャを維持）または redesign（同じ機能を維持し、新しいアーキテクチャを採用） · レベル light（忠実に再現）または complex（改善案も提案） · 忠実度 mirror／embed／describe（未指定の場合はモードとレベルから決定）

パイプライン — 4 つのフェーズ

# 1. SCAFFOLD — deterministic, no API key
node scripts/analyze.mjs --repo <REPO> --out <OUT> --mode <MODE> --level <LEVEL>

# 2. ORIENT — SUMMARY.md (~3 KB, written every run), NOT inventory.json (grows with the repo)
#    slice the inventory:  jq '.features[] | {slug, files: (.files|length)}' <OUT>/inventory.json
#    identify the stack → references/stack-guides/INDEX.md maps the label to its guide

# 3. ENRICH — fill INTERFACES.md, DATA-MODEL.md, ARCHITECTURE.md (+ DESIGN-SYSTEM.md for a UI),
#    then every features/<slug>/PRD.md to full spine depth. At scale, fan out:
node scripts/analyze.mjs --orchestrate --out <OUT> --phase enrich-map

# 4. CONVERGE — run to the fixpoint, autonomously, in one go
node scripts/analyze.mjs --check   --out <OUT>              # layer 1: structure
node scripts/analyze.mjs --review  --out <OUT>              # layer 2: worklist (changed units only)
#   → findings.json → --review --apply findings.json --out <OUT>
node scripts/analyze.mjs --verify  --out <OUT>              # faithfulness: requirement↔evidence
#   → verdicts.json → --verify --apply verdicts.json --out <OUT>
node scripts/analyze.mjs --check --semantic --out <OUT>     # the final, fail-closed gate

フェーズ 4 はチェックリストではなく、ループです。--check --semantic が 0 で終了するまで、強化 → チェック → レビュー → 修正 → 検証 → 判定を繰り返します。そのルール、台帳のフィールド、終了条件は、convergence-loop.md で一元的に定義されています。独自に終了ルールを決めないでください。

絶対に守るべきこと

• hints、routes、i18nは確認候補であり、確定情報ではありません。 ソースを開いて確認してください。inventory.unknownsのすべての項目を解決してください。inventory.warningsがある場合は、その部分で検出精度が低下しています。該当箇所を手作業で確認してください。
• すべての> 🧠コールアウトを解決して削除してください。 1つでも残っていれば、そのユニットは未完了であり、--checkに失敗します。
• 例示ではなく、網羅してください。 「など」や「その他」、正常系だけに限定することは禁止です。動作、役割、検証ルール、エラー状態が存在する場合は、それぞれを個別の行に記載してください。
• 名称ではなく、仕様を記録してください。 数値のないレート制限、メンバー一覧のない列挙型、リクエスト形式が不明なサービスは、いずれも実装できません。10項目のカテゴリについては、buildability-checklist.mdを参照してください。
• 少数の広範なPRDより、多数の小さなPRDを作成してください。 1つのユニットにストーリーが約5～7件を超える場合、またはエンティティが約3つを超える場合は、分割してください。異なる機能ごとに、個別のPRDを作成してください。
• 情報を拡充したツリーに対して、アナライザーを再実行しないでください。 すべてのドキュメントが再生成されます。CLIはこれを拒否します。既存のツリーで作業を続けるには--check／--review／--verifyを使用し、再度スキャフォールドするには--outに新しいディレクトリを指定してください。
• すべての主張の根拠を（コードモードでは）source/／data/、または（スクラッチモードでは）CONTEXT.md／ADRに求めてください。根拠のない修正を加えると、別の指摘に置き換わるだけです。
• 上限によって確認が黙って打ち切られないようにしてください。 --verifyは作業リストに上限を設け（デフォルトは60ペア）、ファンアウトが大きい場合はエージェント数にも上限を設けます。coverageを読み、実際に確認した範囲を報告してください。
• ループを最初から最後まで自分で完了してください。 修正がなくなるまで自分で実行してください。ラウンドを他者に引き継がず、「続けますか？」と尋ねず、最初のパスで止めないでください。報告は最後に一度だけ行ってください。
• セルフチェック： 新しいエージェントが、PRDとアーキテクチャドキュメントだけを使って、このユニットを正確に再構築できるでしょうか。大意が分かるだけでは不十分で、仕様が正しい必要があります。そうでなければ、さらに調査してください。必要な深さの基準はworked-example.mdを参照してください。

オーケストレーション — ハーネスに応じたルート選択

判断フェーズでは、独立したユニットごとの作業リストに処理を振り分けます。--orchestrateは、<OUT>の現在の作業リストをもとにファンアウトを出力します。絶対パスと実際のユニットIDが組み込まれます。

node scripts/analyze.mjs --orchestrate --out <OUT> [--phase enrich-map|review-find|review-verify|adjudicate] [--eco] [--list]

使用するハーネス	各判断フェーズの実行方法
Codexまたはサブエージェントに対応する別のホスト	--orchestrate --phase <p>を実行し、<OUT>/orchestration/agents/<role>.mdに従って、バッチごとにサブエージェントを1つ割り当てます。サブエージェントは断片を返します。単一の逐次マージを行い、foldコマンドを実行するのはあなたです。
Workflowツールを使うClaude Code	--orchestrate --phase <p>を実行し、続いてWorkflowで<OUT>/orchestration/<p>.workflow.mjsを起動します。サブエージェントは断片を返します。単一の逐次マージを行い、表示されたfoldコマンドを実行するのはあなたです。
Ecoモード、またはサブエージェントを使わない場合	--orchestrate --ecoを実行し、<OUT>/orchestration/RUNBOOK.mdに従って順番に進め、各役割を自分で担います。正確性は同じで、異なるのは経過時間だけです。

ファンアウトは最適化の手段であり、必須ではありません。ゲートはハーネスに依存せず、すべてのフェーズに同一の成果物を生成する逐次実行の代替手段があります。サブエージェントは書き込みを行いません。 各ドキュメントのマージも、すべての--applyのfoldも、必ずあなたが行ってください。グリーンフィールドのヒアリング、--brainstorm、reduceステップ、スクラッチビルドをファンアウトしてはいけません。作業リストが作成される前に--phase <p>を実行すると、終了コード2で終了し、その作業リストを生成するコマンドが示されます。プロトコルについてはorchestration.md、規模の決め方についてはscale-and-context.mdを参照してください。

参照マップ

まずはこちら

ファイル	読むタイミング
procedure.md	作業を進めるとき — 4つすべての経路について、手順を最初から最後まで確認できます
convergence-loop.md	フェーズ4 — ループ、台帳、停止するタイミング
worked-example.md	最初の PRD を書く前 — 求められる深さとアンチパターン
troubleshooting.md	何かが失敗する、拒否される、または成功状態にならないとき

手法

ファイル	読むタイミング
analysis-playbook.md	汎用的な手法 — スタックガイドがない場合に使えます
stack-guides/INDEX.md	スタックラベルに対応するガイドを選ぶとき — ファイル名を推測しないでください。 references/stack-guides/ 内のすべてのチートシートを掲載しています。フレームワークを使わないケース（ライブラリ／CLI／SDK）も含まれます
buildability-checklist.md	10 の契約カテゴリと、一貫性を確認するセルフレビュー
architecture-analysis.md	ARCHITECTURE.md を埋めるとき。特に redesign モードの場合
scale-and-context.md	大規模なリポジトリ、モノレポ、または実行でコンテキストを使いすぎているとき
adapters.md	inventory.routes の解決方法と、フレームワークの追加方法

ゲート

ファイル	読むタイミング
ai-review-rubric.md	レイヤー2 — 9つの意味的なビルド可能性チェック
verify-playbook.md	--verify — 主張、証拠、判定、信頼度、上限
orchestration.md	エンリッチメントの分担と、サブエージェント間でのレビューループ

グリーンフィールドとアイデア創出

ファイル	読むタイミング
scratch-playbook.md	グリーンフィールドのインタビューメソッド
scratch-plan-schema.md	plan.json を書くとき — スキーマと記入例
CONTEXT-FORMAT.md · ADR-FORMAT.md	用語集／ADR を書くとき
brainstorm-playbook.md	何かを決定する前の発散フェーズ

出力形式

ファイル	読むタイミング
prd-light-template.md · prd-complex-template.md	レベルごとの PRD 形式
rebuild-instructions.md	再構築を進める方法をユーザーに伝えるとき

安全性

アナライザーは対象リポジトリを読み取り、ファイルを出力先にコピーするだけです。分析中に、解析対象プロジェクトのコードを実行することはありません。別途オプトインが必要な --compare <cases.json> --original <dir> --rebuilt <dir> --run-tests モードでは、 ローカルユーザーの権限でフィクスチャのコマンドを実行します。--run-tests を使う前にすべてのコマンドを確認し、明示的な許可を得てください。許可がない場合、ケースは not-tested のままとなり、ゲートは失敗します。報告するのは実行したケースと、標準出力／標準エラー／終了コードが完全に一致したかどうかだけにしてください。全体的な同等性を報告してはいけません。ソース忠実性とビルド可能性の台帳は、引き続き独立したゲートです。信頼できないリポジトリで実行する前に、scripts/ を確認してください。