Claude Code Setup

Restate dense, jargon-heavy, or hard-to-follow content in plain language so the user actually understands it. Use whenever the user invokes /plain, says something like "explain that more simply", "I don't follow", "what does that actually mean", "in plain English", "break that down", "ELI5", or pastes/points at text they find dense. With no arguments, restate your own previous response. With arguments (pasted text, a file path, or "the part about X"), restate that instead. Trigger even on informal signals of confusion — "wait, what?", "huh?", "lost me" — not just explicit requests.

Run a spike — a timeboxed, deliberately disposable experiment whose only job is to answer the unknowns in a task before anyone commits to a real implementation. Use whenever the user says "spike", "spike this", "let's spike it", "throwaway", "proof of concept", "POC", "quick and dirty", "just to see if it works", "prototype it", "tracer bullet", or "hack something together". Also use — even without those words — when the user is weighing whether an approach is viable, asks "would this even work", "can we do X with Y", "how hard would this be", "is this fast enough", "how many places does this touch", or is about to start a large effort whose shape depends on a fact nobody has checked yet. Prefer this over building the real thing when the honest answer to "do we know this will work?" is no.

Operate Circuit, the flow engine that runs coding work as structured, evidence-backed flows (Fix, Build, Explore, Review, Prototype). Use ONLY when the user explicitly invokes Circuit by name — e.g. says "circuit", "run a flow", "use circuit", "start a circuit run", "resume the run", or names Circuit-specific concepts (flows, checkpoints, run folders, the power dial or process override, connectors, `circuit preview`, `circuit reclaim`). Do NOT trigger on generic coding requests, even substantive ones; do NOT trigger merely because Circuit is installed in the project. Absent an explicit mention, do the work by hand.

Call-graph evidence from git via the calldiff CLI: which functions reach a symbol, and how a change moved the call structure. Use when you need blast radius before editing (does anything reach this function, and by what path), when scoping which files a change really touches, or when reviewing a diff whose risk is structural rather than textual. Tree-sitter based, 22 languages, no build step. Do not use it as a general replacement for git diff.

Give the human a fast, plain-English catch-up on what changed in the project: what the agents did, why, and what decisions need their input. Use this whenever the user asks to "catch me up", "what changed", "where are we", "recap", "brief me", "give me the rundown", "what did you do", "summarize the session", "fill me in", or otherwise signals they have been away and want to get back up to speed quickly. Built for someone steering several agent-driven projects at once who does not read the code closely but needs to grasp the core ideas, the choices made, and the open decisions well enough to steer. Trigger even if they do not use these exact words: any request to get oriented on recent progress should use this skill.

Apply professional typography principles to create readable, hierarchical, and aesthetically refined interfaces. Use when setting type scales, choosing fonts, adjusting spacing, designing text-heavy layouts, implementing dark mode typography, or when asked about readability, font pairing, line height, measure, typographic hierarchy, variable fonts, font loading, or OpenType features.

Turn the prompt supplied with this skill into a concise, auditable Codex Goal or explain why a Goal is not the right fit. Use when the user asks to draft, formulate, rewrite, tighten, or create a `/goal` from a plain-language task, especially for multi-step work that needs a durable objective, evidence-based completion, constraints, iteration policy, and a default adversarial review loop.

Create a narrative guide to a codebase or feature in the style of Knuth's Literate Programming — code and prose interwoven as a single essay, ordered for human understanding rather than compiler needs. Use when the user asks to 'explain this codebase as a story', 'write a literate guide', 'create a narrative walkthrough', 'tell the story of this code', 'Knuth-style documentation', 'weave a guide for this feature', or when they want deep, readable documentation that treats the program as literature. Also trigger when someone wants a document that a thoughtful reader could follow from start to finish and come away understanding both WHAT the code does and WHY every design choice was made.

Write a short, visual, evidence-backed GitHub PR description and open or update the PR with it. Use whenever the user asks to open a PR, write or rewrite a PR description, 'describe this change', or run gh pr create — even if they don't say 'description'. Gathers real proof first (screenshots for UI, terminal transcripts for CLI, ascii before/after for data shapes), then writes prose that captions the evidence. Do not use for PRD/product documents (that's writing-prds) or for review comments on an existing PR (that's pr-self-review).

Draft short, plainspoken notes in the author's voice that help reviewers understand non-obvious choices, boundaries, and preserved behavior in the author's own pull request or local diff. Use when the user asks to self-review, annotate, or add reviewer context to their PR or changes. Draft locally when no PR exists, and post approved notes as one GitHub review when a PR does exist. Do not use for reviewing someone else's PR, writing code comments, explaining code generally, or drafting a PR description. Never post without explicit approval.

First-principles, team-of-experts assessment of a software project that surfaces latent potential; underexploited assets, a sharper north star, missing high-leverage capabilities, better framing and messaging. Produces a prioritized, evidence-grounded report with cheap probes, a reframe candidate, a stop-doing list, and an honest skeptic's case. Use whenever the user wants fresh eyes on a project they have built: "what am I sitting on", "what could this become", "is there a bigger play here", "how do I make this valuable or impactful", "assess this project", "strategic review", "where should this go next", "is this worth pursuing", "what's the potential here", or when they point at a repo and ask what to do with it, even if they never say "assessment" or "potential". Not for routine code review, debugging, or performance audits.

Forensic audit of the user's recent Claude Code sessions to surface step-change workflow improvements — not marginal ones. Use when the user asks to "audit my Claude Code sessions", "analyze how I use Claude Code", "find patterns in my usage", "improve my Claude Code workflow", "review my sessions", "find leverage in my setup", or wants to understand where their Claude Code setup is leaking time. Samples dozens of real transcripts, extracts quantitative signal via scripts, uses parallel subagents for deep reads, then synthesizes into a short prioritized report with drafted implementations (new skills, CLAUDE.md rules, hooks, settings diffs) that the user can install directly. Trigger even when the user doesn't say the word "audit" — if they're asking about improving or reviewing their Claude Code habits at scale, use this skill.

Review recent React, Next.js, or TypeScript UI code changes for hardening before merge or commit. Use when asked to review recent React code changes, audit a React diff, harden a feature, check a PR or branch for React issues, or produce a stack-ranked list of nonredundant findings and a recommended fix plan using react-doctor, Vercel React best practices, Vercel composition patterns, and React useEffect guidance.

Create clear, polished before-and-after screenshots from the actual running product for a GitHub pull request. Use when a UI change needs visual proof: capture matching product states, crop to the relevant UI, stitch and caption one comparison image, attach it natively to the PR, and keep the image out of the repository.

Analyze a provided resource through a Circuit lens. Use when the user provides or points to an article, pasted conversation, X thread, workflow example, GitHub repo, local codebase, product page, paper, or other outside reference and asks what Circuit can learn from it, whether it suggests a possible Circuit flow, whether Circuit can support the workflow today, what product or block changes would be needed, or whether the analysis should be added to Circuit's ideas or flow backlog.

Perform evidence-driven, multi-subsystem audits of real codebases to find correctness bugs, race conditions, security gaps, stale documentation, dead code, and production-readiness risks. Use when asked to audit a system end-to-end, verify agent-written code before shipping, analyze a subsystem for correctness across multiple modules, or produce a structured risk report for a real implementation. Prefer other skills for a single isolated bug, a proposal or document review, or a dedicated dead-code cleanup.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.