Architecture
Application shape, tenancy, authorization, billing boundaries, public identity, frontend ownership, and where domain behavior lives.
Free Rails architecture checkup
How much architecture is your Rails app teaching your coding agent?
A mature Rails app already contains hundreds of decisions about tenancy, authorization, jobs, billing, frontend conventions, integrations, testing, and operations. Coding agents will learn from those decisions whether you documented them or not.
This checkup gives a repo-aware agent one job: figure out what your application already teaches clearly, where the precedent conflicts, and where the next feature still has to guess.
What it looks for
Not whether your app matches somebody else’s stack.
If your app uses CanCanCan instead of Pundit, that is not a finding by itself. The checkup is looking for whether the application has a coherent answer, whether that answer is safe, and whether an agent can discover it from the repository.
Agent context
AGENTS.md, architecture docs, local precedent, contracts, recipes, and places where the code says two different things.
Risk
Tenant isolation, permissions, secrets, external calls, retries, idempotency, error reporting, and other places inconsistency becomes a correctness problem.
Next steps
What to leave alone, what to document, what to normalize when touched, and what deserves deliberate remediation now.
Why this exists
Agents are very good at continuing whatever your repository already teaches.
That is useful when the precedent is good and surprisingly expensive when the app has accumulated several competing ways to solve the same problem. The goal of this prompt is to make that invisible context visible before another feature adds one more pattern.
It will not tell you to rewrite your application into Rails Baseline. An existing Rails app has history, product requirements, and working decisions worth preserving.