super-agent-skills

Initialize or audit a project's CLAUDE.md against best-practice criteria. Use on first-time setup ('init', 'set up project', 'first time in this repo'), when scanning a project to create CLAUDE.md, or when refreshing an existing CLAUDE.md against the current state of the codebase. Replaces Claude Code's default /init.

Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

Check installed plugins for conflicts with super-agent-skills and suggest complementary MCP servers. Use to optimize your plugin setup.

Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.

Executes multi-stream parallel feature development across isolated worktrees. Use when writing-plans detects 2+ independent work streams in the plan and the user chooses compound execution at the handoff.

Use when you have a spec or requirements for a multi-step task, before touching code

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Drives development with tests. Use when implementing any logic, fixing any bug, or changing any behavior. Use when you need to prove that code works, when a bug report arrives, or when you're about to modify existing functionality.

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Guides stable API and interface design. Use when designing APIs, module boundaries, or any public interface. Use when creating REST or GraphQL endpoints, defining type contracts between modules, or establishing boundaries between frontend and backend.

Tests in real browsers. Use when building or debugging anything that runs in a browser. Use when you need to inspect the DOM, capture console errors, analyze network requests, profile performance, or verify visual output with real runtime data via Chrome DevTools MCP.

Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.

Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Proactive security design using STRIDE methodology. Use when building features that handle authentication, user input, external APIs, payment, PII, or multi-tenant access. Identifies threats before implementation so mitigations are designed in, not bolted on.

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Lightweight end-of-phase checkpoint. Use after completing a task or feature to update backlog, changelog, commit, and move to the next item. For branch-based workflows with merge/PR, use finishing-a-development-branch instead.