Edit this page


A digitized AI guide in side profile faces a conceptual CaseFlow Rails editor; layered context and a ruby-colored flow lead to an unresolved evidence question beneath the GitHub Copilot for Rails Engineers Part 02 series heading.

GitHub Copilot for Rails Engineers · Part 02

The first chapter left us with a CaseFlow architecture atlas and a client question: can a user transition a service request to resolved? The code lists resolved as an allowed stored status, but routes expose only index, show and create. A broad prompt such as “implement status changes” invites plausible Rails code and unsupported assumptions about authorization. This chapter narrows the context before asking Copilot for any change.

We will add three different kinds of guidance to the integrated CaseFlow lab: a repository instruction, a model-path instruction and a single-use audit prompt. Then we will compare Copilot’s response with the code and a small evidence register. The exercise asks for a proposal only; we will implement and review a change in Part 03.

Contents

Three scopes, one engineering question {:#scopes}

GitHub distinguishes repository-wide .github/copilot-instructions.md, path-specific .github/instructions/*.instructions.md, and agent-oriented AGENTS.md. Prompt files serve a particular interaction. Their availability varies by Copilot surface: consult the official support matrix for the feature and editor you actually use. These files guide responses; they are not Rails code, tests or access controls.

Context CaseFlow file Question it should answer Avoid
Repository caseflow/.github/copilot-instructions.md What kind of app is this, and what evidence is required? A full copy of the codebase
Model path caseflow/.github/instructions/models.instructions.md What is special about model edits? Global rules repeated at length
One task caseflow/.github/prompts/02-context-audit.prompt.md What should this investigation deliver now? Unbounded “build everything” request

The caseflow/ directory should be opened as the VS Code workspace root for this exercise. Its .github/ is then at the root of the Rails repository as Copilot expects. If you open the companion repository’s outer folder instead, check which workspace and instruction files your Copilot surface is actually using. Do not infer automatic loading from a good answer; open the citations and inspect the available session context.

A Ruby model and task prompt in a conceptual editor receive repository guidance; an amber evidence gate separates a cited proposal from an unresolved question.
Repository rules, model scope and the task prompt inform a cited proposal. The amber gate marks evidence to check; this conceptual editor is not a screenshot or a test run.

Write the smallest useful repository guidance {:#repository}

Place durable facts and review habits in caseflow/.github/copilot-instructions.md. The support package includes the complete file; its core contract is short:

- Inspect the actual route, controller, model, migration, and request specs before describing behavior; do not infer a UI, authentication, jobs, or a status transition.
- Distinguish a source declaration, an existing spec assertion, and a command you actually ran. Quote the path for every behavioral claim and state unknowns explicitly.
- Keep proposed changes within the requested scope. Before editing, identify affected files and a focused verification step.

An instruction that says “tests always pass” would be false. An instruction that says “run a focused spec and report its exit status” is operationally useful. A repository file tells the assistant how to work; it cannot attest that a local database migrated or that a particular HTTP response was observed. Avoid copying a full README into instructions: link to existing files and keep the rules that change decisions.

Narrow guidance to a Rails model {:#models}

A model change has a different failure mode than a README edit. The packaged .github/instructions/models.instructions.md starts with:

---
applyTo: "app/models/**/*.rb"
---

It asks for controller, model, migration and specs to be inspected together. CaseFlow validates title presence and maximum length in the model; the migration declares title non-null but no database length limit. resolved is an accepted status value in ServiceRequest::STATUSES; that does not provide an update route or establish who may use it. The path-specific rules keep those distinctions visible whenever a matching model file is in scope. They do not automatically govern every question about the project; verify actual file context and support for your Copilot feature.

Notice that the dotted, hypothetical “AI remembers everything” arrow is absent. The diagram shows inputs to an audited proposal, not a guarantee of which context a particular model session used. The evidence boundary still needs human review.

Ask for a source-backed change proposal {:#prompt}

The packaged task prompt asks for four artifacts: an evidence table with paths, a list of applicable instructions, a minimal change surface with positive and negative tests, and unresolved authorization and runtime questions. Open caseflow/ in VS Code; use the prompt file if your Copilot workflow supports it, or paste its body into chat with the relevant files explicitly referenced. The key instruction is “Do not edit files.” This is an investigation before Part 03, not agent implementation.

A useful answer could say: config/routes.rb declares no update route; app/models/service_request.rb allows resolved; app/controllers/api/requests_controller.rb permits only title and description for creation; a future update should define its own authorization requirement. That last sentence is a design requirement to resolve, not proof an authorization system exists. Ask Copilot to label it accordingly.

Audit context against evidence {:#audit}

Before accepting the response, fill in this table from the files, then compare Copilot’s exact paths. Supplied RSpec examples describe expectations for create, list and show; they have not been executed in this authoring environment.

Claim from an answer Check Evidence class
resolved can be stored caseflow/app/models/service_request.rb Source: allowed value
A client can transition a request today caseflow/config/routes.rb and controller Unsupported; no update action
A create payload can set status caseflow/app/controllers/api/requests_controller.rb Unsupported; not permitted there
All current request specs passed Actual bundle exec rspec output and exit code Unknown until a real run
A user may perform a transition Written product rule and implemented authorization Unknown; must be designed

This is an instruction audit as well as a code audit: if the assistant claims to have seen instructions, ask it to name their paths and explain which file scope matched. If it invents an ApplicationPolicy or conflates the database default with an HTTP guarantee, correct the guidance or task prompt only after identifying the actual failure. Do not treat instruction text as a security control: enforce permissions in code and verify them with tests.

Your 25-minute lab {:#lab}

  1. Open caseflow/ as the VS Code workspace root. Read the CaseFlow README, instructions and the three code paths in the audit table.
  2. Predict which statements in “A user can set any ServiceRequest status through the API” are unsupported. Write the paths before asking Copilot.
  3. Run the packaged 02-context-audit.prompt.md in your Copilot setup, or paste the prompt content. Save a redacted answer in your own notes; do not add secrets or customer data.
  4. Compare paths, claims and unknowns with the workbook and answer key. For an optional controlled comparison, repeat the prompt with the model instruction excluded from your explicit context and record what changes; do not conclude which file was automatically loaded from output quality alone.
  5. Hand the client a two-sentence finding: what the current API supports, and what must be decided before implementing transitions. Part 03 will start from that bounded issue.

Acceptance criterion: a reviewer can trace each present-tense behavior to source, distinguish tests that exist from tests that ran, and find at least one open authorization question before writing code.

References and supporting materials {:#references}