rails_ai_agents: A Claude Code Configuration Pack for Rails Teams
Specialized AI skills, agents, rules and hooks for modern Rails AI driven-development + Spec-Driven-Development kit + MCP
At a glance
- What is it?
- ThibautBaissac/rails_ai_agents ships 19 agents, 26 slash commands, 18 skills, 14 rules and 6 hooks as plain files you copy into a Rails project, plus a parallel 37signals conventions pack and a spec-driven development pipeline. The real question is whether your team's conventions match the ones baked in.
- Who is it for?
- Adopt this if your Rails app already uses RSpec, Pundit, PostgreSQL and a layered service-object architecture, because the shipped agents encode those choices and you will spend more time deleting than adding otherwise. Skip it if you run Minitest with rich domain models and no service layer, unless you are willing to start from .claude_37signals/ and accept that the documented slash-command set lives under .claude/commands/ and does not come with that pack.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 107 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is convention drift, not code generation
A general-purpose coding assistant asked to add a Rails feature will produce something plausible and wrong for your codebase. It puts authorization checks in the controller when your team uses Pundit policies, writes a fat model when your convention is a service object, or adds a query that triggers an N+1 the reviewer has to catch. The fix is not a better model. It is telling the assistant, in a form it reads automatically, which conventions apply.
This repository is that telling, packaged. The README describes it as a production-ready Claude Code setup: 19 specialized agents, 26 slash commands, 18 skills, 14 rules (11 path-scoped plus 3 always-on), one MCP server and 6 lifecycle hooks. The audience is Rails teams already using Claude Code who want the assistant to know TDD workflows and production patterns without re-explaining them per session. Everything ships as files in a .claude/ directory, so the unit of adoption is a copy command, not a dependency.
Agents, skills and rules are three different loading mechanisms
The pack separates three kinds of instruction, and the difference matters when you debug why the assistant ignored something.
Agents live in .claude/agents/ and carry frontmatter fields the README names explicitly: permissionMode: acceptEdits, memory: project, maxTurns limits, and WHEN/WHEN NOT descriptions used for auto-delegation. Most run on sonnet; migration-agent and lint-agent run on haiku. The model split is the interesting part. Migration and lint work is mechanical and pattern-matched, so the cheap model is a defensible default. Whether haiku writes a reversible migration correctly on your schema is something you have to check on your own data.
Skills live in .claude/skills/ and come in two shapes. Task skills are user-invoked workflows such as code-review (read-only SOLID analysis and N+1 detection) and security-audit (OWASP Top 10 with Brakeman). Knowledge skills are auto-loaded conventions such as rails-architecture, postgres-patterns and caching-strategies. Rules live in .claude/rules/, and 11 of the 14 are path-scoped, meaning they activate based on which file you are editing rather than being injected into every prompt.
That path scoping is the mechanism worth understanding. A rule attached to app/models/ does not consume context while you work in app/views/. The README also mentions a recently added caveman rule with intensity levels for token reduction, which is a direct admission that context budget is a real constraint here. Six lifecycle hooks run at defined points, though the README excerpt does not enumerate them.
Installation is a copy, and the branch you copy decides your stack
There is no gem, no installer and no version pin. The Quick Start is one command:
cp -r .claude/ /path/to/your-rails-app/.claude/
The README gives a table for the variants. The default .claude/ assumes layered architecture, RSpec, Pundit and PostgreSQL. If your team prefers rich models, concerns and Minitest, you copy .claude_37signals/ instead of .claude/, not alongside it. The SDD commands require .specify/ in addition to whichever pack you chose. statusline/ and mcp/sentry_monitor/ are separate optional copies.
Read that table carefully, because it contains a real asymmetry. The README states that .claude_37signals/ is currently a conventions pack (instructions, agents, skills, rules, settings), while the slash-command set documented in the README lives under .claude/commands/. So the 37signals path gets the conventions without the documented command surface. That is not a bug report, it is what the documentation says, and it should shape which pack you pick.
For Codex and Copilot, .claude/ stays canonical. AGENTS.md is the shared instruction file, .agents/skills/ is the mirrored directory, and .github/copilot-instructions.md is the Copilot entrypoint. Because the README notes that Codex skill discovery is unreliable with symlinks, two scripts copy skills and rules into real directories:
scripts/sync_claude_skills_to_codex.sh scripts/sync_claude_rules_to_copilot.sh
Run them after adding, removing or renaming any skill or rule, and restart or reload the chat session if the tool is already running. This is manual synchronization, and it is the most likely place for the repo to drift out of sync with itself.
The SDD kit is a pipeline with a lightweight escape hatch
The spec-driven development kit is the part with the clearest workflow. It runs from specification to implementation through a chain of commands: /feature-spec runs a structured interview and writes a spec with Gherkin scenarios, /feature-spec-review scores that spec and generates missing scenarios, /feature-plan converts it into a TDD implementation plan with PR breakdown, and /feature-tdd-implementation guides Red-Green-Refactor. Two of the agents map onto TDD phases directly: implementation-agent handles the GREEN phase with worktree isolation, and tdd-refactoring-agent handles REFACTOR.
The README also mentions a lightweight mode for bug fixes, which is the right instinct. A four-command pipeline is overhead for a one-line fix, and a kit that only supported the full path would get bypassed within a week.
Two standalone commands are worth singling out because they address failure modes the rest of the pack cannot. /frame-problem reframes vague requests into clear problems, and /prompt-improver scores and rewrites vague prompts. Both are admissions that the input to the pipeline is often the weakest link. /catchup produces a report on a feature branch covering commits, authors, themes and risks since your last contribution, which is a genuinely different job from code generation.
The Sentry namespace follows the same pattern: /sentry:monitor checks for new production errors, /sentry:fix-error launches a background agent in an isolated worktree, /sentry:fix-status lists active fix branches, /sentry:report generates a markdown summary, and /sentry:resolve closes the loop after deployment. The worktree isolation is the design decision that makes the autonomous fix plausible: the agent works somewhere your main checkout is not.
The defaults are opinions, and some of them will be wrong for you
The largest limitation is not technical. It is that this pack encodes one team's stack as the default and treats everything else as a variant. RSpec, Pundit, service objects, SimpleDelegator presenters, ViewComponent, Solid Queue, Turbo, Stimulus and Tailwind all appear as the assumed answer. A shop running Minitest with authorization in the model layer will find that a meaningful share of the 19 agents and 18 skills describe patterns they do not use. Deleting is work, and half-deleted agent packs are worse than none, because the assistant still sees the leftovers.
The second limitation is synchronization. Skills are copied, not linked, into .agents/skills/ for Codex, and rules are generated into .github/instructions/claude-rules/ for Copilot. The README is explicit that you must run the sync scripts after any skill or rule change. Nothing in the supplied material describes an automated check that the mirrors match, so a stale mirror is a plausible failure mode.
The third is verification. The repository is written in Shell and distributed as files. There is no release history in the material provided, no changelog, and no versioning scheme, so upgrading means re-copying and reconciling against your local edits. If you have customized an agent's maxTurns or a rule's scope, a fresh copy will overwrite it. The README does not describe a merge or upgrade path.
Finally, the hooks. Six lifecycle hooks are listed as part of the pack, but the excerpt does not say what they do or when they fire. Treat that as unverified until you read the hook files themselves.
What it is not: this is not a Rails linter or a CI gate
It is worth being precise about the comparison, because the obvious alternative is not another agent pack. It is the tooling that already runs deterministically in your pipeline: RuboCop, Brakeman, and a test suite.
The difference in approach is fundamental. RuboCop and Brakeman produce exit codes. They run the same way on every machine, they fail the build, and they cannot be talked out of a finding. This repository produces instructions that shape what a language model writes before it writes it. The security-audit skill invokes Brakeman, and the lint-agent invokes RuboCop, so the relationship is complementary rather than competing: the pack's value is in reducing how often those tools have something to complain about, and in catching the class of problem linters do not model, such as an N+1 that passes every style check.
If you already have strong CI enforcement and your reviewers catch architectural drift reliably, the marginal gain here is smaller than the README's framing suggests. If your bottleneck is that generated code keeps violating conventions your linters cannot express, the pack targets exactly that gap. Note also that the security-audit and accessibility-review skills run with opus, and accessibility-review depends on external tools (axe-core, Lighthouse or Pa11y) that are not part of this repository.
Licence and maintenance cost
The repository is MIT licensed. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. Because the distribution model is copying files into your application, the practical implication is that the .claude/ directory you copy carries its own provenance separate from your application code, and stripping the notice while redistributing is what the licence prohibits. This is a description of the licence text, not legal advice; check with your own counsel if you plan to redistribute a modified pack.
Maintenance cost is front-loaded and then recurring. Front-loaded: reading 14 rules and 19 agent definitions against your codebase before you copy, because the defaults assume a specific stack. Recurring: re-running scripts/sync_claude_skills_to_codex.sh and scripts/sync_claude_rules_to_copilot.sh whenever skills or rules change, and reconciling any local edits you made to agents or rules when you pull a newer copy. The README states that Codex and Copilot sessions need a restart or reload to pick up changes, which adds a step to every update.
The absence of releases in the supplied material means there is no version number to pin against and no changelog to diff. You are tracking a branch.
Who should copy this in, and what to check first
The fit is narrow and identifiable. You are a Rails team on RSpec, Pundit, PostgreSQL and a layered service-object architecture, already using Claude Code, and your recurring complaint is that generated code ignores your conventions. In that case the default .claude/ pack is close to a drop-in, and the SDD pipeline plus the Sentry worktree commands are the parts with the least equivalent elsewhere.
You should not adopt it if you are on Minitest with rich models, because the default pack fights you and the 37signals alternative does not ship the documented command set. You should also think twice if you have no interest in maintaining two mirrored skill directories for Codex and Copilot, since that mirroring is manual by design.
Before copying, do three things. Read .claude/rules/ and count how many of the 14 rules contradict your codebase; that number is your real integration cost. Read the hook files, since the README excerpt does not describe what the 6 lifecycle hooks do. And confirm whether .claude_37signals/ includes the commands you need, because the README says the documented slash-command set lives under .claude/commands/. If the rules mostly agree and the hooks are inert for your workflow, the copy command is cheap. If the rules mostly disagree, you are better served writing a smaller set of rules that describe your own conventions.
Editorial conclusion
Adopt this if your Rails app already uses RSpec, Pundit, PostgreSQL and a layered service-object architecture, because the shipped agents encode those choices and you will spend more time deleting than adding otherwise. Skip it if you run Minitest with rich domain models and no service layer, unless you are willing to start from .claude_37signals/ and accept that the documented slash-command set lives under .claude/commands/ and does not come with that pack. Before copying anything, read .claude/rules/ to count how many of the 14 rules contradict your codebase, and check whether .claude_37signals/ covers the commands you actually want.
Community notes