brandonburrus
- 73 skills
- 0 followers
- 22 hours ago last updated
- ▌ Visual Plan · brandonburrus bundleThis skill should be used whenever a plan for non-trivial work is being produced, presented, or proposed (a feature, design, refactor, migration, or any multi-step task), including in plan mode and together with whatever planning skill produced the plan. It is the default way to deliver a plan: instead of a wall of text, it renders the plan as MDX to a scannable, self-contained HTML page (diagrams, phases, file-change maps, comparisons) via the `vplan` CLI. It applies when the user says "plan this", "what's the approach", "how should we approach X", "show me the plan", "make a visual plan", "render this plan", or asks for a plan with diagrams/charts, and when they want to review, approve, sign off on, or give feedback on a plan. Skip only for a trivial one-step change or when the user explicitly asks for plain prose.
- ▌ Create Graph Spec · brandonburrus bundleThis skill should be used when authoring a new graphspec-conformant OKF knowledge-graph spec bundle, or adding concepts to an existing one, from a product or engineering intent: a feature idea, a system or component design, a requirement, a decision, or a user journey to capture. It applies when the user says "write a spec", "create a graphspec", "document this system as a graphspec", "spec out this feature", "add a requirement/component/decision to the spec", "wire this concept into the graph", or is working inside a directory that already looks like a graphspec bundle (an `index.md` plus `<name>.<type-token>.md` files). It should not be used to implement or build software FROM an already-written graphspec bundle (use follow-graph-spec instead), to author specs in any other format such as a PRD, ADR, or OpenAPI document (graphspec has zero awareness of other spec formats), or to invent node types or relation names outside the closed 13-type/16-relation graphspec vocabulary.
- ▌ Follow Graph Spec · brandonburrus bundleThis skill should be used when implementing or building software FROM an existing graphspec-conformant spec bundle, pulling only the relevant subgraph for each unit of work instead of re-reading the whole bundle. It applies when the user says "implement this spec", "build from the graphspec", "follow this graphspec to build X", "implement the next component/requirement in the spec", or a graphspec bundle (an `index.md` plus `<name>.<type-token>.md` files) is present or referenced as the source of truth for a coding task. It should not be used to author or extend a graphspec bundle (use create-graph-spec instead), for specs in any other format the graphspec CLI cannot parse, or as a substitute for actually reading the pulled concept files and their test scenarios before writing code.
- ▌ SQL Queries · brandonburrus bundleWrite correct, performant SQL across major data warehouse dialects.
- ▌
- ▌ Decompose · brandonburrusThis skill should be used when breaking a spec, plan, PRD, or feature into work units for an issue tracker such as GitHub Issues, Jira, Rally, or Linear. It applies when the user says "break this down into tickets", "create issues from this spec", "slice this into stories", "decompose into work units", "turn this plan into tasks", or "create the epics and stories". It should not be used for a single-session implementation plan you will execute yourself right now (use create-code-plan) or for writing the spec being decomposed (use spec).
- ▌ Load Test · brandonburrusThis skill should be used to empirically answer whether a system holds at target traffic by scripting and running load tests and reading the results against SLO targets. It applies when the user says "load test", "stress test", "soak test", "will it handle launch traffic", "how does it behave under load", "test at scale", "find the breaking point", or mentions k6, artillery, locust, gatling, or vegeta. It should not be used for estimating capacity by math with no measurement (use estimate-at-scale), for fixing an already-observed slow path (use optimize-performance), or for designing the SLOs themselves (use spec).
- ▌ Vibe Code · brandonburrusThis skill should be used when building a throwaway prototype or quick spike to answer a design question before committing to it, including sanity-checking a data model or state machine, mocking up UI directions, or exploring options. It applies when the user says "vibe code", "prototype this", "spike it", "quick and dirty", "just hack something together", "let me play with it", or "try a few designs". It should not be used for production code of any kind (use follow-tdd), for fixing bugs (use fix), or for work the user has not explicitly framed as disposable.
- ▌ Edit Image · brandonburrus bundleThis skill should be used when manipulating or converting raster images with sharp, including "convert this png to jpg", "resize this image", "make a thumbnail", "compress this photo", "crop/rotate/flip this image", "strip EXIF metadata", "add a watermark", "overlay my logo", "batch convert these images", or "what are this image's dimensions". Covers jpeg, png, webp, avif, gif, tiff. It should not be used for creating diagrams (use create-diagram), charts or plots from data (use visualize-data or analyze-data), editing PDFs (use edit-pdf), or vector/SVG authoring.
- ▌ Follow Tdd · brandonburrus bundleThis skill should be used when implementing any feature, fixing any bug, or changing any code behavior, before writing the implementation code. It also applies when the user says "TDD", "test first", "red-green-refactor", "write the test before the code", when authoring automated end-to-end browser tests (Playwright) for a user journey, and after the fix skill has reproduced a bug's root cause, to write the regression test first. It should not be used to diagnose a reported bug (use fix; it hands off here), for pure configuration changes, documentation, static content, or for runtime-verifying an already-built change (use the verify skill for that).
- ▌ Scrutinize · brandonburrusThis skill should be used to scrutinize the approach, premise, or decision behind a plan, design doc, or proposed change from an outsider's perspective: first whether it should exist at all or a simpler path reaches the same goal, then tracing the real end-to-end path to verify it does what it claims. It applies when the user says "scrutinize this", "sanity-check this", "poke holes in this plan", "is this the right approach", or wants a second opinion on whether the direction itself is sound. It should not be used for line-level review of a PR or diff (use review-pull-request), for verifying a finished task meets its spec with fresh evidence (use the completion-verifier agent), for whole-system architecture evaluation (use audit-architecture), or for sharpening a vague request before any work exists (use interrogate).
- ▌ Write Docs · brandonburrusThis skill should be used when generating or organizing a documentation set for a codebase, library, CLI, or API: writing a README and docs from scratch, filling documentation gaps, or restructuring docs that have become a confusing pile. It applies when the user says "document this", "write the docs", "the docs are a mess", "add docs for this feature", or "what docs does this need". It should not be used for the prose craft of a single explainer or tutorial (use teach-through-writing), for recording one architectural decision (use spec), or for API contract definition (use spec).
- ▌ Write Eval · brandonburrusThis skill should be used when writing evaluations for an LLM-powered feature, agent, or prompt: building eval datasets, choosing graders (code checks, pattern matching, LLM-as-judge, human review), setting pass thresholds, and wiring evals into the development loop. It applies when the user says "write evals", "add evals for this", "how do I know the agent actually works", "test my prompt", "the agent feels unreliable, measure it", or before changing a prompt that has no eval coverage. It should not be used for designing the agent itself (use spec), for testing conventional code (use follow-tdd), or for Claude API mechanics (use the bundled claude-api reference).
- ▌ Interrogate · brandonburrusThis skill should be used when a request, idea, topic, or direction is unclear, underspecified, or likely bigger than it first sounds, and must be understood from every angle before any work starts. It flips the script: the agent relentlessly questions the user until everything discovered is explicitly in scope, out of scope, or deferred, ending in a user-confirmed scope contract. It also applies when a mostly defined request carries just a couple of load-bearing unknowns; a lightweight mode asks only the 2-3 targeted questions those need. It applies when the user says "interrogate me", "grill me", "interview me", "question me until you get it", "clarify this", "refine this idea", "stress-test my thinking", "poke holes in my idea", "define the scope", or "am I missing something". It should not be used for writing the resulting PRD or tech spec (use spec), or for single-fact ambiguities that one direct question resolves.
- ▌ Review Code · brandonburrusThis skill should be used when reviewing code the user just wrote or changed, before committing or opening a PR, by fanning out parallel adversarial reviewers across distinct lenses (security, performance, best practices, maintainability, and an optional acceptance check against a work item). It applies when the user says "review the code I just wrote", "review my changes", "review what we just built", "review this before I commit", "multi-angle review", "adversarially review this", or asks for a thorough review of the current change. It is the multi-lens adversarial fan-out over the current change; for a quick single-pass review of the current diff use the bundled /code-review instead, and inside the execute-code-plan pipeline the code-reviewer and security-reviewer agents fill this role. It should not be used for reviewing someone else's pull request or an external branch (use review-pull-request), or for fixing the issues it finds (it reports only; hand fixes to fix or refactor).
- ▌ Analyze Data · brandonburrus bundleThis skill should be used when analyzing, aggregating, summarizing, or plotting tabular data from CSV, TSV, Excel, JSON, Parquet, or SQLite sources. It applies when the user says "analyze this data", "what's the total/average/trend", "group by", "how many rows", "plot this", "make a chart from this data", hands over a data file with a question, or wants an analysis notebook for the exploration. It should not be used for editing spreadsheet files as documents (use edit-excel-sheet), designing database schemas (use spec), architecture diagrams (use create-diagram), or building an interactive or custom data visualization as the deliverable (use visualize-data).
- ▌ Create Skill · brandonburrus bundleThis skill should be used when the user wants to create a new personal skill, update or improve an existing skill, add a skill to their skills library, teach the agent a new reusable behavior, or capture domain expertise as a skill. It also applies when the user says "make this a skill", "create a skill for X", "improve my X skill", "update the skill", "add X to the skill", "the skill got this wrong", "I want to always do Y", or pastes instructions and asks to invoke them on demand. Not for configuring automated hooks (use update-config) or for AGENTS.md and CLAUDE.md files.
- ▌ Plan Pricing · brandonburrusThis skill should be used when designing a pricing and packaging model for a software product, including picking a pricing model (flat, per-seat, usage-based, tiered, freemium, value-based), choosing the metric to charge on, estimating willingness to pay, and laying out tiers. It applies when the user says "how should I price this", "what should I charge", "design the pricing", "set up our tiers", "freemium or paid", "per-seat vs usage-based", or "what's our pricing model". It should not be used for sizing or segmenting the market (use research-market) or for cost and capacity math at scale (use estimate-at-scale).
- ▌ Tune Context · brandonburrusThis skill should be used when auditing or tightening the always-on agent context, including CLAUDE.md, AGENTS.md files, rules files, skill descriptions, and memory indexes. It applies when the user says "trim my CLAUDE.md", "my context is bloated", "the agent keeps ignoring conventions", "tighten my always-on context", or "clean up the AGENTS.md", and periodically as always-on files accumulate. It should not be used for capturing new learnings (use learn-from-context), for writing a project's first AGENTS.md (use onboard), for auditing a project's AGENTS.md coverage and conformance against the standard (use audit-agent-context), or for managing conversation-level context in a single session (compaction handles that).
- ▌ Validate API · brandonburrus bundleThis skill should be used to validate an API change by sending real HTTP requests against the running service with the Bruno CLI, asserting status, body, and headers, and saving every request into a reusable Bruno collection. It applies after implementing an API change, or when the user says "validate the API", "smoke-test the endpoint", "hit the endpoint and check the response", "verify the API works", or "check the API returns the right shape". The collection is a byproduct for future replay, and this does not replace automated API tests. It should not be used for browser or UI validation (use validate-web), for writing the vitest/supertest or Playwright suite (use follow-tdd), or for designing the API contract (use spec).
- ▌ Validate Web · brandonburrus bundleThis skill should be used to validate a web change by driving a real browser with the agent-browser CLI, confirming user-visible behavior and capturing evidence (screenshots, console, network). It applies after implementing a frontend change, or when the user says "validate this in the browser", "check the UI works", "smoke-test the page", "does the form actually submit", "click through the flow", or "verify it end to end in a browser". The deliverable is a pass/fail-with-evidence report, not a test file. It should not be used for authoring an automated e2e suite (use Playwright via follow-tdd), for API-only validation (use validate-api), or for visual design work (use design), or for a quality and accessibility critique (use audit-ui).
- ▌ Edit Word Doc · brandonburrus bundleThis skill should be used when creating, editing, or reading Microsoft Word documents (.docx), including text, headings, styles, tables, images, and headers or footers. It applies when the user says "create a Word doc", "update this docx", "read the Word document", "fill in this template", or references a .docx file. It should not be used for Markdown or plain-text writing (write directly), for PDFs (use edit-pdf), or for legacy .doc files without converting them to .docx first.
- ▌ Validate Idea · brandonburrus bundleThis skill should be used to test whether a product or business idea is worth building before committing to build it: identify the riskiest assumption, design the cheapest experiment that could falsify it, run it, and turn the evidence into a go/pivot/kill decision. It applies when the user says "validate my idea", "should I build this", "is there real demand", "test this before I build it", "design an experiment to test X", "customer interviews", "user research questions", "the Mom Test", "users say they want it but don't buy", "smoke test", "concierge MVP", "pretotype", or "riskiest assumption". It should not be used for sizing a market or reading the competitive landscape from desk research (use research-market), for refining a vague idea's intent before any test exists (use interrogate), for choosing between solution approaches (use research-solutions), or for writing the PRD once the idea is validated (use spec).
- ▌ Create Diagram · brandonburrus bundleThis skill should be used when creating any kind of diagram, including architecture, infrastructure, and cloud diagrams (AWS, Azure, GCP, Kubernetes, on-prem), network topology, C4 models, flowcharts, sequence diagrams, state machines, ER diagrams, class diagrams, Gantt charts, and git graphs. It applies when the user says "diagram this", "draw the architecture", "visualize this flow", or wants any visual representation of a system or process. It should not be used for UI mockups or wireframes (use design), editing existing images, or plotting charts from datasets.
- ▌ Create Handoff · brandonburrusThis skill should be used when compacting the current working session into a handoff document so a fresh session or another agent can continue without re-deriving context. It applies when the user says "write a handoff", "hand this off", "compact this for a fresh session", "context is running low", or "summarize where we are to continue later". Captures the goal, verified versus half-done state, decisions and their reasons, the exact next step, blockers, and load-bearing paths and commands. It should not be used for extracting durable cross-session learnings into memory (use learn-from-context).
- ▌ Ground In Docs · brandonburrusThis skill should be used before coding against an unfamiliar, fast-moving, or version-sensitive API, library, or framework: fetch and digest the official documentation for the actually installed version instead of trusting training data. It applies when the user says "check the docs", "verify against the documentation", "is this API still current", "ground this in the docs", when a plan relies on a library whose API may have shifted since training, or when an external API call keeps failing in ways that suggest a stale signature. It should not be used for Claude Code, Agent SDK, or Anthropic API questions (the claude-code-guide agent owns those), or for research unrelated to code being written (use deep-research).
- ▌ Review Metrics · brandonburrus bundleThis skill should be used after a feature or product ships, to turn usage and product data into a ship / iterate / roll-back decision with statistical honesty. It applies when the user says "did the launch work", "analyze the metrics", "read the A/B test", "is this experiment significant", "should we ship the variant", "funnel analysis", "retention / cohort analysis", "why did activation drop", "what's our north-star metric", "the feature is live, now what", or "are these numbers real". It should not be used for generic tabular data crunching with no product decision attached (use analyze-data), for pre-launch market sizing from desk research (use research-market), for pre-build demand validation before anything exists (use validate-idea), or for building a dashboard or custom visualization as the deliverable (use visualize-data).
- ▌ Triage Backlog · brandonburrusThis skill should be used when triaging incoming issues, bug reports, or feature requests on any tracker (GitHub Issues, Jira, Rally, Linear), including evaluating new issues, requesting missing information, marking work ready for implementation, or closing out-of-scope requests. It applies when the user says "triage the backlog", "what needs my attention", "look at issue #42", or "prep these issues for agents". It should not be used for creating work breakdowns from specs (use decompose), for fixing the bug itself (use fix), or for prioritization roadmapping across quarters.
- ▌ Visualize Data · brandonburrus bundleThis skill should be used when building a data visualization as the deliverable with marimo, Streamlit, or D3: an interactive reactive notebook, a shareable data app or dashboard, or a bespoke custom web chart. It applies when the user says "visualize this", "build a dashboard", "make an interactive chart", "data app", "build a marimo or streamlit notebook for this", "custom D3 visualization", or wants a visualization someone will interact with rather than a one-off image. It should not be used for a quick static chart answering an analysis question (use analyze-data), for architecture, flow, or sequence diagrams (use create-diagram), or for general UI building with no data visualization at its center (use design).
- ▌ Write Proposal · brandonburrusThis skill should be used when writing persuasive technical documents (spikes, proposals, RFCs, or vendor evaluations) where the goal is to convince stakeholders to adopt a recommended approach. It applies when the user says "write a proposal", "make the case for", "pitch this", "convince the team to", "write an RFC to adopt X", or "spike writeup"; this is the persuade-to-adopt RFC, whereas a design RFC that specifies how to build is the spec skill. It should not be used for pure documentation, reference material, or educational content where the goal is reader understanding rather than persuasion, for recording a decision already made (use spec), or for the staged migration plan itself (use spec; this skill writes the pitch that gets it adopted).
- ▌ Research Market · brandonburrusThis skill should be used to research a market and assess product-market opportunity: who the customers are, how big and reachable the market is, the competitive landscape, real demand signals, and where a wedge to fit might be. It applies when the user says "market research", "is there a market for this", "product-market fit", "PMF", "market size", "TAM", "competitive landscape", "who are the competitors", or "validate the market". The deliverable is an evidence-grounded opportunity brief with a go, refine, or no-go read. It should not be used for defining the product once the market is validated (use spec), for synthesizing feedback from existing users (use synthesize-feedback), for comparing technical tools or vendors to adopt (use research-solutions), or for general fact-finding (use deep-research).
- ▌ Write Blog Post · brandonburrus bundleThis skill should be used when drafting, editing, or writing blog posts for blog.brandonburrus.com. It should not be used for Confluence docs, READMEs, internal technical writing, or any writing not destined for the blog.
- ▌ Create Code Plan · brandonburrusThis skill should be used when planning any non-trivial code implementation, including new features, bug fixes, refactors, or architectural changes. It applies when the user says "plan this", "let's plan before coding", "what's the approach", "how should we approach X", or describes a multi-step code change without explicitly asking for a plan. It should not be used for trivial single-line changes, for tasks already fully specified with no design decisions remaining, or for designing a new system or significant architecture from scratch (use spec; this skill then plans the implementation of that design).
- ▌ Edit Excel Sheet · brandonburrus bundleThis skill should be used when creating, editing, or reading Excel spreadsheets (.xlsx, .xlsm) including cell values, formulas, formatting, multiple sheets, tables, and charts. It applies when the user says "create a spreadsheet", "update this Excel file", "read the xlsx", "add a column to the sheet", or references a .xlsx/.xlsm file. It should not be used for plain .csv files (edit them as text), for legacy .xls files without converting first, or for analyzing tabular data where the spreadsheet is only the container (load it and analyze directly).
- ▌ Estimate At Scale · brandonburrus bundleThis skill should be used to produce an order-of-magnitude estimate from rough scale parameters: monthly cost, storage, capacity, or throughput, given inputs like volume, request rate, data size, retention, and growth. It interrogates for the parameters first, then shows the assumptions and arithmetic behind the number. It applies when the user says "estimate the cost", "how much would this cost at scale", "ballpark this", "napkin math", "rough numbers for", "what's the monthly cost if", "how much storage for X users", "size this", "how many servers or connections do I need", "size the thread or connection pool", "what QPS can this handle", or "capacity planning". It should not be used for computing over a real dataset you already have (use analyze-data), for designing the system being estimated (use spec), or for diagnosing why something is slow (use optimize-performance or fix).
- ▌ Execute Code Plan · brandonburrusThis skill should be used to execute or carry out an already-approved code plan, running its tasks to completion through the subagent pipeline. It applies when the user says "execute the plan", "run the plan", "implement this plan", "build out the plan", "carry out the code plan", "run the pipeline on this plan", or hands over an approved plan and says to build it. It should not be used for creating or designing the plan (use create-code-plan, or the implementation-planner agent), for a single isolated task with no plan (dispatch the task-implementer agent directly), or when no approved plan exists yet.
- ▌ Plan Go To Market · brandonburrusThis skill should be used to plan a go-to-market launch for a software product or feature, choosing the GTM motion (product-led, sales-led, community-led), the beachhead segment and ideal-customer profile, the positioning, the channels, the launch sequence, and success metrics. It applies when the user says "plan the launch", "go-to-market", "GTM plan", "how do we launch this", "launch strategy", or "PLG vs sales-led". It should not be used for sizing the market or validating demand (use research-market), for the technical release and rollback (use prepare-for-deploy), or for a sales document (use write-proposal).
- ▌ Write Post Mortem · brandonburrusThis skill should be used when writing a post-mortem, postmortem, RCA, or root cause analysis for a fixed and validated bug. It applies when the user says "write the post-mortem", "document this fix", "write up the root cause", "close out this bug with a writeup", or when a debugging session has landed a validated fix worth recording. It should not be used for customer-facing incident reports (timeline, blast radius, and comms scope), for bugs not yet fixed and validated, or for trivial one-line fixes where the PR description is the record.
- ▌ Audit Architecture · brandonburrusThis skill should be used when evaluating a codebase's architecture and surfacing improvement candidates, including finding refactoring opportunities, consolidating tightly-coupled modules, making code more testable, or when the user says "audit the architecture", "review the structure of this codebase", "why is this so hard to change", or "find tech debt". It also applies when the fix skill escalates after repeated failed fixes in one area. It should not be used for designing new systems (use spec), for implementing the improvements it proposes (use create-code-plan then refactor), or for reviewing a single change (use review-pull-request).
- ▌ Create Claude Hook · brandonburrus bundleThis skill should be used when creating, editing, debugging, or improving a Claude Code hook, meaning the scripts and settings entries that run automatically on harness events such as PreToolUse, PostToolUse, SessionStart, Stop, or UserPromptSubmit. It applies when the user says "create a hook", "block X automatically", "run the formatter after every edit", "inject context at session start", "guard against Y before it happens", or "the hook isn't firing". It should not be used for skills (use create-skill), agents (use create-claude-agent), or settings changes with no hook script involved (use the bundled update-config).
- ▌ Learn From Context · brandonburrusThis skill should be used when extracting durable learnings from the current session, including after the user corrects the same behavior, when a hard-won lesson, gotcha, or convention surfaces mid-work, at natural wrap-up points, or when the user says "what did we learn", "remember this", "make sure this sticks", "don't make that mistake again", or "capture this for next time". It should also be used proactively when noticing a repeated correction. It should not be used for facts only relevant to this conversation, for creating the skill itself once routing says skill (use create-skill), or for wiring automation (use create-claude-hook or update-config).
- ▌ Prepare For Deploy · brandonburrusThis skill should be used when preparing a release or deployment: cutting a version, changelog and version bumps, pre-deploy gates, staging deploys, rollback plans, or when the user says "get this ready to deploy", "prep the release", "cut a release", "ship this", or asks to deploy anything. The skill prepares everything and hands the user the exact production deploy step; it never executes a production deploy itself. It should not be used for planning schema or API migrations (use spec), for fixing failures the gates surface (use fix), or for live production incidents (stabilize first, then write-post-mortem).
- ▌ Prioritize Roadmap · brandonburrusThis skill should be used to decide what to build next and in what order from a set of candidate features, bets, epics, or backlog items. It applies when the user says "prioritize the roadmap", "what should we build next", "rank these features", "what's the priority", "RICE these", "value vs effort", "sequence the backlog", "what do we cut", or "what's most important to ship this quarter". The deliverable is a ranked and sequenced list with the reasoning and the explicit cut pile. It should not be used for defining what one feature is (use spec), for breaking a chosen item into tasks (use decompose), for triaging individual incoming issues (use triage-backlog), or for choosing among technical approaches to one problem (use research-solutions).
- ▌ Research Solutions · brandonburrus bundleThis skill should be used to research and decide among technical solutions, from the approach down to the specific tool. It applies when deciding the technical approach or mechanism ("what are the options", "which approach should we take", "sync vs async", "monolith vs service") and when selecting the named dev tool that implements it ("compare X vs Y", "Postgres vs Mongo", "which database/library/framework/service should we use", "shortlist tools for", "pick a tool for", "which auth provider"). The deliverable is a decision: an evaluation table for the approach, an evidence-grounded comparison matrix for the tool, each with a recommendation and trade-offs. It should not be used for the strategic build-vs-buy of a whole capability or buying a business app like a CRM (use research-build-vs-buy), digesting docs of a chosen tool (use ground-in-docs), assessing a product's market (use research-market), or general fact-finding (use deep-research).
- ▌ Review Pr Feedback · brandonburrusThis skill should be used when handling code-review feedback received on your own pull request or change: triaging reviewer comments, deciding what to accept versus push back on, implementing the accepted fixes, and replying to reviewers. It applies when the user says "address the review comments", "respond to the PR feedback", "the reviewer asked for changes", "handle the CodeRabbit comments", or pastes reviewer feedback to act on. It should not be used for reviewing someone else's PR (use review-pull-request), for working an issue tracker (use triage-backlog), or for creating the PR itself (use pr).
- ▌ Audit Agent Context · brandonburrusThis skill should be used to audit a codebase or project for proper AGENTS.md coverage and conformance against the CLAUDE.md contextual-documentation standard: whether the root and key subsystems have AGENTS.md files, whether each carries the required sections, whether the content still matches the code, and whether any decision logs follow the format and the gates. It applies when the user says "audit the AGENTS.md files", "audit agent context", "check AGENTS.md coverage", "are the AGENTS.md files proper", "is this project documented for agents", or "review the agent context docs". The deliverable is an audit report with per-file findings and fixes. It should not be used for writing a project's first AGENTS.md (use onboard), for tightening the always-on context to cut bloat (use tune-context), for capturing a new learning into AGENTS.md (use learn-from-context), or for general architecture review (use audit-architecture).
- ▌ Check Comprehension · brandonburrusThis skill should be used when the goal is the user's own understanding rather than a finished answer: learning a new concept, thinking through their own problem or bug out loud, or verifying they understand a change, fix, or feature just built. It applies when the user says "help me understand X", "explain X to me", "rubber-duck this", "ELI5", "talk me through this problem", "make sure I understand this", "quiz me on this", or "walk me through until it clicks". It opens an interactive mode that locates the gap, makes the learner restate first, drills the whys, quizzes with AskUserQuestion, and refuses to advance until each point is mastered. It should not be used for a one-off explanation or quick fact the user only wants to read (answer directly), for sharpening a vague request before a task (use interrogate), for tutorial or explainer material for an audience (use teach-through-writing), for understanding a specific repository (use onboard), or for fixing the bug yourself (use fix).
- ▌ Create Claude Agent · brandonburrus bundleThis skill should be used when creating, editing, porting, or improving a Claude Code subagent, the Markdown agent definitions in ~/.claude/agents or .claude/agents. It applies when the user says "create an agent", "add an agent", "make a subagent for X", or "the agent isn't triggering", when the user names one or more agents to add (often role-suffixed like x-reviewer, x-auditor, x-validator), or when adding several agents at once or agents adapted from reference material. It should not be used for skills (use create-skill), hooks (use create-claude-hook), deciding which agents to create without writing them, or one-off subagent dispatch needing no saved definition (use the Agent tool).
- ▌ Execute In Parallel · brandonburrusThis skill should be used to structure work across multiple concurrent subagents for speed or quality: fanning out genuinely independent tasks, generating several competing solutions and judging them, or adversarially verifying findings with independent skeptics. It applies when the user says "run these in parallel", "parallelize this", "fan out agents", "do these at the same time", "generate a few versions and pick the best", "competitive generation", "judge multiple approaches", "use worktrees for parallel work", or "speed this up with concurrency". It should not be used for executing an already-approved code plan's implement/verify pipeline (use execute-code-plan), for the line-by-line mechanics of authoring a Workflow orchestration script (that is the Workflow tool's own surface), or for reasoning through solution options as a one-time analytical decision without spawning agents (use research-solutions).
- ▌ Format For Obsidian · brandonburrus bundleThis skill should be used when writing or formatting Markdown files for an Obsidian vault. It applies when the user mentions Obsidian, vault, wikilinks, or Obsidian-flavored Markdown, or when a .obsidian directory is detected. It should not be used for GitHub READMEs, static site generators, or any Markdown renderer that is not Obsidian.
- ▌ Generate Test Cases · brandonburrusThis skill should be used when enumerating or planning what test cases to write for a function, module, feature, or spec, covering golden path, error, and edge cases as a reviewed case matrix before any test code exists. It applies when the user says "what should we test", "list the edge cases", "enumerate test cases", "plan the test coverage", or "what cases am I missing", or wants an exhaustive coverage plan up front. It should not be used to write or run the actual test files (use test-writer), to drive test-first implementation (use follow-tdd), or to audit an existing suite against requirements (use test-coverage-requirement-auditor).
- ▌ Respond To Incident · brandonburrusThis skill should be used when responding to a live production incident or outage: a service is down, users are blocked, an alert is firing, data is at risk, or someone declares a SEV. It applies when the user says "prod is down", "we have an outage", "the site is down", "users can't log in", "sev1", "sev2", "page the team", "mitigate this now", or "stabilize the system". The skill drives stabilization, severity classification, and stakeholder communication during the incident, then hands the rest off. It should not be used for the internal engineering RCA after the fix is validated (use write-post-mortem), for debugging the root cause itself (use fix), or for pre-release deploy preparation (use prepare-for-deploy).
- ▌ Review Pull Request · brandonburrusThis skill should be used when reviewing someone else's pull request or proposed code changes. It applies when the user says "review PR #42", "review this pull request", "take a look at this PR", "what do you think of these changes", or asks for a second opinion on a branch, diff, or commit range. It also applies to reviewing a local branch against a base when no PR exists. It should not be used for opening a PR (use pr), reviewing your own in-progress work mid-task, or rewriting code for clarity (use refactor).
- ▌ Synthesize Feedback · brandonburrusThis skill should be used to turn raw product feedback into themes, the pain behind each, and the opportunities they point to. It applies to user interviews, support tickets, app reviews, survey free-text, sales notes, or churn comments, and when the user says "synthesize the feedback", "what are users saying", "themes in this feedback", "go through these support tickets", "what are the top pain points", "make sense of these reviews", or "cluster this feedback". The deliverable is signal-ranked themes grounded in quoted evidence. It should not be used for quantitative analysis of a dataset (use analyze-data), for code-review feedback on your own PR (use review-pr-feedback), for writing the spec a theme leads to (use spec), or for deciding build order across themes (use prioritize-roadmap).
- ▌ Optimize Performance · brandonburrus bundleThis skill should be used when making code, pages, queries, or services faster, when performance budgets or SLAs exist, when Core Web Vitals need improvement, or when the user says "make this faster", "this is slow", "optimize this", "reduce the bundle size", "speed up this query", or "improve load time". It should not be used for diagnosing a performance regression where something got slow after a change (use fix to find the root cause first), or for refactoring for readability without a speed goal (use refactor).
- ▌ Research Build Vs Buy · brandonburrus bundleThis skill should be used when deciding whether to build a capability in-house or adopt an existing product, and, if buying, which product to adopt for a business or team need. It applies when the user says "build vs buy", "should we build or buy X", "make or buy", "build it ourselves or use a product", "is there a product for this or do we build it", "what CRM/tool should we buy", "find software for X", "compare these apps", or "which platform should we use". It covers business applications (CRM, ITSM, project management, helpdesk, analytics, document management, and similar). It should not be used for selecting a developer-integrated library, framework, database, managed service, or dev tool, or deciding a technical approach including a dev component weighed against building it (use research-solutions), for assessing a product's own market opportunity (use research-market), or for writing the spec (use spec).
- ▌ Teach Through Writing · brandonburrusThis skill should be used when writing educational or tutorial content that teaches from first principles, including concept explainers, how-to guides, onboarding docs, and API walkthroughs. It applies when the user says "write a tutorial for", "explain X in a doc", "a how-to for", "onboarding doc", or "walk readers through X". It should not be used for persuasive documents where the goal is stakeholder buy-in rather than reader understanding (use write-proposal).
- ▌ Edit Powerpoint Slides · brandonburrus bundleThis skill should be used when creating, editing, or reading PowerPoint presentations (.pptx), including slides, layouts, placeholders, text, images, tables, charts, speaker notes, and click-to-reveal builds and animations. It applies when the user says "make a slide deck", "create a presentation", "update these slides", "add a slide", "reveal the bullets one at a time", or references a .pptx file. It should not be used for diagrams as standalone artifacts (use create-diagram), for visual design direction of non-slide UIs (use design), or for legacy .ppt files without converting to .pptx first.
- ▌ Triage Security Finding · brandonburrusThis skill should be used to triage an incoming security finding to a disposition: a dependency or scanner alert (Dependabot, Snyk, npm audit), a CVE advisory, a SAST or DAST result, or a pentest or bug-bounty report. It decides whether the finding is real, whether it is reachable and exploitable in your context, its contextual severity, and the action. It applies when the user says "triage this security finding", "is this CVE exploitable", "Dependabot flagged this", "Snyk alert", "npm audit found", "is this vulnerability real", "assess this pentest finding", "is this reachable", or "what's the real severity". It should not be used for building security into a feature as you write it (use harden), for auditing your own diff for new vulnerabilities (use the security-reviewer agent or the bundled /security-review), for reproducing and fixing a confirmed issue once triaged (use fix, then follow-tdd), or for responding to an active breach (use respond-to-incident).
- ▌ Code With Best Practices · brandonburrus bundleThis skill should be used when planning, writing, or reviewing code in TypeScript, JavaScript, Python, Go, Rust, SQL, or Bash, or when working with React, Node.js, Vitest, Playwright, Terraform, AWS CDK, pandas, NumPy, polars, marimo, or Jupyter notebooks. It applies to any implementation work in these stacks even when the user never says "best practices", and when the user says "add retries", "make this resilient", "handle upstream failures", "add timeouts", or "add a circuit breaker". It should not be used for API contract or database schema design (use spec) or UI visual design (use design).
- ▌ Translate For Leadership · brandonburrusThis skill should be used when rewriting engineering content for engineering-org leadership (VPs, directors, PMs, release managers) and shaping it for its channel: ticket comment, Slack post, async standup line, email, or meeting talking points. It applies when the user says "write this up for management", "exec summary", "leadership update", "status update", "make this less technical", or asks for a slack/email/standup version of engineering work. It should not be used for marketing or customer-facing copy, true ELI5 audiences (different rewrite, flag it), or the engineering record itself (use write-post-mortem).
- ▌ Pr · brandonburrusThis skill should be used when opening, creating, or submitting a pull request for the current branch. It applies when the user says "open a PR", "create a pull request", "submit this for review", "put this up", "push this up and open a PR", or asks to get the branch ready for review. It should not be used for reviewing an existing PR (use review-pull-request), merging or managing PRs, or committing without a PR.
- ▌ Fix · brandonburrusThis skill should be used when anything breaks or behaves unexpectedly and before proposing any fix. It applies to bug reports, failing or flaky tests, build failures, crashes, regressions, performance degradation, and pasted stack traces or error logs. It also applies when the user says "debug this", "fix this bug", "why is this failing", "it worked before", or "something is broken". It should not be used for building new features (use follow-tdd) or for troubleshooting Claude Code itself (use the bundled /debug).
- ▌ Demo · brandonburrusThis skill should be used when the user wants to see or show off a working demo of recent work, such as a feature just built, a codebase just landed in, or work completed this session. It applies when the user says "demo this", "/demo", "show me it working", "set up a demo", "let me see it", or "re-setup the demo", optionally naming a specific target. It stages realistic local demo data and proactively opens the best demo for the project type (web, API, CLI, library, service). It should not be used to confirm a change is correct (use verify) or to just launch the app without staging a presentable demo (use run).
- ▌ Spec · brandonburrus bundleThis skill should be used for system and software design: writing a product spec (PRD), a tech spec (system design, design doc), or an ADR (architecture decision record), and for domain design consults: API contracts, database schemas, observability (SLOs, alerts, dashboards), LLM agent architecture, CLI command surfaces, MCP servers, CI/CD pipelines, and migration or deprecation plans. It applies when the user says "PRD", "tech spec", "spec this out", "ADR", "record this decision", "why did we choose X", "design the API", "add an endpoint", "design the schema", "model this data", "define SLOs", "design the alerts", "build an agent", "add an LLM feature", "build a CLI", "build an MCP server", "set up CI", "plan the migration", or "deprecate this". It should not be used for implementation planning (use create-code-plan), ticket slicing (use decompose), persuasive RFCs (use write-proposal), or UI and visual design (use design).
- ▌ Design · brandonburrus bundleThis skill should be used when building, styling, or redesigning any kind of User Interface, including web components, pages, landing pages, dashboards, or frontend interfaces. It also applies when the user says "make this look better", "style this", "design a page for X", or asks for UI polish. It should not be used for auditing existing UI without changing it (use audit-ui), writing backend logic with no visual output, or generating design tokens without an actual UI component.
- ▌ Harden · brandonburrus bundleThis skill should be used when designing, building, or modifying anything that touches untrusted input, authentication, authorization, sessions, secrets, file uploads, payments, PII, or external integrations, including threat-modeling the attack surface before writing the code. It applies when the user says "make this secure", "harden this", "add auth", "is this safe", "handle user input", "threat model this", "what could go wrong here", or "what's the attack surface". It should be applied before and while writing the feature, not after. It should not be used for auditing an existing diff (use the bundled /security-review), for API contract auth design (use spec), or for triaging an incoming vulnerability or security finding (use triage-security-finding).
- ▌ Onboard · brandonburrusThis skill should be used when building an understanding of an unfamiliar codebase or orienting in a new repository. It applies when the user says "onboard me", "help me understand this codebase", "walk me through this repo", "how does this project work", "zoom out", or "where does X happen in here", and when starting substantial work in a repo with no AGENTS.md. It should not be used for evaluating architecture quality (use audit-architecture), for generating a CLAUDE.md (use the bundled init), or for locating one specific symbol (just search).
- ▌ Audit UI · brandonburrus bundleThis skill should be used to review or critique an existing UI for visual quality and accessibility without changing it, returning a severity-ranked findings report. It applies when the user says "review this UI", "audit the frontend", "critique this design", or "is this accessible", or hands over a live page, screenshots, or a component. Covers anti-slop visual quality, hierarchy and typography, accessibility (WCAG contrast, focus, ARIA, keyboard, alt text), responsive behavior, and interaction states. It should not be used for building or fixing UI (use design), or when only behavioral usability is in question (heuristics, mental-model match, flow completeness; use the ux-reviewer agent); this skill reports problems and never implements the fix.
- ▌ Edit PDF · brandonburrus bundleThis skill should be used when creating, editing, or reading PDF files, including extracting text and tables, merging or splitting documents, rotating pages, filling form fields, adding watermarks or page numbers, and generating new PDFs such as reports or invoices. It applies when the user says "read this PDF", "fill out this form", "merge these PDFs", "make a PDF of", or references a .pdf file. It should not be used for Word documents (use edit-word-doc), for rendering Markdown to PDF when a site generator or pandoc pipeline already exists, or for OCR of scanned documents (flag it; OCR is out of scope).
- ▌ Humanize · brandonburrus bundleThis skill should be used when editing text to remove signs of AI-generated writing and make it read as natural and human-written. It applies when the user says "humanize this", "make this sound less like AI", "remove the AI-isms", "this reads like ChatGPT", "de-slop this", or "make this sound natural", and as a final pass over prose the user will publish under their own name. It should not be used for drafting new content from scratch (use the writing skills), for code, or for detecting whether a third party used AI (this skill edits, it does not accuse).
- ▌ Refactor · brandonburrusThis skill should be used when refactoring or simplifying working code without changing its behavior, including reducing complexity, improving names, removing duplication, untangling nested logic, or cleaning up after a feature lands. It applies when the user says "refactor this", "simplify this", "clean this up", "this code is a mess", or "make this readable". It should not be used for fixing bugs (use fix), adding features, or architectural rewrites that change behavior (plan those with create-code-plan).
- ▌ Scaffold · brandonburrus bundleThis skill should be used when scaffolding a brand-new project from scratch: starting a new TypeScript library, CLI tool (commander), or MCP server, a new Python package or Python MCP server (uv, ruff, pytest), a new React web app with Playwright e2e, or a new pnpm monorepo with workspace catalogs. It applies when the user says "scaffold a new project", "start a new repo", "set up a new library/CLI/MCP server", "new TS package", "bootstrap a React app", or "create a pnpm monorepo". Triggers on choosing tsup, biome, vitest, fastmcp, or pnpm-workspace for a brand-new project. It should not be used when adding files to an existing project, migrating, or copying one (use code-with-best-practices for implementation in a repo that already exists).