john-superpowers

Encode working conventions as one rule file per concern in .claude/rules/ — testing (TDD, happy/negative path, coverage as discovery), migrations, design-system (atomic design vocabulary, content extremes, motion), voice (one copy table per surface, a guard test with a banned list), round-trips (independent reads go out together, batchable reads batch), code-review, coding-standard-updates (a judgment-level CODING_STANDARDS.md canon, gated by a five-point style-vs-decision test, every entry standing on its own), subagent-model-tiering (advisory escalation, parallel safety), improve-the-territory (leave touched code better than found), agent-summaries (debrief, not changelog) — generalized to the project at hand, any ecosystem. Use when the user says "setup agent rules", "encode the agent rules", or invokes setup-tooling.

Diagnose what fills a Mac's disk, attribute every large folder to the tool that wrote it, and reclaim the regenerable and leaked space with the user's go-ahead. Use when the user says "my Mac is full", "disk is almost full", "what is taking up space", "free up space", or suspects a tool (Claude, Docker, node) is filling the drive.

Diagnose and reclaim space in a WSL 2 distro — both inside Linux and the virtual disk file it lives in on the Windows drive, which grows with every write and never shrinks by itself. Use when the user says "WSL is full", "my distro is out of space", "ext4.vhdx is huge", "Docker Desktop's disk is huge", or freed space inside WSL and the Windows drive did not get it back. For the rest of the Windows drive, use `clean-windows-hdd`.

Design-level cleanup of the current change, or the whole codebase when nothing is in flight — recomputation, compat shims, dead guards, point-of-use dedup, each redundant against something upstream — iterated to a fixed point. Use when the user says "cleanup" or "clean up the design".

Design-first frontend tooling — every UI is designed in the project's design tool (Pencil or Figma, each through its MCP) with the impeccable skill governing design quality; design precedes implementation. Use when the user says "setup design tooling", or via setup-tooling on a frontend project.

Find bridging opportunities in a product, informed by the intended experience in EXPERIENCE.md and the domain language in CONTEXT.md. Use when the user wants to improve UX, reduce friction in a flow, find where users get stuck or confused, close the gap between what the product does and what it should feel like, or add purposeful delight (micro-interactions, celebrations, empathetic errors) to a flow.

AI-guardrail linting — size/complexity caps that force extraction over sprawl, no comments, named constants, everything an error, and the config protected from agent edits by a deny hook. Ecosystem-agnostic philosophy with per-ecosystem implementations (ESLint for JS/TS today). Standalone-safe on existing repos. Use when the user says "setup linting", "add lint guardrails", or via setup-tooling.

Use when the user asks to open, create, draft, raise, or "send" a pull request, or says "PR this" / "let's PR" / "ship a PR" on a branch with commits ahead of its base. Interrogates the author one question at a time, builds a reviewer-oriented PR body inline, then pushes and opens the PR via gh as a draft by default. Do NOT use for committing, merging, or reviewing existing PRs.

Implement several ready tickets at once — one fresh implementer per ticket in its own worktree, landed in a decided order, then a fresh agent's cleanup and code-review over the whole landing.

Read-only overview of review comment status on the current branch's open PR. Groups comments into addressed / pending / in-discussion / deferred-or-dismissed so you can see where things stand before acting. Use when the user says "show PR review status", "where are we on the review", "what's left to address", "summarize review progress", or comes back to a long-running PR and needs context. For active triage, fixes, and posting replies, use `triage-pr-comments` instead.

The EVM layer module for setup-tooling — wagmi + viem on TanStack Query, a wallet layer chosen per project, vendored ABIs and address provenance under src/lib/web3/, an anvil fork trial (fork / seed / dev / smoke / unstick + a runbook section) and a fixture-transport DOM test tier. Use when a web project reads and writes on-chain contracts, when the user says "set up the web3 stack", or via setup-tooling.

The Expo/React Native mobile stack module for setup-tooling — Expo (latest SDK) + Expo Router, NativeWind v5 + Tailwind v4, TanStack Query, Zod, Zustand when needed, react-native-reanimated for motion, jest-expo + @testing-library/react-native for tests, tsc typecheck and lefthook commit gates, EAS for build/update/CI/submit, all on pnpm with the 1-day package-age guard. Backend decided per project (Supabase client SDK or a shared API + Drizzle). Use when the user says "setup expo", "setup the mobile stack", "bootstrap an expo app", "scaffold a react native app", or bootstraps a fresh Expo repo — usually composed by setup-tooling.

The JS/TS stack module for setup-tooling — TanStack Start (or Vite for SPAs), TanStack Query/Form, Zustand for client state when needed, GSAP for motion/animation, Hono for pure backends, Drizzle + Docker/Supabase Postgres, Zod, Tailwind, shadcn, Vitest, tsc typecheck and lefthook commit gates, GitHub Actions CI, all on pnpm with the 1-day package-age guard. Use when the user says "setup js tooling", "setup the js stack", or bootstraps a fresh JS/TS repo — usually composed by setup-tooling.

Bootstrap a project with my preferred tooling. Drives an intent interview first, then composes the matching modules — a per-platform stack (JS/TS web via setup-js-stack, Expo/React Native mobile via setup-expo-stack), lint-guardrails, setup-evm-stack for on-chain web projects, design-tooling, and agent-rules. Use when the user says "setup tooling" or "bootstrap this project", sets up a mobile/expo app, or starts a fresh repo.

Triage review comments (CodeRabbit, reviewers) on the current branch's open PR. Verifies each claim against the actual code, classifies into explicit states, reports validity + priority, asks for clarification when needed, and only commits/pushes/replies on explicit user approval. Use when user says "triage the PR comments", "check coderabbit comments", "address review feedback", or wants a grounded assessment of review feedback before acting. For a read-only overview of where things stand (no edits, no posts), use `pr-review-status` first.