Claude Skills by mik2win

Run a PostgreSQL production-readiness checklist against the current schema, database config, and connection settings, reporting pass/fail with remediation. TRIGGER when the user wants to vet Postgres for production, audit schema/indexes/constraints/connection-pool/backup settings, or asks "is the database production-ready". Do NOT trigger for general code review (use code-review) or query-level tuning (use performance-audit).

Worked SQL/DDL examples for PostgreSQL conventions — data types, indexing (B-tree/GIN/ GiST/BRIN), constraints, queries, EXPLAIN, JSON/arrays, and Rails-specific patterns. CONSULT when writing migrations, schema, or SQL and you need the idiomatic example or an index/constraint pattern. Reference loaded on demand — the always-apply rules live in the `postgresql-universal` and `postgresql-rails` rules.

Structured code review of changed or specified files against project conventions, OOP principles, security, and performance. TRIGGER when the user asks to review changes, a PR, a branch, a diff, staged work, or named files ("review my changes", "code review this PR", "check this branch"). Do NOT trigger when the user only wants to understand how code works (exploration, not review).

Worked GOOD/BAD examples for this project's Ruby/Rails conventions plus the optional architectural patterns — value objects, query objects, form objects, custom validators, and focused concerns. CONSULT when you need an idiomatic Rails example (model structure order, service patterns, thin controllers, routing, jobs, migrations) or when introducing a value/query/form object, a custom validator, or a concern. This is reference loaded on demand — the always-apply rules themselves live in the `r...

Worked RSpec examples for this project's testing conventions — describe/context/it structure, subject/let, FactoryBot, verified doubles, matchers, and coverage patterns. CONSULT when writing or reviewing specs and you need the idiomatic example. Reference loaded on demand — the always-apply rules live in the `rspec-testing` rule.

Worked view-layer examples for this project's UI/UX conventions — templates, partials, ViewComponents, helpers, forms, and Hotwire/Stimulus patterns. CONSULT when building or reviewing views/components/helpers and you need the idiomatic example. Reference loaded on demand — the always-apply rules live in the `ui-ux` rule.

Generate RSpec tests for a Rails class following project BDD conventions (FactoryBot, Shoulda Matchers, verified doubles, comprehensive coverage). TRIGGER when the user wants tests written/generated for a Rails model, service, controller, or request. Do NOT trigger to run an existing suite or to debug a specific failure (use diagnose).

Structured code review of changed or specified files against project conventions, OOP principles, security, and performance. TRIGGER when the user asks to review changes, a PR, a branch, a diff, staged work, or named files ("review my changes", "code review this PR", "check this branch"). Do NOT trigger when the user only wants to understand how code works (exploration, not review).

Generate a Rails migration with zero-downtime patterns, correct PostgreSQL types, proper indexes, and foreign-key constraints. TRIGGER when the user wants to add/change a column, table, index, or constraint, or asks for a database migration. Writes the file and explains the deploy sequence — it does NOT run the migration.

Scaffold a service, form, policy, value, or query object following project patterns, structure, and naming. TRIGGER when the user wants to extract business logic into a service/command object or create a form/policy/value/query object. Does NOT modify existing app code beyond the new object.

Worked examples for building LLM/agent features in Ruby — prompt construction, tool/ function calling, structured output, retries/guardrails, token handling, and testing. CONSULT when implementing or reviewing agent/LLM code (files matching *agent*/*llm* or config/prompts) and you need the idiomatic example. Reference loaded on demand — the always-apply rules live in the `llm-agent-practices` rule.

Audit Rails code for N+1 queries, missing indexes, caching opportunities, inefficient queries, and PostgreSQL anti-patterns. TRIGGER when the user reports slowness or wants a performance pass over models/queries/controllers. Do NOT trigger for correctness bugs (use code-review) or production-readiness config (use pg-checklist).

Run a PostgreSQL production-readiness checklist against the current schema, database config, and connection settings, reporting pass/fail with remediation. TRIGGER when the user wants to vet Postgres for production, audit schema/indexes/constraints/connection-pool/backup settings, or asks "is the database production-ready". Do NOT trigger for general code review (use code-review) or query-level tuning (use performance-audit).

Worked code examples for this project's Rails layer conventions — models, ActiveRecord queries, database/migrations, controllers & routing, business logic (services/forms/ policies), background jobs, caching & storage, and security. CONSULT when implementing or reviewing a Rails layer and you need the idiomatic example (model structure, N+1 fixes, service patterns, thin controllers, idempotent jobs, caching, strong params/SQL safety). Reference loaded on demand — the always-apply rules live i...

Worked RSpec examples for this project's testing conventions — describe/context/it structure, subject/let, FactoryBot, verified doubles, matchers, and coverage patterns. CONSULT when writing or reviewing specs and you need the idiomatic example. Reference loaded on demand — the always-apply rules live in the `rspec-testing` rule.

Worked GOOD/BAD examples for Ruby style and OOP conventions — naming, idioms, safe navigation, freeze, SRP, dependency injection, Tell-Don't-Ask, Law of Demeter, duck typing, composition over inheritance. CONSULT when you need an idiomatic Ruby example or are unsure how a style/OOP rule looks in code. Reference loaded on demand — the always-apply rules themselves live in the `ruby-style` and `ruby-oop` rules.

Reference for idiomatic Ruby standard-library usage — Enumerable patterns, blocks/procs/lambdas, hash/array/Set/Range idioms, File/IO, freeze patterns, Comparable/Enumerable mixins, and stdlib logging. CONSULT when writing or reviewing Ruby and unsure which stdlib tool or idiom fits — choosing between map / each_with_object / filter_map / tally, Set vs Array, block vs lambda vs proc, dig/fetch, ranges, execute-around, or frozen-string patterns. This is reference knowledge loaded on demand, no...

Audit Rails application code against the OWASP Top 10 — SQL injection, XSS, CSRF, mass assignment, and credential exposure. TRIGGER when the user wants a security review of Rails code or asks about injection/XSS/auth/secret-handling risks. Complements the built-in /security-review.

Generate RSpec tests for a Ruby class or module following project BDD conventions (verified doubles, comprehensive coverage). TRIGGER when the user wants tests written/generated for a Ruby class or module. Do NOT trigger to run an existing suite or to debug a specific failure (use diagnose).

Interactive requirements gathering and specification writing — acts as a senior business analyst plus system analyst. Runs an interview (one question at a time), clarifies scope, challenges assumptions, grounds in the codebase, then writes a spec to the project's plans location. Answers WHAT and WHY, not HOW. TRIGGER when: the user wants to analyze/plan a feature, gather requirements, design something new, or work out a still-vague idea ("analyze feature", "gather requirements", "let's plan",...

Design a public contract (HTTP/REST, RPC, webhook, CLI, or library API) before building it — consumers & compatibility promise first, resource model in the domain language, the contract checklist (error model, pagination, idempotency, partial updates, versioning), worked request/response examples including errors, and a consumer's-eyes review pass. TRIGGER when: designing or extending an API/endpoint/webhook/CLI surface or a library's public interface — "design the API", "какой сделать контра...

Proactive whole-codebase architecture scan — find shallow modules, leaky interfaces, misplaced seams, layer violations, and ball-of-mud hotspots; present them as a RANKED report; then grill through the one you pick and route it to /refactor or /prepare. Run it every few days to keep entropy in check, before the codebase becomes hard to change. Distinct from /refactor (cleans the current diff on demand) — this scans the whole tree and surfaces what to clean. TRIGGER when: the user wants an arc...

Scoped architectural quality audit of a module or changeset — classifies each file SOUND / SHORTCUT / HACK against THIS codebase's own architecture, with the architecturally correct alternative, fix effort, and blocking status, then hands back a phased refactor plan. Read-only: it never edits code. TRIGGER when: the user asks whether code is a hack or architecturally sound, wants a quality or architecture audit of a module/directory/changeset, says code "works but feels wrong", asks what the ...

Orchestrating security audit — an OWASP-style sweep that ties together the project's security rule, the built-in /security-review, the security-reviewer agent, and /deps into one risk-tiered report with a deploy verdict. Covers secrets, injection (command/SQL/path), authorization, unsafe deserialization, and dependency trust. TRIGGER when: the user wants a security audit before a deploy, after adding an external integration or user-input surface, or as a periodic security review of the codeba...

Adapt the feature-flow kit to THIS project — the front door for setting it up. Run on the FIRST install after dropping the kit into a project's .claude/ folder: detects the stack, writes the project profile (.claude/PROJECT.md), installs and reconciles stack rule packs against the real codebase, wires settings/hooks/commands, and writes the kit manifest. Backs up before writing and asks keep-or-rollback before cleaning up build-time files. On a project that's ALREADY adapted (profile_status: ...

Whole-codebase cruft-removal sweep — find and DELETE dead code, unused symbols and files, legacy/back-compat shims, YAGNI abstractions, stale TODOs, and commented-out code. Every deletion is backed by a Proof-of-Deadness evidence checklist and gated by batched user confirmation, then verified via format + test. TRIGGER when: the user wants to "clean up the codebase", "remove dead code", "delete unused stuff", "strip legacy shims", a post-refactor lean-down, or a periodic MVP-discipline sweep....

Terminal epic-close checklist over a wave-structured decomposition (one epic = one <backlog>/<task-name>/ directory from /prepare Phase 6): verify every plan is terminal, execute the epic's declared E2E-verify block plus ONE integration test pass, run plan↔code conformance on deviated plans, detect docs drift the epic caused and fix small documentation debt inline, price every remaining finding (default: a named known-undone clause, NOT a card), promote only the survivors into a runnable foll...

Structured review of changed or specified code against this project's rules, plus real correctness/security/performance problems. TRIGGER when: the user asks to review changes, a PR, a branch, a diff, staged work, or named files ("review my changes", "code review this PR", "check this branch", "review the diff"). DO NOT TRIGGER when: the user only wants to understand how code works or learn a flow (exploration/explanation, not review).

Shared vocabulary and discipline for designing deep modules — a lot of behaviour behind a small interface, placed at a clean seam, testable through that interface. The design lens the kit's planning and quality skills reach for. TRIGGER when: the user wants to design or improve a module's interface, decide where a seam goes, make code more testable or AI-navigable, weigh two designs, OR another skill (/prepare, /tdd, /refactor, /arch-health) needs the deep-module vocabulary. DO NOT TRIGGER wh...

Service-architecture decision discipline — decide monolith vs modular monolith vs extracting a service, per candidate boundary, on evidence: real extraction drivers (deploy contention, asymmetric scaling, failure isolation, team ownership) weighed against the distributed tax, with "extract the seam before the service" as the governing rule. Verdict per boundary: STAY / MODULARIZE / EXTRACT, recorded as an ADR and routed to the right executor. TRIGGER when: the user asks "should we split this ...

Pick the cheapest sufficient deploy command for what actually changed — classify the working tree against the project's Deploy mapping, name the command and what it costs, and hand it over as text the user runs. Includes the "no deploy needed" branch and a post-deploy verification checklist. Never executes anything. TRIGGER when: the user asks how to deploy / push / ship this change, which deploy command to run, whether a change needs a deploy at all, or wants the deploy step after work has l...

Dependency & vulnerability hygiene — run the stack's vulnerability audit, summarize findings by severity, and propose pinning + a safe upgrade path. Reads the package manager and audit command from PROJECT.md; never auto-upgrades or commits. TRIGGER when: the user wants to audit dependencies, check for vulnerable/outdated packages, run `npm audit`/`bundler-audit`/`pip-audit`/`cargo audit`, or plan a safe dependency upgrade. DO NOT TRIGGER when: the user wants a code-level security review of t...

Root-cause debugging workflow — reproduce, isolate, root-cause, fix, verify. TRIGGER when: the user reports a bug, failure, crash, test failure, or unexpected/incorrect behavior and wants to know WHY it happens and how to fix it. TRIGGER ALSO on a bare failure report with no request attached — a pasted traceback, a failing test name, "X is broken", a screenshot of wrong output: the report IS the request. DO NOT TRIGGER when: the failure is live in production and harming users right now — use ...

Feature research & ideation — frame a request, find prior art and reuse candidates in the repo (and optionally the web), then write a short feature brief and route onward. Read-only on app code; no spec, no plan, no implementation. TRIGGER when the user wants to research a feature, find prior art, check "what already exists for X", scope a fuzzy idea, or hunt for reuse before committing to a design ("research this", "what's already there", "how do we usually do X", "is there anything we can r...

Pattern mining — surface the codebase's recurring implicit conventions (error handling, construction, data access, naming, test shape…), verdict each as BLESS / UNIFY / BAN / DEEPEN with cited occurrences, then install the verdicts where agents actually read them: project rules, CONTEXT.md, reference examples. Makes the implicit explicit so generated code copies the best pattern in the repo instead of the most frequent one. TRIGGER when: the user wants to extract/codify the codebase's convent...

Build and sharpen the project's LIVING domain model — a ubiquitous-language glossary (CONTEXT.md) plus architectural decision records (docs/adr/). Actively challenge fuzzy terms, stress-test relationships with edge-case scenarios, cross-check against code, and write the glossary and decisions down the moment they crystallize. A shared language makes the agent terse, names code consistently, and is easier to navigate next session. TRIGGER when: the user wants to pin down terminology / a ubiqui...

Read-only progress dashboard over a wave-structured decomposition (one epic = one <backlog>/<task-name>/ directory from /prepare Phase 6): which subtasks are done/in-progress/blocked, which wave is current, the next safe wave to launch (all Deps merged, Owns pairwise disjoint), what can launch in parallel right now, and whether running parallel sessions collide on ownership. Where a parent RUN-ORDER exists it is read as the execution truth and reported against plan frontmatter as drift. Repor...

A relentless grilling session that ALSO builds the project's shared language as you go — runs the /grill interview while /domain-model captures crystallizing terms into CONTEXT.md and decisions into ADRs, inline. You leave aligned AND with the glossary/decisions written down, so the next session is terser and the codebase gets named consistently. TRIGGER when: the user wants to stress-test a design AND pin down its terminology/decisions — "grill me and document it", "grill with docs", alignin...

Relentless one-question-at-a-time interview that stress-tests a plan or design until every branch of the decision tree is resolved and you and the user share one understanding. The reusable alignment primitive the pipeline leans on (analyst wraps it, arch-health runs it, prepare/spike apply it) and a standalone way to interrogate any plan before building. TRIGGER when: the user wants to pressure-test a plan/design, says "grill me" / "interview me" / "poke holes in this" / "what am I missing",...

Snapshot the live session state into a resume doc at the project's plans/backlog location so a fresh session (or another developer) can pick the work up without re-deriving context: what's done, what's next, key decisions, modified files, and how to verify. Complements the deviation report /implement writes. TRIGGER when the user wants to hand off / pause / checkpoint work, save progress for later, or prep a resume note before a context reset ("handoff", "save state", "checkpoint this", "I'll...

The plain-language front door to the pipeline — for a user who describes an outcome ("I want it so that…") and should get what a top-tier senior developer would build. Elicits the wish in outcome scenarios (no jargon), presents 2–3 solution shapes with felt trade-offs and a recommendation, then drives the full pipeline (analyst → prepare → implement → verify) itself — making every technical decision, logging it, and reporting back in behavior terms with confirmation at each stage. TRIGGER whe...

Execute a prepared plan or subtask file with quality gates. Reads the plan, builds a verbatim step ledger, implements each step with real-time deviation tracking, routes every finding (adapt / fix-and-log / file-as-card / STOP), spawns an audit subagent (counter-bias), runs tests, drives its slice of the epic's E2E block, and ends with a MANDATORY formatted report (Changes, Architecture Audit, Deviation Report, Cross-Session / Out-of-Scope Findings, Test Results, Commit Message). TRIGGER when...

Production incident discipline — stabilize first, understand later: triage severity and blast radius, mitigate with known-good states (rollback / flag off / failover), preserve evidence before it's destroyed, verify recovery by user-visible signal, then hand root-cause to /diagnose and feed the post-incident review. TRIGGER when: something is broken in production/live for real users RIGHT NOW — an outage, error spike, data corruption in progress, degraded service, a bad deploy — and the prior...

Fast comprehension of an unfamiliar codebase — surface scan, run-it-first, one traced end-to-end flow, git-history archaeology (churn hotspots, bus factor, the oldest untouched code), seams & boundaries, load-bearing weirdness list — into a written orientation map. TRIGGER when: joining/inheriting an unfamiliar repo, "разберись в этом проекте", "how does this codebase work", "map this project", before the first real task in a codebase nobody has profiled yet. DO NOT TRIGGER when: researching ...

Measurement-first performance work — define the budget and metric, measure a reproducible baseline, profile to find the REAL hotspot, fix the biggest lever first (algorithmic > batching/caching > micro), re-measure after every single change, stop at the budget. TRIGGER when: something is slow, memory-hungry, or the user wants it faster/cheaper ("optimize", "why is this slow", "speed this up", "reduce latency/memory"). DO NOT TRIGGER when: it's a correctness bug that happens to involve time (t...

Release-readiness gate — one orchestrated pass before code ships: full test suite + lint/typecheck, dependency & security quick pass, docs drift, config/migration/flag check, changelog draft from commits, and a GO / GO-WITH-RISKS / NO-GO verdict with a suggested deploy command (never executed). TRIGGER when: the user is about to ship/release/deploy/tag ("are we ready to ship", "preflight", "release check", "can this go out"). TRIGGER ALSO on the same ask phrased as plain work, with this skill...

Pre-implementation analysis — strategic brainstorm, impact mapping, SOLID extension checks, DRY reuse discovery, complexity tiering, and (for complex work) decomposition into an atomic, parallel-safe backlog. TRIGGER when the user wants pre-implementation analysis/decomposition before coding ("prepare", "analyze before building", "think through this", "decompose this task", "plan the work"). DO NOT TRIGGER when: the user already has a clear plan and just wants to build it → use /implement; th...

Compile a raw idea (feature, refactor, migration, bug hunt, research) into a sequenced pack of copy-paste-ready prompts for Opus/Sonnet-class models — one prompt per development phase (research → spec → plan → implement → verify), each self-contained, grounded in the project's real facts, and chained through artifact files so the methodology survives fresh sessions and less self-driving models. TRIGGER when: the user wants prompts to run later or elsewhere ("generate prompts for this idea", "...

Build a THROWAWAY prototype to flesh out a design before committing to it — either a runnable terminal/script app to explore state & business-logic questions, or several radically different UI variations toggleable from one route to compare looks and flows. The product is a learning, not shippable code. Distinct from /spike (validates ONE binary hypothesis) — prototype EXPLORES a design space with multiple options. TRIGGER when: the user wants to explore how a feature should look or behave, c...

Clean up and improve already-written code — simplification, reuse/DRY extraction, efficiency, language modernization, and architecture/layer hygiene. QUALITY-ONLY: this skill does NOT hunt for correctness bugs — use /code-review for that. It applies edits then verifies via format + test. TRIGGER when: the user wants to tidy, simplify, modernize, de-duplicate, or make changed code more reusable or efficient. DO NOT TRIGGER when: the user wants to hunt correctness/security/crash bugs (use /code...