Gustavo Franco

Audit code for accessibility issues. Checks keyboard navigation, ARIA patterns, color contrast, focus management, alt text, form labels, and screen reader compatibility. Aligned with axe-core rules and WCAG 2.1 AA. Returns file:line findings with severity.

Review API changes for backward compatibility and design consistency. Checks response shape changes, removed fields, changed status codes, new required parameters, auth changes, naming, pagination, error format, and versioning. Returns file:line findings with severity.

Trace all consumers of changed interfaces to identify the full impact of a code change. Use during code review to find files affected beyond the diff. Given changed exports, types, routes, or columns, find every dependent file.

Verify documentation accuracy against the codebase. Checks README content, stale links, code examples, env var documentation, and API doc accuracy. Returns file:line findings with severity.

Validate translation files for completeness and correctness. Checks missing keys across locales, incorrect diacritical marks, inconsistent interpolation variables, and locale coverage. Returns file:line findings with severity.

Verify database migration files for safety, idempotency, reversibility, and ordering. Use before committing migrations or during code review of migration changes. Returns a safety report with actionable findings.

Adversarial analysis of code. Attacks happy paths under load, finds silent failures, exploits trust assumptions, breaks edge cases. Use when you need a hostile review that goes beyond standard categories. Returns file:line findings with severity.

Compare the current diff against the active plan.md spec to detect scope expansion. Flags files and features not in the original plan. Use during implementation to catch unplanned changes before they accumulate.

<One line. Used for routing: be specific about WHEN this agent activates and WHAT it returns.>

Generate structured test scenarios with priority classification for a feature or file. Use during /plan, before implementation, or when /test needs scenario planning. Returns a requirement-to-test traceability matrix and categorized scenarios.

Architecture completeness audit for an implementation. Finds missing patterns, planted defects, and opportunities to stand out. Use when user says "assess", "what am I missing", "interview prep", "take-home review", "check my architecture", "pre-submission audit", or wants to verify an implementation covers all engineering patterns before declaring it done. Do NOT use for diff-based code review (use /review), security-only audits (use /audit), or running tests (use /test).

Security audit across dependencies, secrets, Docker, code patterns, images, STRIDE, and OWASP. Absorbs /deps for vulnerability scanning and /cso for threat modeling. Use when user says "security audit", "scan for vulnerabilities", "check dependencies", "find secrets", "audit Docker", "CVE scan", "cso", "threat model", "owasp audit", "deep security scan", or wants to find security issues across the full project. Do NOT use for code review (use /review), architecture completeness (use /assessment), or running tests (use /test).

Performance regression detection. Measures API latency, bundle size, and database query time, then compares against saved baselines. Use when user says "benchmark", "performance check", "check for regressions", "bundle size", "latency", "is this slower", or wants to detect performance changes. Do NOT use for code quality scoring (use /health), load testing setup, or profiling.

API breaking change management. Identifies all consumers of a changing API, generates a deprecation plan with timeline, creates the new API version alongside the old one, adds deprecation headers, and drafts a migration guide. Use when user says "breaking change", "deprecate API", "API migration", "version the API", "consumer migration", "sunset endpoint", or needs to change an API that has consumers. Do NOT use for non-breaking API changes, code review (use /review), or general planning (use /plan).

Post-deploy monitoring as a standalone skill. Checks HTTP status, response time, and response body validity at regular intervals, compares against a pre-deploy baseline, and produces a clean deploy report or a regression report with timestamps and evidence. Use when user says "canary", "monitor deploy", "watch production", "post-deploy check", "health monitor", or wants to monitor a URL or service after deployment. Do NOT use for merging PRs (use /deploy land), CI checks (use /ship checks), or incident reports (use /incident).

Save and resume working state across sessions. Subcommands: save, resume, list. Captures git state, decisions made, remaining work, and modified files so a new session can pick up where the last one left off. Use when user says "checkpoint", "save progress", "save state", "resume", "pick up where I left off", or wants to preserve session context. Do NOT use for git commits (use /ship commit), retrospectives (use /retro), or planning (use /plan).

Stale branch, PR, and worktree cleanup. Lists branches with no recent commits, PRs open too long, merged branches not deleted, orphaned worktrees, and draft PRs that went stale. Offers to close or delete with confirmation per item. Use when user says "cleanup", "clean branches", "stale PRs", "delete old branches", "prune", "tidy up", or wants to reduce repository clutter. Do NOT use for code cleanup (use /refactor), dependency updates (use /audit deps), or git workflow (use /ship).

Merge PRs, verify deployments, and monitor post-deploy health. Subcommands: land (default), canary. Extends the delivery pipeline past /ship by handling merge, deployment verification, and post-deploy monitoring. Use when user says "deploy", "merge and deploy", "land this PR", "canary", "post-deploy check", "verify deployment", or wants to take a shipped PR through to production. Do NOT use for creating PRs (use /ship pr), running tests (use /test), or CI diagnosis (use /ship checks).

Design consultation, variant exploration, and design system scaffolding. Subcommands: consult (default), variants, system. Researches design patterns, proposes component hierarchies, generates design decisions document, and creates multiple visual approaches for comparison. Use when user says "design this", "design consultation", "design system", "component design", "design variants", "UI approach", "visual direction", or needs structured design thinking before implementation. Do NOT use for design review or audit of existing code (use /review design), color palette generation (use /palette), or implementation planning (use /plan).

Post-ship documentation sync. Reads all project docs and cross-references the latest diff to find stale, missing, or outdated documentation. Identifies new features without docs, removed features still documented, changed APIs with stale examples, new env vars not in .env.example, and new CLI commands not documented. Use when user says "document release", "sync docs", "update docs after release", "docs drift", "stale documentation", "changelog polish", or wants to ensure documentation matches the current codebase after shipping. Do NOT use for generating READMEs from scratch (use /readme), code review (use /review), or incident reports (use /incident).

Explain code with educational depth. Generates Mermaid diagrams for architecture and data flow, traces data through the codebase, explains design decisions with rationale, identifies patterns, and suggests improvements. Use when user says "explain", "explain this code", "how does this work", "walk me through", "what does this do", "trace the data flow", or wants to understand a file, directory, or system with educational depth. Do NOT use for code review (use /review), debugging (use /investigate), or architecture assessment (use /assessment).

Fix a GitHub issue by number. Fetches the issue, analyzes requirements, searches the codebase, implements the fix with tests, and commits referencing the issue. Use when user says "fix issue #N", "fix #N", "resolve issue N", "close issue N", or wants to implement a fix for a specific GitHub issue. Do NOT use for general debugging without an issue (use /investigate), code review (use /review), or feature planning (use /plan).

any input (code, docs, papers, images) → knowledge graph → clustered communities → HTML + JSON + audit report

Combined safety mode for risky operations. Activates directory freeze, destructive command warnings, and scope enforcement simultaneously. Use when user says "guard", "safe mode", "freeze to this directory", "be careful", "restrict edits", or wants extra protection during a risky operation. Do NOT use for debugging (use /investigate), code review (use /review), or general editing.

Code quality dashboard with weighted scoring. Runs type checker, linter, test suite with coverage, and dead code detection in parallel, then computes a 0-10 quality score. Tracks trends over time. Use when user says "health check", "code quality", "project health", "quality score", "how healthy is this project", or wants a quick quality snapshot. Do NOT use for code review (use /review), running tests alone (use /test), or security audit (use /audit).

Emergency production fix with expedited workflow. Creates a hotfix branch from the latest release tag, applies the minimal fix, runs critical tests, ships with expedited review, and backports to the main branch. Use when user says "hotfix", "production bug", "emergency fix", "prod is broken", "urgent fix", or needs to fix something in production immediately. Do NOT use for non-urgent bugs (use /investigate), feature work (use /plan), or general debugging (use /investigate).

Gather incident context and generate a blameless postmortem from the template in observability rules. Use when user says "postmortem", "incident report", "outage report", "what happened", "write a post-mortem", or needs to document an incident with timeline, root cause, and action items.

Manage infrastructure for local development. Subcommands: docker, terraform, db. Covers container orchestration with Colima awareness, IaC workflows with safety gates, and database migrations with ORM detection. Use when user says "docker compose", "start containers", "terraform plan", "run migration", "create migration", "database setup", or needs to manage local dev infrastructure. Do NOT use for deploying to production (use CI/CD), security scanning (use /audit), or Terraform test patterns (check standards/terraform-testing.md).

Systematic debugging with hypothesis testing, bounded retries, and optional edit freeze. Use when user says "debug this", "investigate", "why is this failing", "find the bug", "trace this error", "root cause", or needs structured debugging beyond reading an error message. Do NOT use for incident postmortems (use /incident), code review (use /review), or running tests (use /test).

Manage operational learnings across sessions. Subcommands: show, search, add, prune, export, stats. Stores insights with confidence scoring and decay so the most relevant learnings surface first. Use when user says "learn", "save this insight", "what did we learn", "search learnings", "show learnings", or wants to persist knowledge across sessions. Do NOT use for checkpoints (use /checkpoint), retrospectives (use /retro), or documentation updates (use /readme).

Framework and library migration assistant. Detects current usage, identifies the migration path from official docs, generates a migration plan, and applies changes incrementally with testing between steps. Each step is a separate commit for easy rollback. Handles framework migrations, library swaps, major version upgrades, and language version upgrades. Use when user says "migrate", "upgrade", "swap library", "replace express with fastify", "upgrade to v5", "move from jest to vitest", or wants to change a framework, library, or major version. Do NOT use for dependency auditing (use /audit), code review (use /review), or planning without execution (use /plan).

Start-of-day dashboard with open PRs, pending reviews, notifications, and standup prep. Use when user says "good morning", "morning", "standup", "daily standup", "what's on my plate", "start of day", or wants a summary of pending work across GitHub and GitLab.

Pre-code brainstorming with forcing questions. No code produced, only a structured design document. Asks six questions one at a time, then produces a design document with Problem Statement, User Persona, Success Criteria, Scope, Risk Mitigation, and Competitive Analysis. Use when user says "office hours", "brainstorm", "think through this", "design session", "let's talk about", "before we code", or wants structured thinking before implementation. Do NOT use for code review (use /review), implementation planning (use /plan), or design system work (use /design).

Onboard to a new codebase with structured exploration. Scans the project, generates an architecture map with Mermaid diagrams, identifies entry points, explains the tech stack, lists key patterns and conventions, and produces a "start here" guide. Use when user says "onboard", "new project", "understand this codebase", "what does this project do", "walk me through the project", "project overview", or joins a new team or repository. Do NOT use for explaining a single file (use /explain), code review (use /review), or assessment (use /assessment).

Generate an accessible OKLCH color palette with WCAG AA contrast verification, ready for Tailwind CSS and shadcn/ui. Use when user says "generate colors", "color palette", "create a theme", "design tokens", "OKLCH palette", or needs accessible color scales for a frontend project. Do NOT use for full design audits (use /review design) or existing palette review.

Plan implementations, record architecture decisions, and scaffold boilerplate. Subcommands: plan (default), adr, scaffold. Creates spec folders, manages ADRs, and generates files from existing project patterns. Use when user says "plan this", "how should I implement", "design this feature", "create an ADR", "scaffold a service", "architecture decision", or needs to think through an approach before coding. Do NOT use for code review (use /review), shipping (use /ship), or running tests (use /test).

Performance profiling and bottleneck identification. Instruments code to find the slowest operations, ranks by impact, and suggests specific optimizations. Use when user says "profile", "why is this slow", "find bottleneck", "performance issue", "slow query", "slow endpoint", "optimize", or needs to find what is causing poor performance. Do NOT use for benchmark comparisons (use /benchmark), load testing (use /test perf), or general code review (use /review).

Generate PR summary with reviewer suggestions based on file ownership. Fetches PR data, summarizes changes, highlights risks, and recommends reviewers from git history. Use when user says "pr summary", "summarize this PR", "who should review this", "generate PR description", or wants a reviewer-ready summary of a pull request. Do NOT use for code review (use /review), creating PRs (use /ship pr), or checking CI status (use /ship checks).

Generate a marketing-grade README and GitHub repo description by analyzing the project's actual codebase, infrastructure, and architecture. Use when user says "write a README", "generate README", "update README", "repo description", or wants a polished project README for open source or marketing purposes. Do NOT use for assessment READMEs (use /assessment, which has its own technical README template) or general documentation updates.

Guided refactoring with behavior preservation verification. Identifies candidates (long functions, deep nesting, duplicated logic, god classes), proposes a refactoring plan, executes incrementally with tests between steps, and verifies no behavior change. Use when user says "refactor", "clean up this code", "simplify", "extract", "restructure", "reduce complexity", "split this file", or wants to improve code structure without changing behavior. Do NOT use for new features (use /plan), bug fixes (use /investigate), or code review (use /review).

Guided merge conflict resolution with verification. Shows each conflict with context from both branches, suggests resolution based on understanding both changes, verifies tests pass after resolution, and checks that no functionality was lost. Use when user says "resolve conflicts", "merge conflict", "fix conflicts", "rebase failed", "conflict resolution", or has merge conflicts to resolve. Do NOT use for general debugging (use /investigate), code review (use /review), or git workflow questions.

Session retrospective and codebase pattern discovery. Subcommands: retro (default) extracts corrections and preferences into durable config, discover extracts codebase conventions into rule files. Enhanced with self-improving agent lifecycle. Use when user says "retro", "what did we learn", "save preferences", "discover patterns", "extract conventions", or after a significant multi-step session with corrections worth persisting.

Review code, run QA analysis, or audit visual design. Subcommands: code (default), qa, design. Three-pass code review with 58-category checklist, 30-rule QA analysis with PICT and coverage delta, and frontend design/accessibility/performance/SEO audit. Use when user says "review this PR", "review my code", "check this diff", "QA analysis", "test coverage gaps", "design audit", "check accessibility", "check performance", "check SEO", or wants feedback on a specific change. Do NOT use for full architecture assessment (use /assessment), security scanning (use /audit), or shipping code (use /ship).

Cross-model code review using an alternative AI model for independent perspective. Uses Ollama (local), OpenAI, or other configured providers. Three modes: gate (pass/fail), adversarial (break the code), consult (open discussion). Use when user says "second opinion", "cross-model review", "independent review", "another model", "double check with another AI", or wants verification from a different model. Do NOT use for standard code review (use /review), security audit (use /audit), or design review (use /review design).

Session activity logger for handoff and standup. Shows what was done in the current session, including files changed, tests run, commits made, and decisions taken. Use when user says "session log", "what did we do", "session summary", "handoff notes", "standup notes", "export session", or wants a summary of current session activity for handoff or standup prep. Do NOT use for retrospectives (use /retro), checkpoints (use /checkpoint), or morning standup dashboard (use /morning).

Interactive project environment setup. Reads .env.example, prompts for missing values, detects required services and offers to start them via Docker, runs migrations, seeds the database, and verifies the app starts successfully. Use when user says "setup", "set up the project", "configure environment", "first time setup", "get this running", "initialize", or is setting up a project for the first time. Do NOT use for infrastructure management (use /infra), deployment (use /deploy), or README generation (use /readme).

Ship code through the full delivery pipeline. Subcommands: commit, pr, release, checks, worktree. Handles semantic commits, pull requests with CI monitoring, tagged releases, pipeline diagnosis, and parallel worktree management. Use when user says "commit", "create a PR", "push", "release", "check CI", "pipeline status", "worktree", or wants to move code from working directory to production. Do NOT use for code review (use /review), running tests (use /test), or planning (use /plan).

Technical debt triage and prioritization. Scans the codebase for TODO/FIXME/HACK/debt markers, categorizes by impact, estimates effort, and produces a prioritized backlog. Use when user says "tech debt", "show todos", "what needs fixing", "debt triage", "technical debt", "cleanup backlog", or wants to systematically review accumulated shortcuts. Do NOT use for implementing fixes (use the fix directly), code review (use /review), or assessment (use /assessment).

Run tests, load benchmarks, coverage analysis, linting, and security scanning. Subcommands absorb /perf for HTTP load testing with k6/wrk/hey/ab. Use when user says "run tests", "check coverage", "lint", "benchmark", "load test", "perf test", or wants to execute the project's test suite with results. Do NOT use for QA analysis of test gaps (use /review qa), security auditing (use /audit), or writing test scenarios during planning (use /plan).

Sprint or week retrospective with delivery metrics. Aggregates commits, PRs, and issues from the past N days, calculates velocity, identifies patterns, and produces a summary for standup or sprint review. Use when user says "weekly", "sprint summary", "what did we ship", "weekly retro", "velocity", "sprint review", "week in review", or wants a summary of team delivery over a period. Do NOT use for daily standup (use /morning), session-level retrospective (use /retro), or incident reports (use /incident).