mcpField
R
recon

recon

github.com/venhdev開発1131 回インストール今日更新
リポジトリ

recon について

reconは、サブシステムの境界、実行フロー、システム不変条件を追跡するコードベース調査スキルです。対象の規模に応じて調査方法を調整し、コード位置を示す構造化レポートを作成します。

主な機能

  1. 01エントリポイントとモジュール境界の把握
  2. 02主要な実行フローの追跡
  3. 03不変条件と副作用の特定
  4. 04コードベースの規模に応じた調査
  5. 05構造化されたアーキテクチャレポート

活用シーン

  1. 01変更前のサブシステム理解
  2. 02モジュールをまたぐ実行経路の追跡
  3. 03アーキテクチャ上の課題と設計案の発見

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/venhdev/skills --skill recon

インストール後、Claude Code で/reconを入力して読み込まれたか確認します。

詳細

recon — コードベースのトポロジーとアーキテクチャをマッピングするエンジン

ドメイン評価基準

1. マッピングの観点
  • 地形とモジュール境界：エントリーポイント、スキーマ、データモデル、およびサブシステム間のアーキテクチャ境界。
  • 主要な実行フロー：実行時のディスパッチを入力から終端状態の永続化まで追跡する、正確なコードポインター（file:///path/to/file#L<N>）付きの逐次的な呼び出しチェーン。
  • システムの不変条件と注意点：トランザクション境界、状態のライフサイクル、隠れた副作用、仕様の乖離。
2. 調査のガードレール（対象外とするもの）
  • アーキテクチャの遷移とモジュール境界に厳密に焦点を当て、些細なリーフユーティリティ、一時的なテストフィクスチャのカタログ化、または生のディレクトリ一覧の羅列は禁止します。

正式な出力仕様

# Codebase Cartography: <Subsystem / Target Scope>

## 1. Topography & Architectural Seams
- **Entrypoints**: <Primary intake points, commands, public APIs, or event consumers with file pointers>
- **Core Contracts & Schemas**: <Key interfaces, data types, state schemas, or governing specifications>
- **Module Boundaries**: <Key directories/packages and their distinct architectural responsibilities>

## 2. Key Execution Flows
### Flow: <Primary Flow Name, e.g., Data Intake / Transformation / Render Pipeline>
1. `<Symbol>` ([<file>#L<N>](file:///path/to/file#L10)) ── <Trigger or input intake>
2. `<Symbol>` ([<file>#L<N>](file:///path/to/file#L50)) ── <Intermediate dispatch, orchestration, or validation>
3. `<Symbol>` ([<file>#L<N>](file:///path/to/file#L90)) ── <Core state transition, persistence, or terminal execution>
*(Add secondary flow if distinct execution path exists)*

## 3. Invariants & Gotchas
- **Invariants (Must Preserve)**: <Core rules, transaction boundaries, or state lifecycles that cannot be broken>
- **Gotchas (Watch Out)**: <Hidden side-effects, spec drift, or surprising couplings; state 'None observed' if clean>
ルーティング
  • 依頼者が、方向性が確定しており、実行パスと変更境界が明確な変更を要求している場合 →（/changeset 経由）。
  • アーキテクチャ上の緊張関係、トレードオフ、または複数の実現可能な実装方法が判明した場合 →（/clarify 経由）。

実行プロトコル

フェーズ 1：マクロアンカーの把握
  1. 対象のサブシステムまたはコードベースの範囲を把握します。
  2. ファイルとシンボルのツールを使って、上位レベルのアーキテクチャアンカー（エントリーポイント、主要なスキーマ、ルーターの境界）を調査します。
  3. 詳細な調査に入る前に、アンカーの座標を確定します。
フェーズ 2：規模に応じたマッピング
  1. 対象範囲の規模を評価します。
    • ターン内実行（10 ファイル未満、または単一のまとまりあるモジュール）：発見したアンカーに基づいて、そのターン内で呼び出しフローを直接追跡し、サブエージェントによる遅延とトークンのオーバーヘッドをなくします。
    • サブエージェントへの分散（広範なコードベース、または複数レイヤーにまたがる範囲）：1～3 個の research サブエージェント（役割：Cartography Scout (<Layer>)）を起動します。各サブエージェントには、対象境界、発見したアンカー、および正式な出力仕様を伝えます。
フェーズ 3：統合とターン停止ゲート（集約）
  1. 調査結果を正式な出力仕様に沿って統合します。
  2. 完成したマッピングを会話ストリームに提示し、ただちにターンを終了します。

コメント

Markdown 対応