Curated library of AI agent skills for Ruby on Rails development. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and workflow automation.
98
99%
Does it follow best practices?
Impact
98%
1.38xAverage score across 26 eval scenarios
Passed
No known issues
Task 0.0 is ALWAYS "Create feature branch" unless user explicitly says otherwise.
Each sub-task MUST be a single, clear action completable in 2-5 minutes.
Sub-tasks MUST include exact file paths, not vague references.
TESTS GATE IMPLEMENTATION — structure sub-tasks as:
a) "Write spec for X" (with exact file path)
b) "Run spec — verify it fails because X does not exist yet"
c) "Implement X to pass spec" (with exact file path)
d) "Run spec — verify it passes"
OUTPUT MODE:
If the user asks for strategy, sequencing, phases, or approach, produce a phased plan first.
If the user asks for implementation tasks, checklist, or exact steps, produce the detailed mode.
POST-IMPLEMENTATION GATE (add as explicit parent tasks after tests pass):
Every task list touching production code MUST end with:
1. YARD — name each file to document (skill: yard-documentation)
2. Documentation — update README, diagrams (Mermaid, ADRs), domain docs; list concrete paths
3. Code review — self-review via rails-code-review; fix blockers before opening PRbundle exec rspec or npm test).tasks-[feature-name].md in /tasks/. Use the same [feature-name] as the PRD if one was provided.0.0 creates the feature branchRelevant Files section is presentSee HEURISTICS.md for the full change-type → first-slice mapping table.
See TASK_TEMPLATES.md for full templates. A typical task block looks like:
- [ ] 1.0 Parent task title
- [ ] 1.1a Write spec for `ServiceName` at `spec/services/module/service_name_spec.rb`
- [ ] 1.1b Run spec — verify it fails: `bundle exec rspec spec/services/module/service_name_spec.rb`
- [ ] 1.1c Implement `ServiceName` at `app/services/module/service_name.rb`
- [ ] 1.1d Run spec — verify it passes| Problem | Correct approach |
|---|---|
| Dependencies out of order | A task must never reference something created in a later task |
| No README/diagram/doc paths when integrators need updates | List concrete doc paths in Relevant Files |
| Skill | When to chain |
|---|---|
| create-prd | Generate PRD first, then derive tasks from it |
| rails-tdd-slices | When planning the best first failing spec for a Rails change |
| ticket-planning | When the same initiative also needs Jira ticket drafts |
| rails-bug-triage | When the request starts from a bug report |
api-rest-collection
create-prd
ddd-boundaries-review
ddd-rails-modeling
ddd-ubiquitous-language
docs
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
scenario-19
scenario-20
scenario-21
scenario-22
scenario-23
scenario-24
scenario-25
scenario-26
generate-tasks
mcp_server
rails-architecture-review
rails-background-jobs
rails-bug-triage
rails-code-conventions
rails-code-review
rails-engine-compatibility
rails-engine-docs
rails-engine-extraction
rails-engine-installers
rails-engine-release
rails-engine-reviewer
rails-engine-testing
rails-graphql-best-practices
rails-migration-safety
rails-review-response
rails-security-review
rails-skills-orchestrator
rails-stack-conventions
rails-tdd-slices
refactor-safely
rspec-best-practices
rspec-service-testing
ruby-service-objects
strategy-factory-null-calculator
ticket-planning
yard-documentation