mcpField
R
repo-architecture

repo-architecture

github.com/objectivlabs開発9242 回インストール19 週間前に更新
リポジトリ

repo-architecture について

repo-architectureは、RepoSkillOptで特定リポジトリの現状アーキテクチャを分析するスキルです。依存関係や変更影響を評価する開発者向けで、Repository Specificationを前提にコード根拠を示し、成果物を決定的なチェックにかけます。

主な機能

  1. 01リポジトリ仕様とコード根拠の照合
  2. 02コンテキスト、コンテナ、コンポーネントの可視化
  3. 03エンドツーエンドのシーケンスと依存グラフの追跡
  4. 04モジュール、テスト、呼び出し箇所への変更影響分析
  5. 05主張への事実・推論・不明ラベル付け
  6. 06アーキテクチャと影響分析成果物の完全性チェック

活用シーン

  1. 01リポジトリ内のモジュールと依存関係の把握
  2. 02指定対象の変更による影響範囲の評価
  3. 03実装前のアーキテクチャと呼び出し経路の確認

インストール

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

$npx skills add https://github.com/objectivlabs/reposkillopt --skill repo-architecture

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

同梱ファイルCHANGELOG.md

詳細

RepoSkillOpt — 現状アーキテクチャ分析(標準スキル)

目的

これは RepoSkillOpt のリポジトリ特化型分析レイヤーです。汎用的な理解スキル (repo-skillopt)に変更はなく、リポジトリに依存しない Repository Specification を生成します。このスキルは 特定のリポジトリに特化し、その Repository Specification をさらに掘り下げて、 現在のアーキテクチャを根拠に基づいて把握し、「何を変更すると、どこに波及するか」を答えます。 すべてに手を加える前に実施します。Architecture View と Change-Impact (影響範囲)Analysis を生成します。また、現状を分析する段階として、将来像を計画する スキル(repo-orchestration)に利用されます。このスキル自体の内容はベンダーに依存しません(コーディングエージェントの実行環境への依存なし)。一方、出力はリポジトリ固有です。

トリガー条件

ユーザーがアーキテクチャのマッピング、依存関係/結合度/レイヤー構造の評価、 または**「もし〜を変更したらどうなるか/X を変更しても安全か」の評価**(あるいはそれらに相当する依頼)を求めたときに有効化します。 無関係な依頼では有効化しないでください。

前提条件

Repository Specification(.reposkillopt/specs/repository-specification.md)が必要です。存在しない場合は、前提条件を伝え、リポジトリ理解スキルを案内してください。浅い調査からアーキテクチャを 捏造してはなりません。

運用原則

  • 仕様を土台にし、コードと照合します。 Repository Specification を根拠の出発点とし、アーキテクチャに関するすべての主張を、実際のファイル、設定、呼び出し箇所と照合して確認します。
  • 主要な主張にはすべて根拠を示します。 各主張には、**[fact]**、**[inference]**、 **[unknown]**、**[human]** のいずれか1つだけを付けます。**[fact]** には解決可能な file:line/シンボルの引用を必ず付けます。
  • 黙って省略しません。 解決できない構造や影響は、理由を添えて **[unknown]** とし、決して省略しません。
  • 過剰な主張は避けます。 追跡していないレイヤーやフローを記述せず、推論は推論として示します。
  • リポジトリの事実は、そのリポジトリ内に限定します。 汎用化候補として明示されたパターンのみ、スキル統合のサイクルに取り込めます。

ワークフロー

(a) Repository Specification と、そこに記載されたエントリーポイント、マニフェスト、コアモジュールを読みます。

(b) Architecture View(.reposkillopt/architecture/architecture-view.md。templates/architecture-view.md に準拠):C4 形式のレベル、すなわち Context(システムと外部アクター)、 Containers(実行単位/デプロイ可能な単位)、Components(コンテナー内のモジュール)に加え、主要なシーケンス(エンドツーエンドのフロー。各段階に引用を付与)と依存関係グラフ(内部エッジに引用を付与)を記載します。すべてのコンポーネントとエッジには、実在する file:line の引用を付けます。図(graph、sequenceDiagram)は視覚的な補助であり、引用は不要です。ただし、図に示すすべてのノード/エッジは、引用付きの行にも記載してください。

(c) Change-Impact Analysis(.reposkillopt/impact/change-impact-analysis.md。templates/change-impact-analysis.md に準拠):指定された対象/変更について、影響を受けるモジュール、テスト、コントラクト、呼び出し箇所を記載します。各行には、根拠の強さに紐づいた確信度ラベルを付けます(引用付きの直接的な呼び出し箇所=高、名前解決/推論=中、動的/未解決=低かつ **[unknown]**)。また、引用も付けます。高速スキャナー(rg/grep)で影響箇所を特定し、引用する一致行のみを読みます。

(d) 決定論的な完全性ゲート。 完了前に、成果物が決定論的チェック(check_architecture_view、check_impact_analysis)に合格する必要があります。すべてのコンポーネント/エッジに解決可能な引用があり、すべての影響行に引用と確信度ラベルが付いていることを確認します。

出力規律

ラベル:**[fact]**(検証済み。引用付き)、**[inference]**(根拠を明記)、 **[unknown]**(その旨も一覧に記載)、**[human]**(Feedback Item の ID を引用)。引用には path:line、 path:start-end、path:Symbol[:line]、または cmd:/output: を使用します。自明な再掲にはラベルは不要です。

人間によるフィードバックループ

修正は フィードバック項目(templates/human-feedback.md)として .reposkillopt/feedback/ に記録され、成果物に直接反映されます。リポジトリ固有の修正は、 そのリポジトリの範囲内にとどめます。

スキルの収束ループ

汎用化候補としてマークされた、関連するフィードバックが繰り返し(3 件以上)寄せられ、 このスキルの弱点が明らかになった場合は、スキル編集提案(templates/skill-edit-proposal.md)を作成します。これは、検証ゲート(rubric/validation-gate.md)を通過した場合にのみ受け入れられます。検証ゲートでは、互いに重複しない保留済み参照セットに対して成果物を再生成し、次元別のルーブリックで後退がないこと(rubric/asis-architecture-rubric.md を参照)を確認し、決定論的チェックにも引き続き合格する必要があります。黙って昇格することはありません。受け入れ時にはバージョンを更新し、CHANGELOG にエントリーを追加します。受け入れた編集はすべて、4 つのアダプターにも反映します(アダプター間の同等性)。

コメント