mik2win
UserA disciplined feature pipeline for Claude Code — drop it into any repo's .claude/, run /bootstrap, and get discovery → spec → plan → code.
Categories
Indexed Skills (43)
analyst
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", "help me design", "what do we need to clarify"). DO NOT TRIGGER when: requirements are already clear and the user wants codebase-readiness analysis (use /prepare), wants to start implementing, or asks for a code review.
api-design
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", "какой сделать контракт/эндпоинт", adding endpoints consumers outside this repo will call. DO NOT TRIGGER when: designing an internal module seam (use /codebase-design), or the contract exists and the question is shipping a change to it safely (use /rollout).
arch-health
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 architecture health-check, "what's rotting here", "find the worst modules", "where's the tech debt", a periodic ball-of-mud scan, or deepening opportunities. DO NOT TRIGGER when: the user wants to clean up specific changed files (use /refactor), review a diff for bugs (use /code-review), or plan one known change (use /prepare).
clean-mvp
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. DO NOT TRIGGER when: the user wants to clean up the current diff or specific changed files (use /refactor — it improves code, this sweeps it away), rank architecture-level rot and ball-of-mud hotspots (use /arch-health — proposes only), or hunt correctness/security bugs (use /code-review).
decompose
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 into services", "monolith or microservices", "extract X into its own service", "is it time to break this up", or a plan proposes a new service and the boundary hasn't been justified. DO NOT TRIGGER when: the user wants in-process module/interface design (use /codebase-design), a whole-tree rot scan (use /arch-health), the extraction is already decided and needs a shipping strategy (use /rollout), or a past architecture decision needs re-examination first (use /revisit).
deploy
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 landed. DO NOT TRIGGER when: the question is the *strategy* for shipping something risky or irreversible (expand-contract, flags, canary) — that is /rollout; the question is whether the release is ready at all — that is /preflight; production is currently broken — that is /incident.
deps
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 their own code (use the `security-reviewer` agent / built-in `/security-review`), or wants to actually perform an upgrade they've already decided on.
discover
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 reuse"). Do NOT trigger when there is already a clear spec or scope → go to /prepare; or the request is a bug/failure → use /diagnose.
distill
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 conventions, "make the code consistent", "what patterns do we have", "turn how we do X into a rule", or after inheriting a codebase whose house style exists only in the code. DO NOT TRIGGER when: hunting rot/shallow modules (use /arch-health), applying cleanups to a diff (use /refactor), executing an already-decided mass migration (use /sweep), or writing the initial profile for a fresh project (use /bootstrap).
domain-model
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 ubiquitous language, record an architectural decision, resolve a naming conflict, OR another skill (analyst, grill, tdd) needs the domain model actively maintained — not merely read. DO NOT TRIGGER when: a skill only needs to *read* the glossary for vocabulary (that's a one-line habit any skill does, not this skill) — this skill is for *changing* the model.
grill-with-docs
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", aligning on something worth recording. DO NOT TRIGGER when: a quick plain stress-test is enough (use /grill), or it's pure glossary/ADR work with no plan to interrogate (use /domain-model).
grill
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", OR another skill needs the interview loop. DO NOT TRIGGER when: the user wants a written spec (use /analyst), a full impact analysis (use /prepare), to ALSO capture the terms/decisions as you align (use /grill-with-docs), or simply asked a question to be answered (just answer it).
handoff
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 continue tomorrow", "write a resume doc"). DO NOT TRIGGER to execute a plan (use /implement) or to write a feature spec (use /analyst) — this only snapshots state and writes no code.
idea
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 when: the user describes a wish in everyday words, is non-technical (per PROJECT.md → Audience or their own register), says "хочу вот так" / "make me…" / "I want an app/feature that…", or asks where to start without knowing the skills. DO NOT TRIGGER when: the user is technical and named a pipeline skill or asked for a specific stage (route directly — /discover, /analyst, /prepare, /implement), or asked a question to be answered (just answer it).
implement
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: the user wants to carry out an existing plan or subtask file. DO NOT TRIGGER when: there is no plan yet — route to /prepare (to write one) or /analyst (to investigate) first; or the work is a new module/component/command modelled on an existing one that must be registered in an extension point — route to /scaffold.
incident
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 priority is making it stop. DO NOT TRIGGER when: the bug is reproducible in dev/CI with no live users affected (use /diagnose), or the incident is over and only analysis remains (use /diagnose for root cause, /retro for patterns).
onboard
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 one feature/capability in a known repo (use /discover), hunting architectural rot in a familiar one (use /arch-health), or the user wants PROJECT.md written (that's /bootstrap — this skill *feeds* it).
perf
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 (timeout because of a hang → /diagnose), or a whole-codebase perf *audit* with no target metric (use the performance-analyzer agent directly).
prepare
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; the request is "add another <X> like the existing one" in a project that already has that shape → use /scaffold; or requirements are still unclear/ambiguous → use /analyst first.
prompt-master
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", "prompt pack", "how would I drive Opus/Sonnet through this", "разложи идею на промпты"), or wants a phased prompt plan instead of doing the work now; ALSO when the input is a whole surface rather than one change ("audit this whole area", "review every screen", "map all of X and tell me what to fix") — that is the program pass, and it is authored here, not by /prepare. DO NOT TRIGGER when: the user wants the work done in THIS session (route via /which-skill or run the pipeline skills directly), wants a spec (/analyst), a pl
prototype
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, compare UI options, feel out a flow, or "mock something up to react to" before designing for real. DO NOT TRIGGER when: the user wants to validate one risky assumption yes/no (use /spike), build the real feature (use /implement), or work out requirements in words (use /analyst).
refactor
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-review), scan the WHOLE codebase for rot/ball-of-mud hotspots (use /arch-health), or design a module's interface from scratch (use /codebase-design).
code-review
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).
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).
write-tests
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).
create-migration
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.
create-service
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.
performance-audit
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).
security-audit
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.
bootstrap
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: ACTIVE) it hands off to /update-kit instead of re-installing, so any later update or re-adapt goes through the safe staging + 3-way merge. Trigger when the user says "bootstrap", "adapt the kit", "set up .claude for this project", or when PROJECT.md is missing / still a TEMPLATE. DO NOT TRIGGER to remove or roll back the kit (that's /teardown). For a plain kit update or re-adapt you can go straight to /update-kit — running /bootstrap on an already-adapted (profile_status: ACTIVE) project is still safe: it detects that and
close-epic
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 follow-up board, draft the ledger/changelog row, and EMIT a copy-paste archive command. Takes ONE epic or a BATCH of them in a single invocation. Never flips statuses, never runs git. TRIGGER when: a multi-session epic looks finished and should be settled and archived — "close the epic", "settle and archive this", "finalize the epic", or right after its last wave merges. TRIGGER ALSO on the same request phrased as plain work, with this skill unnamed — "run the verification steps from the overview", "can this be archived" — a
codebase-design
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 when: the user wants to run tests, hunt for correctness bugs (use /code-review), or do a mechanical rename with no design question.
diagnose
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 /incident first (stabilize, preserve evidence), then return here for root cause; the user wants to build a new feature (use /analyst); or wants a general code-quality / cleanup pass with no specific failure (use /code-review).
epic-status
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. Reports and recommends — never edits, commits, or launches. TRIGGER when: "where is this epic", "what's the next wave", "can I start these in parallel", "epic status", or before launching concurrent /implement sessions. TRIGGER ALSO on the same question phrased as plain work, with this skill unnamed — "how far along is <backlog>/<name>", "what's left in this epic", "which of these are safe to run at once", "did wave N land", "is this finished", "check if the epic is done? <backlog>/<name>". Those last two are cheap status ques
preflight
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 unnamed — "anything blocking release", "run the pre-release checks", "is main safe to deploy" — an ask for a ship/no-ship judgment IS this skill. DO NOT TRIGGER when: the user wants a review of one diff (use /code-review), a security-only sweep (use /audit-security), or to settle an epic's plans and archives (use /close-epic — run it before this when an epic is involved).
rails-conventions-reference
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 `ruby-rails-conventions` rule.
rails-reference
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 in the matching `rails-*` rules.
ruby-idioms
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, not an always-on rule.
postgres-reference
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.
rspec-reference
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.
ui-ux-reference
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.
llm-agent-reference
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.
ruby-conventions-reference
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.