mcpField
A
apply-code-conventions

apply-code-conventions

github.com/igmarinDevelopment2845 installsUpdated 4w ago
Repository

About apply-code-conventions

apply-code-conventions is a skill for reviewing and refactoring Rails code. It adds architecture and behavior guidance beyond the configured linter, with test gates, structured logging, and area-specific rules.

Key features

  1. 01Linter-based style guidance
  2. 02Test-first implementation gate
  3. 03Structured logging requirements
  4. 04Path-specific Rails recommendations
  5. 05Links to specialized skills

Use cases

  1. 01Reviewing Rails code changes
  2. 02Refactoring controllers or services
  3. 03Checking logging and TODO comments

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/igmarin/rails-agent-skills --skill apply-code-conventions

After installing, type/apply-code-conventionsin Claude Code to confirm it loaded.

Bundled filesassets/checklist.mdassets/snippets.md

Details

From the project README

Apply Code Conventions

Style source of truth: Style and formatting defer to the project's configured linter(s). This skill adds non-style behavior and architecture guidance only. For Hotwire + Tailwind specifics, see apply-stack-conventions.

Quick Reference

TopicRule
PrinciplesDRY, YAGNI, PORO where it helps, CoC, KISS
Comments / tagsExplain why; tagged notes need actionable context
LoggingOne verified message argument (usually a JSON hash); no interpolation; include a redacted backtrace on errors
Deep stacksChain apply-stack-conventions → domain skills (services, jobs, RSpec)

HARD-GATE

TESTS GATE IMPLEMENTATION:
When this skill guides new behavior, the tests gate still applies:
PRD → TASKS → TEST (write, run, fail) → IMPLEMENTATION → …
No implementation code before a failing test. See write-tests.

Core Process

When reviewing or refactoring Rails code, follow this sequence. Each step maps to a required checkpoint in your output.

  1. Run linter — Detect config (e.g. .rubocop.yml or .standard.yml), run the appropriate tool, note absence if none found. Output: linter detected (or absent); style defers to it.
  2. Apply area-specific rules — Check path patterns and apply targeted guidance from the Apply by area table. Output: concrete per-path recommendations for every relevant changed file.
  3. Verify tests gate — Confirm failing tests exist before any new behavior. Output: failing spec, run command, expected failure, minimal implementation step, passing rerun.
  4. Enforce structured logging — Ensure all Rails.logger calls use the installed logger's verified single-message interface; include an event: field and redacted backtrace for errors. Output: apply structured logging rules from Sub-Rules below.
  5. Enforce comment discipline — Ensure all tags (TODO:, FIXME:) have actionable context (owner, ticket). Output: apply comment discipline rules from Sub-Rules below.
  6. Chain to specialised skills — Use the Integration table to pull in deeper guidance (security, jobs, specs) as needed.

Language: English unless explicitly requested otherwise.

Sub-Rules

Comments and tagged notes

Comment why, not what. Tags — TODO: / FIXME: / HACK: / NOTE: / OPTIMIZE: — must carry actionable context (owner, ticket, next step). Naked tags fail review.

# BAD — naked tag, no context
# TODO: fix this

# GOOD — TODO with next step + dependency
# TODO(jsmith, JIRA-1234): replace TIER_RATES with DB-backed lookup once billing API v2 is stable.
Structured Logging

Use the project's installed logger interface. Standard Ruby/Rails loggers accept one message argument; a two-argument structured call requires a verified custom adapter. Log once at the recovery boundary, redact sensitive data, and preserve unexpected exceptions.

rescue Timeout::Error => e
  Rails.logger.error({ event: "order.processing_failed", error_class: e.class.name, backtrace: e.backtrace&.first(5) }.to_json)
  raise
end
Apply by area (path patterns)
AreaPath patternGuidance
ActiveRecord performanceapp/models/**/*.rbEager load in loops; prefer pluck / exists? / find_each.
Controllersapp/controllers/**/*_controller.rbStrong params; thin actions → services; IDOR / PII → security-check.
RSpecspec/**/*_spec.rbFactoryBot; let > let! unless eager setup required.
Service objectsapp/services/**/*.rbSingle responsibility; .call / injected deps.
Background jobsapp/jobs/**/*.rb / app/workers/**/*.rbIdempotency, retries, queue choice, and side-effect boundaries → implement-background-job.
RSpec and let_it_be (test-prof)

Only recommend let_it_be if test-prof is already in Gemfile.lock. Otherwise default to let; reach for let! only when lazy evaluation would break the example. Don't introduce test-prof unless asked.

Extended Resources (Progressive Disclosure)

Load these files only when their specific content is needed:

Document which assets were loaded and why in your output so the process is verifiable.

Integration

SkillWhen to chain
apply-stack-conventionsStack-specific: PostgreSQL, Hotwire, Tailwind
model-domainWhen domain concepts and invariants need clearer Rails-first modeling choices
create-service-objectImplementing or refining service objects
implement-background-jobWorkers, queues, retries, idempotency
write-testsSpec style, tests gate (red/green/refactor), request vs controller specs
security-checkControllers, params, IDOR, PII
code-reviewFull PR pass before merge

Comments

Markdown supported