Claude Skills by brunob54

MUST USE when the user wants new features, behavior changes, refactoring with new capabilities, or architecture decisions and no approved design exists yet. Produces an approved design document before any code is written. Triggers on: "build this", "add a feature", "I want to change", "how should we", "design", "architect", "new project", "refactor", "we need to add/build/create", "implement a new". Routed by using-superpowers, or invoke directly via /brainstorming.

Creates minimal, high-signal CLAUDE.md and AGENTS.md context files based on empirical best practices. Invoke on /init command, "create CLAUDE.md", "update CLAUDE.md", "write AGENTS.md", or "set up Claude Code for this project". Also invoked by brainstorming when repo lacks a context file. tools: Read, Glob, Grep, Bash, Edit

Use in long or noisy sessions to persist durable state across session boundaries via state.md. Also generates project-map.md when asked to map the project. Triggers on: user explicitly asks to "save state", "compress context", "map this project", "generate project map", "create project map", cross-session handoff needed, or repeated failures indicate context is getting stale.

Use BEFORE brainstorming when facing a complex architectural, technology, or design decision where the options are not yet well-defined or the problem itself may need reframing. Assembles named stakeholder perspectives that each speak once without debate, then surfaces where they converge and where real tension remains — without forcing a premature choice. Triggers on: "should we use X or Y", "not sure which approach", "evaluate these options", "what are the trade-offs between", "help me thin...

MUST USE when updating, migrating, or auditing project dependencies: upgrading packages, fixing security vulnerabilities (CVEs), resolving breaking changes, migrating to new major versions, or auditing outdated dependencies. Enforces incremental updates with verification at each step. Distinct from systematic-debugging (which fixes application bugs) and refactoring (which restructures application code). Triggers on: "update dependencies", "upgrade packages", "npm update", "pip upgrade", "outd...

Use when 2+ tasks are independent and can run concurrently without file or state conflicts or sequential dependencies. Triggers on: "run these in parallel", "do these at the same time", plans with independent tasks, when subagent-driven-development identifies parallelizable work.

Maintains a project-specific known-issues.md mapping recurring errors to their solutions. Consulted automatically by systematic-debugging before investigation. Saves time by avoiding rediscovery of known problems across sessions. Triggers on: "save this fix", "remember this error", "known issues", or automatically when systematic-debugging resolves a recurring error.

MUST USE when a plan.md exists and implementation needs to begin. Executes in controlled batches with verification checkpoints. Triggers on: "execute the plan", "start building", "follow the plan", "go". Routed by using-superpowers or writing-plans handoff.

MUST USE when implementation is verified and you need to choose the branch outcome: merge, PR, keep, or discard. Triggers on: "merge this", "create a PR", "squash and merge", "we're done with this branch", "clean up the branch", "push this", "get it merged", after verification-before-completion passes. Routed by using-superpowers or executing-plans at completion.

MUST USE for any frontend, UI, or web interface implementation. Enforces production-grade visual quality, accessibility, responsive design, and professional polish. Triggers on: "build a UI", "frontend", "website", "landing page", "dashboard", "make it look professional", any React/Vue/Svelte/HTML component work. Routed by using-superpowers, or invoke directly via /frontend-design.

MUST USE when a branch needs N independent whole-branch code review rounds with fixes applied between rounds. M clean-context reviewer subagents per round (default 1) under a rotating lens (correctness/spec alignment, adversarial red-team, security, test quality); one fix subagent per round for Critical/Important findings; sidecar audit log; early exit after two consecutive clean rounds. Invoked by subagent-driven-development at the final whole-branch review gate, or directly via /multi-code-...

MUST USE when a spec or plan document needs N independent review rounds with findings merged between rounds. M clean-context reviewer subagents per round (default 1) under a rotating lens; findings triaged into the document; a sidecar audit log records every disposition; early exit after two consecutive clean rounds. Invoked by brainstorming (spec gate) and writing-plans (plan gate), or directly via /multi-doc-review <doc-path> [N] [M=<m>]. Triggers on: "multi doc review", "document review ro...

MUST USE when the user asks to orchestrate the full development pipeline from an approved spec: plan writing, N plan-review rounds, batched implementation, and N code-review rounds run autonomously, stopping only on major errors, ending before merge/PR. Triggers on: "orchestrate the development", "orchestrate docs/superpowers-orchestrator/<date>-<slug>/specs/...", "run the whole pipeline autonomously", "resume orchestration", "abandon orchestration". Requires the Agent tool with nested dispat...

MUST USE when investigating or fixing performance issues: slow responses, high memory usage, CPU spikes, throughput degradation, or optimization requests. Enforces measure-first methodology — profile before guessing, baseline before fixing, re-measure after every change. Distinct from systematic-debugging (which changes behavior to fix bugs) and brainstorming (which designs new features). Triggers on: "slow", "performance", "optimize", "speed up", "latency", "throughput", "memory leak", "high...

Validates whether proposed or in-progress work should exist before investing in it. Invoke BEFORE designing, planning, or building anything non-trivial — and WHEN new evidence arrives that could change the motivation for existing work. Triggers on: 'design a system', 'create a plan', 'build out the full version', 'extend this to handle', architecture proposals, or any moment where test results, research findings, or changed requirements weaken the original reason for doing something. Also tri...

Handles review feedback with technical rigor: verify suggestions, resolve unclear items, implement fixes in priority order. Invoke when review comments are received or user says "address review feedback". Routed by using-superpowers when review feedback arrives.

MUST USE when restructuring existing code without changing behavior: extracting functions/modules, inlining, simplifying, decoupling, reorganizing files, renaming across the codebase, or cleaning up code structure. Enforces behavior-locking tests before any structural change and incremental verification after each move. Distinct from brainstorming (which designs new behavior) and bug fixing (which changes behavior). Triggers on: "refactor", "restructure", "reorganize", "clean up this code", "...

Structured code review against requirements, quality, and security standards. Invoke after meaningful code changes or before merge. Triggers on: "review my code", "code review", "check this before merge", "security review", "is this secure", "look over my changes", "second pair of eyes", "check the diff". Routed by using-superpowers or executing-plans after implementation.

Grounds one technology decision in verified external evidence before design approaches are compared. Dispatches a controller subagent that runs N read-only researcher subagents in parallel (candidate source reading, version verification anchored to this repository's manifest, registry existence and health, prior art) and merges their file-based reports into one evidence report. Invoked by brainstorming at its research gate with the decision, candidate list, N, topic slug, and project director...

Internal reasoning technique invoked by systematic-debugging and verification-before-completion for high-stakes multi-step inference. Generates N independent reasoning paths and takes majority vote to surface confident-but-wrong single-chain failures. DO NOT invoke independently — this skill is embedded in the skills that need it.

Executes plans using parallel subagents with per-task implementation and staged review gates. Invoke for parallel plan execution in the current session. Also provides Batched Autonomous Mode: implement up to N tasks per session with a fixed task-cap batch boundary, write a handoff into state.md, and resume after /clear. Triggers on: "implement the next N tasks", "execute the plan in batches", "resume the plan". Routed by writing-plans handoff or using-superpowers for large plans with independ...

Invoke BEFORE attempting any fix when a bug, test failure, error, warning, unexpected behavior, or performance regression appears. Enforces hypothesis-driven root cause analysis — no fix without evidence. Triggers on: error messages, stack traces, "it's broken", "not working", "bug", test failures, blank/white screens, "works locally but not in production", performance degradation, console warnings, "can't figure out why". Also routed by using-superpowers for debugging tasks.

MUST USE for any behavior change: write failing tests before production code. No exceptions. Triggers on: "TDD", "write tests first", any implementation task, bug fix needing regression tests, behavior changes during execution. Routed by using-superpowers, or invoke directly via /test-driven-development.

Always-on operational standard. Enforces concise responses, parallel tool execution, no redundant work, exploration tracking, and proactive context compression throughout every session. Applied automatically at session start.

Use before implementation when work should be isolated from the current branch. Triggers on: "use a worktree", "isolate this work", "don't touch main", experimental or risky changes that need isolation.

BLOCKING REQUIREMENT — invoke this skill BEFORE writing any code, editing files, debugging, planning, reviewing, or making any technical tool calls beyond reading files. This is the mandatory workflow router for ALL technical tasks. Matches: "implement", "build", "fix", "debug", "refactor", "optimize", "add feature", "change", "update", "create", "develop", "plan", "review", "test", or ANY request that involves code changes. Do NOT skip this skill even if the task seems simple. Invoke FIRST, ...

Invoke BEFORE saying "done", "tests pass", "ready to merge", or any completion claim. Requires fresh command output as evidence — no completion without proof. Also routed by using-superpowers at task end.

MUST USE after design approval to decompose requirements into executable task plans with verification commands and TDD ordering. Triggers on: "write a plan", "break this down", "plan the implementation", after brainstorming approval. Routed by brainstorming as the next step.