rkstack

Use this agent when a major project step has been completed and needs to be reviewed against the original plan and coding standards. Performs two-pass review (CRITICAL then INFORMATIONAL), classifies findings as AUTO-FIX or ASK, and cites file:line for every finding.

Performance regression detection using the browse daemon. Establishes baselines for page load times, Core Web Vitals, and resource sizes. Compares before/after to catch regressions. Tracks performance trends. Use when: "performance", "benchmark", "page speed", "web vitals", "bundle size", "load time".

Explore ideas before implementation. Turn vague requests into fully formed designs and specs through collaborative dialogue. Use before any creative work — creating features, building components, adding functionality, or modifying behavior. Proactively suggest when the user jumps straight to code without a design.

Headless browser for web QA, screenshots, and interaction. Navigate URLs, interact with page elements, verify state, take annotated screenshots, check responsive layouts, test forms and uploads, handle dialogs. Use when asked to open a page, test a site, take a screenshot, check responsive behavior, or verify a deployment.

Post-deploy canary monitoring. Watches the live app for console errors, performance regressions, and page failures using the browse daemon. Takes periodic screenshots, compares against pre-deploy baselines, and alerts on anomalies. Use when: "monitor deploy", "canary", "post-deploy check", "watch production", "verify deploy".

Safety guardrails for destructive commands. Warns before rm -rf, DROP TABLE, force-push, git reset --hard, kubectl delete, and similar destructive operations. User can override each warning. Use when touching prod, debugging live systems, or working in a shared environment. Use when asked to "be careful", "safety mode", "prod mode", or "careful mode".

Launch real Chrome controlled by rkstack with the Side Panel extension auto-loaded. One command: connects Claude to a visible Chrome window where you can watch every action in real time. The extension shows a live activity feed in the Side Panel. Use when asked to "connect chrome", "open chrome", "real browser", "launch chrome", "side panel", or "control my browser".

Infrastructure-first security audit. OWASP Top 10, STRIDE threat modeling, secrets archaeology, dependency supply chain, CI/CD pipeline security. Modes: full audit, --diff (branch only), --owasp, --infra, --code. Use for security review before shipping or periodic audits.

Design consultation: understands your product, researches the landscape, proposes a complete design system (aesthetic, typography, color, layout, spacing, motion), and generates font+color preview pages. Creates DESIGN.md as your project's design source of truth. For existing sites, use /plan-design-review to infer the system instead. Use when asked to "design system", "brand guidelines", or "create DESIGN.md". Proactively suggest when starting a new project's UI with no existing design system or DESIGN.md.

Designer's eye QA: finds visual inconsistency, spacing issues, hierarchy problems, AI slop patterns, and slow interactions -- then fixes them. Iteratively fixes issues in source code, committing each fix atomically and re-verifying with before/after screenshots. For plan-mode design review (before implementation), use /plan-design-review. Use when asked to "audit the design", "visual QA", "check if it looks good", or "design polish". Proactively suggest when the user mentions visual inconsistencies or wants to polish the look of a live site.

Dispatch 2+ independent tasks to parallel subagents. Use when facing tasks that can be worked on without shared state or sequential dependencies. Coordinates results and handles conflicts.

Post-ship documentation update workflow. Audits all .md files against code changes, auto-updates factual content, gates risky changes, polishes CHANGELOG voice, and ensures cross-doc consistency. Run after shipping or when documentation may be stale.

Sequential Claude-Codex review loop for specs and plans. Embedded in brainstorming and writing-plans for automatic Codex review after self-review. Also user-invocable for manual ad-hoc review. Max 3 rounds default, early exit if clean.

Execute implementation plans task-by-task with review checkpoints. Use when you have a written implementation plan to execute in a separate session. Batch execution with checkpoints for review.

Use when implementation is complete and ready to merge, create PR, or clean up a branch. Use when asked to ship, merge, land, or finish.

Restrict file edits to a specific directory for the session. Blocks Edit and Write outside the allowed path. Use when debugging to prevent accidentally "fixing" unrelated code, or when you want to scope changes to one module. Use when asked to "freeze", "restrict edits", "only edit this folder", or "lock down edits".

Full safety mode: destructive command warnings + directory-scoped edits. Combines /careful (warns before rm -rf, DROP TABLE, force-push, etc.) with /freeze (blocks edits outside a specified directory). Use for maximum safety when touching prod or debugging live systems. Use when asked to "guard mode", "full safety", "lock it down", or "maximum safety".

Use when writing human-facing text: specs, plans, docs, READMEs, CHANGELOGs, PR descriptions, blog posts, reports. Use when asked to humanize, write naturally, or remove AI patterns. Use before producing any public-facing prose.

Designer's eye plan review -- rates each design dimension 0-10, explains what would make it a 10, then fixes the plan to get there. Works in plan mode before implementation (no browser needed). For live site visual audits, use /design-review. Use when asked to "review the design plan" or "design critique". Proactively suggest when the user has a plan with UI/UX components that should be reviewed before implementation.

Report-only QA testing. Systematically tests a web application and produces a structured report with health score, screenshots, and repro steps -- but never fixes anything. Use when asked to "just report bugs", "qa report only", or "test but don't fix". For the full test-fix-verify loop, use /qa instead. Proactively suggest when the user wants a bug report without any code changes.

Systematically QA test a web application and fix bugs found. Runs QA testing, then iteratively fixes bugs in source code, committing each fix atomically and re-verifying. Use when asked to "qa", "QA", "test this site", "find bugs", "test and fix", or "fix what's broken". Proactively suggest when the user says a feature is ready for testing or asks "does this work?". Three tiers: Quick (critical/high only), Standard (+ medium), Exhaustive (+ cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only.

Respond to code review feedback with technical rigor. Use when receiving review feedback, before implementing suggestions. Requires verification of feedback accuracy, not blind agreement.

Gate-quality pre-landing review. Dispatches code-reviewer agent with checklist-driven two-pass review (CRITICAL then INFORMATIONAL), adversarial analysis, test coverage audit, documentation staleness check, and TODOS cross-reference. Fix-first paradigm.

Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics. Supports time windows: /retro [24h|7d|14d|30d]. Tracks trends across retros. Use for team health, focus scoring, and identifying hotspots.

Import cookies from your real Chromium browser into the headless browse session. Supports Chrome, Arc, Brave, Edge, and Chromium. Use before QA testing authenticated pages. Use when asked to "import cookies", "login to the site", or "authenticate the browser".

Configure project-level safety guards and working rules. Reads the detection cache from .rkstack/settings.json, installs .claude/settings.json hooks, .claude/hooks/ scripts, and .claude/rules/ files. Guards protect against destructive commands (rm -rf, force-push, drop table). Rules are curated best-practice documents copied as-is from templates. Run once per project, update when rkstack ships new templates. Use when asked to "setup project", "configure guards", "protect this project", or "add safety hooks".

Execute plans by dispatching fresh subagent per task with two-stage review after each: spec compliance first, then code quality. Use when executing implementation plans in the current session with isolated context per task.

Deep Supabase testing — auth flows, RLS policies, data consistency between browser and database, migration validation. Use when working on a project with Supabase backend.

Use when encountering any bug, test failure, or unexpected behavior. Use before proposing fixes. Use when asked to debug, investigate, find root cause, or figure out why something is broken.

Red-Green-Refactor TDD workflow. Use when implementing any feature or bugfix, before writing implementation code. Iron law: NO production code without a failing test first.

Clear the freeze boundary set by /freeze, allowing edits to all directories again. Use when you want to widen edit scope without ending the session. Use when asked to "unfreeze", "unlock edits", "remove freeze", or "allow all edits".

Create isolated git worktrees for feature work. Use when starting feature work that needs isolation from the current workspace or before executing implementation plans. Smart directory selection and safety verification.

Root skill injected at session start. Establishes how to find and use skills, maps user intent to the right skill, defines instruction priority. Loaded automatically — not invoked manually.

Use before claiming work is complete, fixed, or passing. Use before committing or creating PRs. Use when about to say "done", "tests pass", or "it works".

Write comprehensive implementation plans from specs or requirements. Use when you have a spec or requirements for a multi-step task, before touching code. Plans are bite-sized, TDD-first, with exact file paths and complete code in every step.

Create new skills for your project. Use when creating a skill from scratch, editing existing skills, or testing skill behavior. TDD applied to process documentation: write failing test, write skill, close loopholes.

1 hook across 1 event