qult

Devil's advocate reviewer. Finds edge cases, logic errors, and silent failures that other reviewers missed. Use as Stage 4 of /qult:review for catching subtle bugs. NOT for spec compliance, code quality, or security — those are separate stages.

Independent plan evaluator. Assesses plan quality across Feasibility, Completeness, and Clarity before implementation begins. Use when validating a plan generated by plan-generator. NOT for reviewing code — use reviewer for that.

Independent plan generator. Analyzes codebase and expands brief feature descriptions into structured implementation plans. Use when /qult:plan-generator is invoked.

Default session agent for qult-enabled projects. Embeds quality-first philosophy into every interaction. Automatically checks gate status, suggests appropriate workflows, and enforces the architect-agent relationship. Active when qult plugin is installed.

Independent code quality reviewer. Evaluates design, maintainability, edge cases, and error handling. Use as Stage 2 of /qult:review. NOT for spec compliance or security — those are separate stages.

Independent security reviewer. Evaluates vulnerability surface and hardening of the implementation against OWASP Top 10 and common attack vectors. Use as Stage 3 of /qult:review. NOT for spec compliance or code quality — those are separate stages.

Independent spec compliance reviewer. Verifies implementation matches the plan — checks task completion, consumer coverage, and implementation gaps. Use as Stage 1 of /qult:review. NOT for code quality or security — those are separate stages.

View or change qult config values (score thresholds, iteration limits, review file threshold). Use to adjust quality gate sensitivity for the current project. NOT for gate management (use /qult:skip instead).

Structured root-cause debugging. Use when encountering any bug, test failure, or unexpected behavior — BEFORE proposing fixes. Enforces systematic investigation over guesswork. NOT for known issues with obvious fixes.

Check qult health for the current project. Verifies state files, gates, and MCP server connectivity. Use when hooks don't fire, gates seem broken, or after initial setup to confirm everything works. NOT for checking session progress (use /qult:status instead).

AI-development-specific design exploration. Interviews the architect through structured questions before any code is written. Use when starting new features, major changes, or when requirements are unclear. NOT for trivial fixes or well-scoped tasks with clear requirements.

Branch completion workflow. Use when implementation is complete and all tests pass — guides the architect through merge, PR, hold, or discard options. NOT for incomplete work or failing tests.

Set up or re-initialize qult for the current project. Creates .qult/ directory, detects gates, and configures .gitignore. Idempotent — safe to run multiple times. Use for initial setup or after changing toolchain. NOT for config changes (use /qult:config).

Generate a structured plan from a feature description. Spawns plan-generator agent to analyze the codebase and produce a task-by-task plan. Use when starting new work or to expand a brief description into a detailed plan. NOT for modifying existing plans.

Register qult hooks in .claude/settings.local.json as a fallback. Use when plugin hooks don't fire (VS Code, some environments). NOT needed if hooks already work via plugin.

Independent 4-stage code review: Spec compliance → Code quality → Security → Adversarial edge cases. Spawns specialized reviewers, then filters by Succinctness/Accuracy/Actionability. Use before a major commit or as a review gate. NOT for trivial changes.

Temporarily disable or re-enable quality gates (lint, typecheck, test, review), or clear false-positive pending fixes. Use when a gate is broken, irrelevant for current work, or producing false positives. NOT for permanently removing gates (edit .qult/gates.json instead).

Show current qult session status including pending fixes, test/review gates, and changed files. Use to check commit readiness, see what gates are blocking, or confirm all gates are clear before committing. NOT for diagnosing setup issues (use /qult:doctor instead).

TDD methodology for creating and testing qult skills. Use when creating new skills, editing existing skills, or verifying skills work correctly. Applies test-driven development to process documentation. NOT for editing non-skill files.

8 hooks across 7 events

gopls

pyright-langserver

rust-analyzer

typescript-language-server