Edit this page


GitHub Copilot for Rails Engineers Part 08: a digitized guide faces the CaseFlow Rails workbench, where repository instructions, a task recipe and permitted tools feed evidence to a human reviewer; optional boundaries remain visible.

A successful prompt is a moment; a reliable workflow can be taught. This final chapter turns eight Rails/Copilot exercises into a small, auditable procedure that knows when to stop.

GitHub Copilot for Rails Engineers · Part 08 · Final chapter

Parts 01–07 took one synthetic CaseFlow Rails app from source orientation through instructions, a candidate change, staged CI, an adoption pilot, a client workshop and a Copilot CLI rehearsal. The last question is architectural: which parts should be repeated by an agent, and which must remain decisions by a developer or client? A stack of customizations is not the answer by itself. This chapter makes one workflow explicit, gives it a Ruby evidence check, and leaves all rollout switches off until there is a reason to enable them.

The cumulative companion package contains Parts 01–08, the integrated CaseFlow source, this complete article, a workflow blueprint, a blank JSON evidence record, a Ruby structural validator, Mermaid source, visual masters, and exercises with answers. No Copilot skill, hook or MCP server is installed by this educational release.

Contents

Begin with one Rails task {:#task}

Use the same bounded exercise: the CaseFlow baseline allows index, show and create for api/requests; Part 03 proposes a separate PATCH /api/requests/:id/resolve route. Part 07 asks Copilot CLI to plan and potentially propose that change on a local branch. The Part 03 patch is a candidate, and Part 04’s CI workflow is staged. The purpose here is to capture what a reviewer would need: exact source files, candidate diff, actual focused test command/log, and a named review decision. Do not turn an imagined result into a “passed” badge.

This makes a useful question for every mechanism: What new failure or authority does it introduce, and what evidence makes it worthwhile? A task can succeed with the existing repository instructions, CLI permission prompts, a human review and a single Ruby check. Add another component only when a repeated need justifies it.

Choose the smallest useful mechanism {:#mechanisms}

GitHub’s Copilot CLI customization comparison separates several tools that are often blended into “agentic workflow.” Apply them to the same Rails task:

Mechanism Job in CaseFlow Is it installed by this chapter?
Repository instructions Always remind Copilot of Rails conventions and the difference between source and runtime evidence Already present from Part 02 in caseflow/.github/copilot-instructions.md
Task skill Load a reusable recipe when someone asks for a reviewable Rails change No; blueprint describes when to author one
Built-in CLI tools Read source, propose an edit or run a command after permission review Available in the CLI; no operation run during authoring
MCP tool Access an external system only if an authorized task actually needs it No server or credential added
Hook Execute a deterministic command at a lifecycle point after payload and failure behavior are tested No hook configured
Human reviewer Evaluate relevant outputs, security implications and approval Decision field intentionally blank

This table is a design choice for this lab, not a list of everything Copilot can do. A SKILL.md is suited to a repeatable, relevant procedure; GitHub’s skills guide describes project locations and loading. Its documentation warns about pre-approving shell access in a skill. We therefore provide a workflow blueprint, not an installed skill granting tool permission. The learner can propose a skill after several human-reviewed repetitions.

Make evidence explicit in Ruby {:#evidence}

The companion’s parts/08-repeatable-rails-workflow/EVIDENCE.json has two source paths and blank fields for diff, test command, exit code, test log, reviewer and decision. A small Ruby standard-library script checks that these fields are filled and that referenced files exist inside the companion repo:

ruby scripts/08_validate_evidence.rb parts/08-repeatable-rails-workflow/EVIDENCE.json

Expected on the shipped template: a nonzero exit listing missing evidence. The script does not run RSpec or the CLI, read a remote service or mark a test as passed. If you fill the record after a real Part 07 session, a zero exit means only that the structure and paths look complete. A human still checks that the log belongs to the stated branch and command, that negative tests are relevant, that authorization is sound and that the decision is accountable. Fake data can make a structural validator happy; that is why it is not an approval system.

{
  "candidate_diff": "",
  "test_command": "",
  "test_exit_code": null,
  "test_log": "",
  "reviewer": "",
  "decision": ""
}

Those fields are excerpts from an intentionally blank template, not a transcript. Store no secrets or personal telemetry in it. The blueprint shows the expected location of local files and the exact command to run from the companion root. The validator cannot establish genuine provenance or actual test quality.

Know where optional extensions fit {:#extensions}

Suppose a team repeats this evidence procedure every week. A skill can teach Copilot to collect the exact diff and check logs when that task is requested. If every attempted operation must be screened against a protected directory, a hook may enforce a reviewed rule; hooks execute commands at lifecycle points, so mistakes affect real work. GitHub’s hook reference describes events and payloads that a team must test against its installed CLI. Neither mechanism is active in this package.

A cutaway CaseFlow workbench shows persistent instructions around a task recipe, a local tool action, an optional external MCP bridge and an inactive guard checkpoint; Ruby evidence and human review remain downstream.

The illustration shows different jobs around one task, not a stack every team must install. A built-in tool is enough to read config/routes.rb. An MCP connection would add an external source such as a client ticket system; that requires specific permission, scope, retention and revocation. It brings no value to the synthetic CaseFlow exercise. An unarmed hook in the drawing is a design possibility, not an implemented guardrail.

The matching editable diagram lives in docs/diagrams/08-workflow-boundaries.mmd. Its optional dashed MCP edge and two possible human outcomes are intentional. The diagram is a proposal, not evidence of an installed agent, server or passed gate.

There are neighboring surfaces you may study later: gh performs GitHub repository operations and is a different executable from copilot; the Copilot desktop app addresses desktop agent sessions; the Copilot SDK is for building an application around its runtime. GitHub’s current SDK guides list examples in TypeScript, Python, Go, .NET, Java and Rust, so this Ruby-only companion does not pretend to provide an official Ruby SDK integration. HydraFusion is a visual/thematic reference from the blog’s agentic-engine post, not an additional dependency or security control required by the Rails exercise.

Promote a procedure only after review {:#promote}

The right end state is modest: a team that can explain its source map, show a focused candidate change, reproduce its checks, state a privacy boundary and hand a reviewer an honest ledger. A real organization may then choose to publish repository instructions, package a skill, prototype a hook or authorize an MCP service. Give each addition an owner and a separate test. Keep baseline measurements and client approval out of this synthetic repo until they genuinely exist.

Across this series, repeatability means that another engineer can follow the same decision points and challenge the same evidence. It does not mean every action should run without a person. Stop if the route claim lacks a source path, the agent touches a secret, test output cannot be tied to the diff, or no authorized reviewer can decide what happens next.

Try the final lab {:#lab}

  1. Map (10 min): point to the CaseFlow route, Part 03 candidate patch and Part 07 prompt. Label source, proposal and unknown.
  2. Choose (10 min): use the mechanism table and workflow blueprint to say which customizations you would actually enable for this task.
  3. Check (10 min): run the Ruby structural validator on the intentionally blank JSON on your Mac; record its actual exit and findings. Do not fill invented results just to get green.
  4. Rehearse (15 min): imagine a real focused RSpec run and describe where its authentic log, branch, command and review decision would go. Then try the workbook before reading its answer key.
  5. Transfer (5 min): deliver a two-minute client explanation of what you would reuse, what still needs permission, and what would make you stop.

References and supporting material {:#references}