load-context

Load Context

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.

Core Process

Load minimum context before any code, spec, or PRD in an existing Rails codebase. A fifteen-second read of db/schema.rb, config/routes.rb, and one neighbor saves a full retry.

Automatic Context (Optional)

If rails-ai-bridge is running, call the get_project_context tool to retrieve unified project context (structure, routes, models, schema, dependencies). When this succeeds, skip manual steps 2 and 3 below and proceed directly to finding neighbor patterns and posting the Context Summary.

Manual Context Discovery (Fallback)

1. Scope the change: In one sentence, name the Rails layer touched (controller, model, service, job, engine, view/Turbo, migration, API, GraphQL).
2. Load baseline Rails context: Read at minimum:
   • db/schema.rb — tables and columns involved (grep by table name)
   • config/routes.rb — routes that border the change
   • Gemfile.lock — confirm Rails version + domain gems (sidekiq, pundit, rspec, rails-i18n, graphql, etc.) Do not read other files (like config/application.rb) as baseline context unless explicitly requested by the task.
3. Load one neighbor of each kind: For each Rails layer touched, open the nearest sibling that already solves a similar problem — a comparable controller, service, spec, factory. When searching for neighbors, ALWAYS run and cite the exact grep -r commands using the pattern: grep -r "class.*<LayerName>" <directory>. Specifically:
   • 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 Do not use glob patterns or find commands to search for classes. Include the exact grep command in the Context Summary.
4. Detect drift: If there is an existing spec for the area, compare what it asserts vs what the code currently does. Drift is a red flag — document it.
5. Post the Context Summary: Before any proposal, output the template below (see Output Style).
6. Handle ambiguity: If steps 2–4 surface a conflict (two patterns used, specs contradict code, missing requirement, unclear boundary), produce a Confusion Block: