mcpField
L
load-context

load-context

github.com/igmarinエージェントワークフロー2846 回インストール4 週間前に更新
リポジトリ

load-context について

既存の Rails コードベースで作業するコーディングエージェント向けのコンテキスト読み込みスキルです。変更を提案する前に対象を絞って読み、参照元を示し、矛盾を明示する手順を定めています。

主な機能

  1. 01スキーマ、ルート、近接実装に読取範囲を限定
  2. 02Rails の層ごとに類似コードを検索
  3. 03仕様とコードのずれを確認
  4. 04スコープ変更時にコンテキストを再読込
  5. 05コンテキスト要約にファイルを引用

活用シーン

  1. 01既存 Rails アプリで機能変更を始める
  2. 02近接パターンを基にコントローラーやサービスを計画
  3. 03仕様と実装の不一致を記録

インストール

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

$npx skills add https://github.com/igmarin/rails-agent-skills --skill load-context

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

EXAMPLES.md
references/
confusion-management.md
context-sources.md

詳細

コンテキストの読み込み

HARD-GATE

DO NOT propose code, specs, PRDs, or task lists until the Context Summary is posted.
DO NOT silently resolve ambiguity — if requirements conflict or specs and code disagree, post a Confusion Block first.
DO NOT load the entire repo — use targeted reads (schema, routes, one neighbor of each kind).
ALWAYS cite the files you read (path:line where possible) so the user can verify.
ALWAYS re-check context when the user's request changes scope mid-conversation.

コアプロセス

既存の Rails コードベースにおいて、コード、仕様、PRD のいずれかに着手する前に、最小限のコンテキストを読み込みます。db/schema.rb、config/routes.rb、そして隣接するファイルを1つ、15秒読むだけで、リトライを1回分まるごと節約できます。

自動コンテキスト (任意)

rails-ai-bridge が動作している場合は、get_project_context ツールを呼び出して統合されたプロジェクトコンテキスト (構造、ルート、モデル、スキーマ、依存関係) を取得します。これが成功した場合は、以下の手動ステップ 2 と 3 をスキップし、隣接パターンの探索と Context Summary の投稿に直接進みます。

手動コンテキスト探索 (フォールバック)
  1. 変更の範囲を定める: 一文で、影響を受ける Rails レイヤー (controller、model、service、job、engine、view/Turbo、migration、API、GraphQL) を明示します。
  2. ベースラインの Rails コンテキストを読み込む: 最低限以下を読みます:
    • db/schema.rb — 関係するテーブルとカラム (テーブル名で grep)
    • config/routes.rb — 変更に隣接するルート
    • Gemfile.lock — Rails のバージョン + ドメインの gem (sidekiq、pundit、rspec、rails-i18n、graphql など) の確認 タスクで明示的に要求されない限り、ベースラインコンテキストとして他のファイル (config/application.rb など) を読まないでください。
  3. 各種類につき隣接ファイルを1つ読み込む: 影響を受ける Rails レイヤーごとに、類似の問題をすでに解決している最も近い兄弟ファイルを開きます — 比較可能な controller、service、spec、factory です。 隣接ファイルを検索する際は、必ず次のパターンで正確な grep -r コマンドを実行し、引用してください: grep -r "class.*<LayerName>" <directory>。 具体的には:
    • Controllers: grep -r "class.*Controller" app/controllers
    • Services: grep -r "class.*Service" app/services
    • Models: grep -r "class.*Model" app/models
    • Jobs: grep -r "class.*Job" app/jobs クラスの検索に glob パターンや find コマンドを使用しないでください。正確な grep コマンドを Context Summary に含めてください。
  4. ドリフトを検出する: その領域に既存の spec がある場合は、それがアサートしている内容とコードが現在行っている内容を比較します。ドリフトは危険信号です — 文書化してください。
  5. Context Summary を投稿する: 提案の前に、以下のテンプレートを出力します (Output Style を参照)。
  6. 曖昧さを処理する: ステップ 2〜4 で競合 (2つのパターンが使われている、spec とコードが矛盾している、要件が欠けている、境界が不明確) が表面化した場合は、Confusion Block を生成します:
### Confusion Block
- Conflict: <what conflicts — e.g., spec asserts X but code does Y>
- Options: <list the options with their tradeoffs>
- Recommendation: <state which option and why, or ask user to choose>

黙って選ばないでください。 7. 引き継ぐ: コンテキストを読み込んだ状態で、次のスキル (plan-tests、apply-stack-conventions など) に進みます。Context Summary はタスクとともに引き継がれます。

Output Style

プロジェクトコンテキストの読み込み (またはコンテキストを含む計画・推奨の作成) を求められた場合、あなたの出力 answer.md は以下のテンプレートに正確に従わなければなりません。テンプレートブロックをその全体 (末尾の Resources セクションと3つの参照リンクすべてを含む) を複製しなければなりません。形式的な前置きを避けて出力を簡潔に保つため、動機となる原則は別のヘッダーを使わず、導入部分に直接織り込んでください:

Context Summary Template
To ensure a rapid setup and avoid retries, we follow the fifteen-second read principle of schema, routes, and one neighbor before proposing any changes.

### Context Summary
**Rails layer:** <controller | model | service | job | engine | view/Turbo | migration | API | GraphQL>
**Files read:**
  - <path>:<line-range> — <one-line finding>
  - <path>:<line-range> — <one-line finding>
  - (repeat for each file)
**Neighbor patterns found:**
  - <layer>: <file path> — <key convention or pattern observed> (found using grep: <exact grep command used>)
  - (repeat per layer)
**Gemfile notes:** Rails <version>; relevant gems: <list>
**Drift detected:** <none | description of spec-vs-code mismatch>
**Ambiguities:** <none | list any unresolved conflicts — triggers a Confusion Block>
**Next step:** <plan-tests | apply-stack-conventions | write migration | etc.>

**Resources:**
Load these files only when their specific content is needed:
  - [EXAMPLES.md](EXAMPLES.md) — Use when you need worked examples showing Context Summary and Confusion Block templates
  - [references/confusion-management.md](references/confusion-management.md) — Use when you encounter ambiguity or conflicting signals between code layers
  - [references/context-sources.md](references/context-sources.md) — Use when you need the comprehensive list of context sources by Rails layer beyond the Quick Reference table

落とし穴

落とし穴緩和策
過剰な grepディレクトリまたはクラス名のプレフィックスで絞り込みます。1レイヤーにつき隣接ファイルを2つ以上読まないでください。
schema.rb が存在しないdb/structure.sql を探します。代わりに関連する CREATE TABLE ブロックを解析してください。
複数の engine読み取りを特定の engine ディレクトリに限定し、境界をサマリーに文書化します。
spec が存在しないサマリーに「spec カバレッジなし」と書き、コードを信頼できる情報源として扱います。
自分自身が隣接ファイル変更対象のファイルを使わず、最も近い独立した兄弟ファイルを選んでください。
実行途中での範囲変更探索 (ステップ 1〜4) を再実行し、更新された Context Summary を投稿します。

拡張リソース(段階的開示)

これらのファイルは、その具体的な内容が必要な場合にのみ読み込んでください:

  • EXAMPLES.md — Context Summary と Confusion Block のテンプレートを示す具体的な例が必要な場合に使用します
  • references/confusion-management.md — コードレイヤー間の曖昧さや矛盾するシグナルに遭遇した場合に使用します
  • references/context-sources.md — クイックリファレンス表を超えて、Rails レイヤーごとのコンテキストソースの包括的なリストが必要な場合に使用します

コメント