Scaffold Project-Specific Skills

The generic rails-skills pack teaches an agent how senior Rails devs write Rails. It cannot know your product — your tenant isolation rules, your booking/payment workflow, your test-and-verify loop. This skill closes that gap: it interviews your app and generates local, project-specific skills that live in your repo and become the source of truth. Use the generic pack as the baseline; use the skills this generates as the authority.

Why this matters

A general Rails pack steers toward generic "best practice." But your hard parts are domain-specific: which models are tenant-scoped, what a valid Offer looks like, how a draft gets accepted, what your team's verification loop actually is (e.g. inspect → implement → Playwright, not RSpec-first). When those rules live only in people's heads, every AI agent re-derives them — and gets them subtly wrong.

The fix is local skills: small, product-aware SKILL.md files in your own .claude/skills/ that encode the conventions that matter to your launch. This skill scaffolds them from an interview + a codebase scan, so you start from a real draft instead of a blank file.

The opinion

Keep project-specific skills in your own repo as the source of truth; let the generic pack be the fallback. Generate them from the actual codebase, not a wish-list. One skill per bounded product area (tenancy, a domain workflow, your verification loop) — small and high-signal beats one giant "conventions" file. Encode rules an agent can act on, and prefer a checker (test, lint, gate) over prose wherever a rule can exit 0/1.

Counter-position: some teams put everything in a single root CLAUDE.md. That works for a while, but as one file grows, per-rule attention tends to degrade — the agent honors the top and bottom more reliably than the middle. Splitting into description-gated skills (so only the relevant rules load per task) is more dependable than relying on one long instruction file, regardless of its exact length.

The interview

Ask these in groups. Skip anything already answered or obvious from the codebase. If the user says "just scan and draft", infer from the repo and present drafts for correction.