polish
Pre-release code review - runs lint/type checks, then launches 4 parallel review agents (cleanliness, design, efficiency, side-effect gating) to analyze the diff, synthesizes a unified report, and fixes with approval. Use before committing, pushing, or releasing changes. Triggers on "review code", "check before commit", "cleanup before release", "review changes", "is this ready to ship", "polish before release", "simplify".
What this skill does
# Pre-Release Polish
Current branch: !`git rev-parse --abbrev-ref HEAD`
Uncommitted changes: !`git diff --stat 2>/dev/null | tail -1`
## Rules
- Read every changed file fully before reviewing - never assess code you haven't opened
- Only flag real issues, not style preferences already handled by the formatter
- Do NOT add comments, docstrings, or type annotations to code that doesn't have them
- Distinguish legitimate operational logging (`logger.info`, `logger.error`) from debug leftovers (`console.log`, `console.debug`)
- When fixing, make minimal targeted edits - don't refactor surrounding code
- Only flag issues in changed/added lines, not pre-existing code
- Reuse suggestions must point to a specific existing function/utility in the codebase, not hypothetical "you could extract this"
- Do not flag efficiency on cold paths, one-time setup code, or scripts that run once
## Phase 1: Automated Checks
Run the project's lint + type-check command. Check CLAUDE.md for the correct validation command (commonly `pnpm check`, `just check`, `cargo clippy`, `uv run ruff check`, etc.).
If checks fail:
1. Fix all errors
2. Re-run checks until clean
3. Then proceed to Phase 2
If no validation command is found in CLAUDE.md, ask the user what to run.
## Phase 2: Diff Analysis
Determine what changed:
1. Check for uncommitted changes: `git diff` + `git diff --cached`
2. If no uncommitted changes, diff against main: `git diff main...HEAD`
3. If no changes at all, report "nothing to review" and stop
Read every changed file fully. Understand what each change does and why.
When a change relocates or rewrites an existing code path (a moved file, a handler split into middleware, a renamed/replaced function), open the prior version - the file it moved from, or `git show <ref>:<path>` for a deleted/renamed file - and compare behavior, not just lines. Note any dropped validation, reordered side-effects, or removed guards; pass those to the agents.
## Phase 3: Parallel Review
Use the Agent tool to launch all four agents concurrently in a single message. Pass each agent the full diff and the list of changed files so it has the complete context.
### Agent 1: Cleanliness
Fast, mechanical, high-confidence. Looks for junk that should be removed.
- **Debug leftovers**: `console.log`, `console.debug`, `console.warn` added during development; temporary debug variables, hardcoded test values. NOT structured logger calls (`logger.info`, `logger.error`, `c.var.logger`)
- **AI slop**: comments explaining obvious code ("// increment counter", "// return the result") - flag each such comment individually, even if the code it describes is also flagged under another category; JSDoc on internal/private functions that aren't part of a public API; verbose docstrings on simple helpers; `TODO`/`FIXME`/`HACK` markers left by Claude (not by the user); unnecessary type annotations where the language infers correctly; emoji in code or comments (unless the project uses them)
- **Dead code**: unreferenced functions, variables, types; commented-out code blocks (git has history); unused function parameters (unless required by interface/callback signature)
- **Unused imports**: imports added but never referenced, imports left behind after refactoring (linter catches most - verify edge cases)
- **Hardcoded values**: magic numbers or strings that should be in constants; URLs, prices, limits that belong in config. NOT obvious constants like `0`, `1`, `true`, HTTP status codes
### Agent 2: Design & Reuse
Requires codebase exploration beyond the diff. Looks for structural and design issues.
- **Reuse opportunities**: search the codebase for existing utilities, helpers, and shared modules that could replace newly written code. Look in utility directories, shared modules, and files adjacent to the changed ones. Flag hand-rolled logic where a utility already exists (string manipulation, path handling, type guards, env checks)
- **Over-engineering**: helper functions used exactly once (should be inlined); abstractions wrapping a single call with no added value; try/catch adding nothing (re-throwing same error, catching impossibilities); validation of internal data already validated at route boundary; feature flags or config for things that could just be code; backwards-compat shims for code that was just written
- **Redundant state**: state that duplicates existing state; cached values that could be derived; observers/effects that could be direct calls
- **Parameter sprawl**: adding new parameters to a function instead of generalizing or restructuring existing ones
- **Copy-paste with slight variation**: near-duplicate code blocks that should be unified
- **Leaky abstractions**: exposing internal details that should be encapsulated, or breaking existing abstraction boundaries
- **Stringly-typed code**: using raw strings where constants, enums, or branded types already exist in the codebase
- **Structural issues**: functions that grew too long during changes (>50 lines, consider splitting); inconsistent naming with existing codebase conventions
- **Behavior drift in relocated code**: when the diff moves or rewrites an existing path, compare it against the code it replaced (see Phase 2). Flag dropped input validation, removed guards or early-returns, and changed error semantics (status codes, return shapes). A refactor that changes *behavior* is a regression even when every line looks clean.
### Agent 3: Efficiency
Looks for runtime performance and resource issues.
- **Redundant work**: redundant computations, repeated file reads, duplicate network/API calls, N+1 patterns
- **Missed concurrency**: independent operations run sequentially when they could run in parallel
- **Hot-path bloat**: new blocking work added to startup or per-request/per-render hot paths
- **No-op updates**: state/store updates inside polling loops, intervals, or event handlers that fire unconditionally without change detection. Also: wrapper functions that take updater/reducer callbacks but don't honor same-reference returns
- **TOCTOU anti-patterns**: pre-checking file/resource existence before operating - operate directly and handle the error
- **Memory**: unbounded data structures, missing cleanup, event listener leaks
- **Overly broad operations**: reading entire files when only a portion is needed, loading all items when filtering for one
- **Unchecked system boundaries**: fetch/HTTP calls without response status checks (`r.ok`), unhandled promise rejections on external calls, missing error handling at I/O boundaries
### Agent 4: Side-Effect Gating
Closed-scope correctness check. Finds costly or irreversible side-effects that run before the checks meant to gate them. Does NOT judge whether business logic is correct - that is `/review`'s job.
- **Inventory the side-effects**: list every costly or irreversible side-effect introduced or relocated in the diff - charges/payments, DB writes/deletes, mutating external calls, file writes, notifications/emails, irreversible state changes
- **Inventory the gates**: for each side-effect, list the checks that must precede it - input validation (shape/type/range), authentication, authorization, precondition/existence checks, idempotency/dedup
- **Cross-check ordering**: flag any side-effect reachable on a control-flow path where a gate runs after it, or not at all. Trace ACROSS the middleware/handler boundary - middleware that fires a side-effect before calling `next()` is the prime suspect; the validation that should gate it often lives in the downstream handler
- **Missing rollback**: flag a committed side-effect with no compensation when a later step on the same request can still fail (e.g. charged, then the request errors)
- **Out of scope** - route to `/review`: whether the business logic is correct, pricing math, algorithmic correctness, anything without a crisp invariant
Every finding must cite the side-effect line, the gate it precedes (or "ungated"), and the contrRelated in Design
contribute
IncludedLocal-only OSS contribution command center. Auto-refreshes the user's in-flight PR and issue state on invoke so conversations start with full context — no need to brief Claude on what's in flight. Helps the user find issues to contribute to on GitHub, builds per-repo dossiers of what each upstream expects (CLA, DCO, branch convention, AI policy, draft-first, review bots, issue templates), runs deterministic gates before any external action so AI-assisted contributions don't reach maintainers as slop. State is markdown-only: candidate files at ~/.contribute-system/candidates/, repo dossiers at ~/.contribute-system/research/, append-only event log at ~/.contribute-system/log.jsonl. No database, no cloud calls. Use when the user asks about their PRs / issues / contributions, wants to find new work to take on, claim an issue, build/refresh a repo's dossier, or draft a Design Issue or PR. Trigger with "/contribute", "what's my PR status", "find a contribution", "claim issue X", "draft a Design Issue for Y", "refresh dossier for Z".
architectural-analysis
IncludedUser-triggered deep architectural analysis of a codebase or scoped subtree across eight modes — information architecture, data flow, integration points, UI surfaces, interaction patterns, data model, control flow, and failure modes. This skill should be used when the user asks to "diagram this codebase," "map the architecture," "show the data flow," "give me an ERD," "trace control flow," "find the integration points," "verify the layout pattern," "audit the UX architecture," or any similar request whose primary deliverable is mermaid diagrams plus cited reports under docs/architecture/. Dispatches haiku/sonnet sub-agents in parallel for per-mode exploration, then verifies every citation mechanically before any node lands in a diagram. Not for one-off prose explanations of code (use code-explanation) or for high-level system design from scratch (use system-design).
mcp
IncludedModel Context Protocol (MCP) server development and tool management. Languages: Python, TypeScript. Capabilities: build MCP servers, integrate external APIs, discover/execute MCP tools, manage multi-server configs, design agent-centric tools. Actions: create, build, integrate, discover, execute, configure MCP servers/tools. Keywords: MCP, Model Context Protocol, MCP server, MCP tool, stdio transport, SSE transport, tool discovery, resource provider, prompt template, external API integration, Gemini CLI MCP, Claude MCP, agent tools, tool execution, server config. Use when: building MCP servers, integrating external APIs as MCP tools, discovering available MCP tools, executing MCP capabilities, configuring multi-server setups, designing tools for AI agents.
react-native-skia
IncludedDesign, build, debug, and optimise high-polish animated graphics in React Native or Expo using @shopify/react-native-skia, Reanimated, and Gesture Handler. Use when the user wants canvas-driven UI, shaders, paths, rich text, image filters, sprite fields, Skottie, video frames, snapshots, web CanvasKit setup, or performance tuning for custom motion-heavy elements such as loaders, hero art, cards, charts, progress indicators, particle systems, or gesture-driven surfaces. Also use when the user asks for fluid, glow, glass, blob, parallax, 60fps/120fps, or GPU-friendly animated effects in React Native, even if they do not explicitly say "Skia". Do not use for ordinary form/layout work with standard views.
plaid
IncludedProduct Led AI Development — guides founders from idea to launched product. Six capabilities: Idea (discover a product idea), Validate (pressure-test the idea against fatal flaws, problem reality, competition, and 2-week MVP feasibility), Plan (vision intake + document generation), Design (translate image references into a design.md spec), Launch (go-to-market strategy), and Build (roadmap execution). Use when someone says "PLAID", "plaid idea", "help me find an idea", "product idea", "idea from my business", "idea from my expertise", "plaid validate", "validate my idea", "pressure-test", "is this idea good", "find fatal flaws", "validate the problem", "plan a product", "define my vision", "generate a PRD", "product strategy", "plaid design", "design from image", "translate image to design", "create design.md", "extract design tokens", "plaid launch", "go-to-market", "launch plan", "GTM strategy", "launch playbook", "plaid build", "build the app", "start building", or "execute the roadmap".
nextjs-framer-motion-animations
IncludedAdds production-safe Motion for React or Framer Motion animations to Next.js apps, including reveal, hover and tap micro-interactions, whileInView, stagger, AnimatePresence, layout and layoutId transitions, reorder, scroll-linked UI, and lightweight route-content transitions. Use when the user asks to add, refactor, or debug Motion or Framer Motion in App Router or Pages Router codebases, especially around server/client boundaries, reduced motion, LazyMotion, bundle size, hydration, or route transitions. Avoid for GSAP-style timelines, WebGL or 3D scenes, heavy scroll storytelling, or CSS-only effects unless Motion is explicitly requested.