Converts a Rock RMS WebForms block (.ascx/.ascx.cs) to Obsidian (Vue 3 + C# RockBlockType). Triggers on: "convert block", "migrate block to obsidian", "obsidian conversion", or a WebForms block path like "RockWeb/Blocks/Core/Foo.ascx.cs" with conversion intent. Also handles attached Figma design URLs (translation + redesign) and net-new feature scope ("add inline comments", "also support drag-to-reorder", etc.) when the user describes them alongside the conversion target. Produces a `/working/{block}/` research workspace, classifies the block as Detail/List/Custom, generates the C# block + bags + .d.ts placeholders + Vue SFC + partials, chops the WebForms files, and offers to archive the research as a frozen spec once `/review-conversion` passes. Do NOT use for non-block tasks, creating new blocks from scratch, or general Rock RMS questions.
Reviews a completed Rock RMS Obsidian block conversion for bugs, missing logic, redundant code, and pattern violations. Primary input is the /working/{block-name-kebab}/ research folder produced by /convert-block — review verifies code against the documented spec and writes verdicts back into each artifact. The WebForms .ascx.cs is ground truth for spec-gap detection (catches what convert-block missed). When /working/ is absent (post-archive scenario), falls back to a fresh-eye audit against WebForms only. Use when the user says "review conversion", "review block", "review obsidian block", "check the conversion", "compare to webforms", "audit the block", or asks to verify a converted block before merging. Use after all conversion files are written. Do NOT use for: incomplete conversions, non-conversion code review, or general Rock RMS questions.
Author or complete a spec document in the repo's `specs/` directory. Specs capture requirements and architecture decisions BEFORE coding, or document a known issue (problem, root cause, proposed fix) for review. Use when the user says "write a spec", "create a spec", "spec this out", "draft a spec for X", "document the design for Y", or asks for a written decision record/RFC. Also use when the user wants to formalize the analysis of a bug or regression before applying the fix. ALSO use when the user says "complete this spec", "mark spec as done", "the X spec is finished", "archive this spec", or similar — the skill will move the file into `specs/completed/{Domain}/` and update `specs/completed/INDEX.md`. ALSO use when the user says "reject this spec", "won't fix", "won't do", "mark spec as rejected", "abandon this spec", or similar — the skill will capture a rejection reason, append a Rejection section to the spec, move the file into `specs/rejected/{Domain}/`, and update `specs/rejected/INDEX.md`. Do NOT use
Audit the current session for things worth saving to auto-memory and present them as a plan-mode draft for explicit user approval before writing. Also identifies bubble-up candidates — rules that arguably belong in team-shared memory (CLAUDE.md or .claude/rules/) instead of private auto-memory — and surfaces them as suggestions without writing them. Use when the user says "remember", "/remember", "save what we learned", "capture this session", or wants a deliberate retrospective pass on a long session before context fades. Reads MEMORY.md plus every individual memory file first to dedupe; classifies each candidate as user / feedback / project / reference; drafts full bodies; awaits ExitPlanMode approval before writing anything. Do NOT use for: editing CLAUDE.md (that is the /memory slash command's job), saving session-specific task state (memory is for cross-session learning), or recording git history or code patterns that are derivable from the repo.
Author or update technical documentation in the repo's `docs/` directory. Docs are the living "as built" reference for how Rock currently works, organized by Rock domain (`docs/core/`, `docs/lava/`, `docs/group/`, etc.). Audience is core developers and quasi-technical community members. Use when the user says "write docs for X", "document this feature", "update the docs", "how is X documented", "audit the docs", or describes a feature/subsystem they want a written reference for. Also use when the spec skill hands off after completing a spec, or when the commit skill detects that changed files are referenced in some doc's frontmatter. Do NOT use for: writing end-user tutorials or how-to guides (different audience), generating API reference (separate tool), writing release notes, drafting RFCs or proposals (those are specs).
Generate safe, correct SQL scripts for the Rock RMS database. Handles INSERT, UPDATE, DELETE, SELECT queries, data migrations, and seed scripts that respect Rock's schema conventions (PersonAlias, audit columns, FK constraints, DefinedType/DefinedValue lookups, Guid-based references). Use when the user says "create a sql script", "write sql", "insert data", "seed data", "data migration", "update records", "sql for Rock", "populate data", "add test data", "query Rock database", or any request involving direct SQL against the Rock RMS database. Also use when the user describes data they want to add, modify, or query in Rock — even if they don't explicitly say "SQL" — such as "add 100 attendance records", "create a new campus", "give Ted Decker some financial transactions", or "set up check-in data". If the task involves Rock database records and SQL is the right tool, use this skill.
Orchestrate a git commit for Rock RMS. Runs two pre-commit checks before handing off to the standard git commit flow: (1) detect active specs in `specs/` that look related to the change and offer to mark them complete after the commit lands; (2) ask whether the change belongs in the release notes and draft a Rock-formatted message accordingly (`+ (Domain) Fixed/Added/Improved/Updated ...` for release-note commits, `- ...` for minor commits). Use when the user says "commit", "commit this", "commit my changes", "create a commit", "make a commit", or invokes `/commit`. Do NOT use for: viewing commit history, amending an existing commit, force-pushing, or generating messages for code that has not been written yet.
Fix a known bug in the Rock RMS codebase. Guides Claude through root cause analysis, minimal correct fix, and a release-note commit message. Use when the user says "fix this bug", "bugfix", "this is broken", "debug this", describes a bug with file paths or issue numbers, or pastes an error/stack trace with intent to fix. Also use when a bug is found by another skill (e.g. /review-conversion, /check) and the user wants it fixed. Do NOT use for: finding bugs (use /check or /review-conversion), adding features, or refactoring.