Explore AI Agent Skills & Claude Prompts

Complete code quality loop for Rails projects with hard gates: enforce naming conventions and linter compliance (rubocop/brakeman/erblint must pass) → refactor only after characterization tests PASS on current code, verify behavior preserved after each extraction → generate YARD docstrings for all public APIs → NEVER open PR before linter, ERB linter, full test suite, security scan, and YARD docs all pass; phases conventions review→refactoring→documentation. Use this composite end-to-end loop instead of individual refactoring or documentation skills when full three-phase production-readiness review is needed in one pass. Trigger: code review prep, before PR, full Rails quality sweep, quality audit, production-ready review, end-to-end quality check.

schedule Updated 22 days ago

refactor-code

Use when refactoring Rails code to change structure without changing behavior — must write characterization tests and verify they pass on the current code BEFORE touching any production files, identify inputs/outputs keeping public interfaces stable, run verification after every step and the full suite at the end, and include a Stable behavior statement and Verification evidence showing actual command output under the Observed output label. Trigger words: refactor, restructure, extract service, split class, reduce duplication.

code-review

Reviews Rails (Ruby on Rails) pull requests, diffs, and merge requests for quality, security, and conventions. Use when asked to do a PR review, review my diff, review my merge request, or code review of Ruby on Rails code. Grounds every finding in a real file:line from the actual diff, applies exactly three severity labels (Critical, Suggestion, Nice to have) where Critical covers security/data loss/crash and Always Critical flags (permit!, html_safe on user-supplied content, business logic in controllers, unparameterized SQL, destructive migrations), and always includes a "Code review before merge" task line. Follows the principle: review early, review often; self-review before PR; re-review after significant changes.

apply-stack-conventions

Use when writing new Rails code (Ruby on Rails) for the PostgreSQL + Hotwire + Tailwind stack, including TDD (test-driven development), write-tests-first, or red-green-refactor workflows — must write specs and validate them RED BEFORE implementation, verify they pass GREEN after, show spec file content (not just spec path), include a Tests-first proof before implementation section showing actual spec code, the run command (bundle exec rspec spec/[path]_spec.rb), and the Observed RED output and Observed GREEN output labels, keeping steps testable in isolation. MVC structure, ActiveRecord queries, Turbo Frames/Streams, Stimulus controllers, and Tailwind patterns. Not for general Rails design principles — scoped to this specific stack.

implement-graphql

Use when building or reviewing GraphQL APIs in Rails with graphql-ruby — must follow the TDD gates by writing a failing spec in spec/graphql/ using AppSchema.execute rather than HTTP controller dispatch, define arguments/return types without leaking internal model names (use connection_type for pagination), implement resolver/mutation classes that delegate to services, prevent N+1 queries by using and priming the dataloader on association loads, and ensure mutations return result and errors shapes on failure. Trigger words: graphql, graphql-ruby, resolver, mutation, dataloader, schema.

schedule Updated 23 days ago

write-tests

Use when writing, reviewing, or configuring RSpec tests in Ruby on Rails — must execute the spec via `bundle exec rspec` and capture the actual test output (failure message or stack trace) rather than describing expected behavior, prefer behavioral confidence over implementation coupling, pick the smallest spec type exercising the behavior (model > service > request > system), mirror the file paths of the source, use # frozen_string_literal: true, define subject(:result) for service specs, and consult `assets/tdd_proof_checklist.md` when the task involves new behavior. Use when adding test coverage, refactoring specs, or practicing TDD. Trigger words: write spec, rspec, test-driven development, testing, write tests.

rails-agent-skills

Entry point for Rails development workflows covering TDD, RSpec, Service Objects, DDD, GraphQL, Engines, and Code Quality. Use when the user asks about Ruby on Rails development patterns, needs RSpec test suites generated, wants service objects scaffolded, is setting up GraphQL schemas, performing Rails code review, refactoring .rb files, working with domain-driven design, implementing background jobs, conducting Rails security checks, or building Rails engines. Generates RSpec tests, structures service objects, enforces TDD workflows, configures GraphQL schemas, and coordinates domain-driven design patterns. Trigger keywords: Rails, RSpec, TDD, Rails testing, Rails refactor, Rails API, Rails code review, domain driven design, service objects, GraphQL, Rails engine, Ruby, .rb, background jobs, Rails migrations, Rails security check.

schedule Updated 13 days ago

tdd

Orchestrates the full Rails TDD cycle with hard gates: test MUST exist, be run, and FAIL for the correct reason (e.g. undefined method, not syntax error) before any implementation code — propose minimal implementation and wait for user approval → verify test PASSES → run full suite with rubocop, brakeman, rspec all green → produce YARD documentation and self-reviewed PR; phases context/test design→implementation→iterate→finish. Use when practicing test-driven development, red-green-refactor, TDD workflow, writing tests before code, adding tests first, or building a Rails feature where specs must gate implementation.

implement-hotwire

Use when creating Hotwire UIs with progressive enhancement in Rails — generates Stimulus controllers, Turbo Frame markup, Turbo Stream responses, and ActionCable broadcast setups, then verifies degraded mode by disabling JavaScript (or running rails test:system with Capybara rack_test driver) and confirming forms submit, links navigate, and data persists after reload. Includes a Verification section with explicit no-JavaScript checks. Stimulus, Turbo, Turbo Frames, Turbo Streams.

agnostic-planning-skills

star 0

Master orchestrator for the Agnostic Planning Skills library. Use to discover and activate 11 language-agnostic skills and 4 personas for product planning, task breakdown, estimation, risk assessment, ticket generation, backlog prioritization, sprint planning, retrospectives, requirements clarification, and status reporting. Personas guide end-to-end workflows. prd, planning, tasks, tickets, estimation, risks, status, backlog, sprint, retrospective, tdd, agile, product management, requirements, clarification.

schedule Updated 13 days ago

requirements-clarifier

star 0

Transforms vague task descriptions into actionable specifications with user stories acceptance criteria and identified edge cases — NEVER write implementation code or suggest solutions, do NOT edit files, do NOT produce configuration or test cases, produce requirements only. Language-agnostic. Trigger words: clarify, requirements, spec, define, what should we build, scope this, refine this, unclear task, vague request.

schedule Updated 23 days ago

estimate-tasks

star 0

Assigns relative effort estimates using story points (Fibonacci) t-shirt sizes or time ranges — never mix frameworks within a single table, include confidence level per task, use table format with ID Task Estimate Confidence Notes, and flag high-uncertainty items. Language-agnostic. Use when the user asks to estimate effort, size tasks, or assign story points to backlog items. Trigger words: estimate, story points, t-shirt size, effort, sizing, fibonacci.