Claude Skills by petekp

Write clear, plain-spoken code comments and documentation that lives alongside the code. Use when writing or reviewing code that needs inline documentation—file headers, function docs, architectural decisions, or explanatory comments. Optimized for both human readers and AI coding assistants who benefit from co-located context.

Conduct exhaustive, citation-rich research on any topic using all available tools: web search, browser automation, documentation APIs, and codebase exploration. Use when asked to "research X", "find out about Y", "investigate Z", "deep dive into...", "what's the current state of...", "compare options for...", "fact-check this...", or any request requiring comprehensive, accurate information from multiple sources. Prioritizes accuracy over speed, cross-references claims across sources, identif...

Perform comprehensive, deep analysis of a system and its subsystems to identify bugs, race conditions, stale documentation, dead code, and correctness issues. Use when asked to "audit this system", "exhaustive analysis of X", "analyze for correctness", "root out issues in...", "deep dive into...", "verify this code is correct", "find bugs in...", or when reviewing agent-written code for production readiness. Automatically decomposes systems into subsystems, applies appropriate analysis checkl...

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, or when the user asks about readability, font pairing, line height, measure, or typographic hierarchy.

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 subag...

Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.

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 liter...

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.

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 co...

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.

Operate Circuit, the flow engine that runs coding work as structured, evidence-backed flows (Fix, Build, Explore, Review, Prototype). Use this skill at the START of any substantive coding task in a project where Circuit is installed: fixing a bug, building a feature, refactoring, reviewing a diff or PR, investigating a question, or prototyping. Also use it whenever the user mentions Circuit, flows, runs, checkpoints, run folders, the power dial or process override, connectors, or asks to crea...

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",...

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 inf...

Create clear, polished before-and-after screenshots for a GitHub pull request. Use when a UI change needs visual proof: capture matching 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.

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 d...

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 wo...

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.

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.

Check whether the stated problem is the right problem before work commits to it. Walks a problem statement back down to what was actually observed, names where the inference leapt, and returns competing frames plus the cheapest observation that would tell them apart. Use when the user asks "is this the right problem", "frame check", "what if the real problem is something else", "are we sure that's the cause", "reframe this", or questions a diagnosis. Also use proactively at the moments where ...

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 ...