claude-code-setup

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 when 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", or "fill me in", or otherwise wants to get back up to speed after being away.

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.

Cut interface copy that should not exist. Captions that restate a label, hints that pre-empt a worry the user never had, warnings that are scar tissue from a fixed bug. Use when writing or reviewing any user-facing string (labels, hints, empty states, toasts, confirmations, button text), or when asked to clean up or tighten copy.

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.

Investigate a question that requires sustained research across sources and produce cited findings. Use for deep research requests; skip ordinary lookups and single-document reviews.

Suggest a few specific follow-up questions when consequential advice depends on unresolved assumptions. Skip reviews, simple explanations, and requests for brevity.

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.

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 solving the wrong problem is most likely and most expensive: a bug that keeps coming back after being fixed, a PRD or project whose problem statement is asserted rather than evidenced, a post-incident review, or the start of a large effort whose direction rests on an unexamined diagnosis. Do not use to pressure-test a plan whose problem is already settled, and do not use on small well-specified tasks where the frame is not in doubt.

Rename Herdr tabs, panes, and agents so each sidebar entry says in a few words what that session is doing. Use whenever the user mentions Herdr and wants tab, pane, or agent names renamed, relabeled, cleaned up, tidied, or made clearer; says a tab or agent name is confusing, meaningless, stale, or just a number; asks what a tab is; or wants the sidebar readable at a glance, even if they only say 'fix the names' or 'label these'. Reads each pane's recent output and names the task, not the project and never the auto-generated terminal title. Needs to run inside Herdr (HERDR_ENV=1). Not for naming things in code, git branches, tmux or terminal windows, or Claude Code sessions outside Herdr.

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.

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.

Restate dense text in plain language. Use when the user asks for a simpler explanation or signals confusion.

Write or update a GitHub PR description grounded in the diff and real verification. Use when opening a PR or editing its description.

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.

Draft explanatory author notes for the user's own PR or local diff. Use for self-review or reviewer context; posting requires approval.

Review a React or TypeScript UI diff for concrete behavior, accessibility, and performance risks. Use when a React review or hardening pass is requested.

Refine prose so it says what the writer means to a specific reader: cut the text that should not exist, put the point first, state things literally, remove the patterns that mark machine writing, and match the voice. Use when drafting, revising, tightening, editing, proofreading, or reviewing prose: essays, posts, emails, PR descriptions, docs, plans, reports, comments, commit messages, UI strings. Also use for requests like "clean this up", "make it read better", "tighten this", "does this sound like AI", "de-slop", or "humanize". Not for code.

Run a disposable experiment to resolve a specific feasibility question. Use for an explicit spike or when inspection cannot resolve an implementation-blocking uncertainty.

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.

Run a batch of Vignette TODO items as a multi-agent worktree run. Use when Pete asks to "run the TODOs", "run items N to M", "do a todo run", or hands over queued items from docs/TODOS.md in the Vignette repo. The orchestrator plans, briefs, and reviews; delegated coding agents do every code change and every verification, each in its own worktree with its own scratch settings; an integrator merges, a reviewer attacks the merge, and the branch is handed to Pete unmerged. Not for a single small fix in the checkout, and not for a repo other than Vignette.

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.