Run a five-axis panel review of a completed change — code style, architecture, spec conformance, security, testing — with parallel specialist reviewers, adversarial verification of major findings, and a self-contained fix report written to .boris/reviews/. Invoke on "panel review", "full review", "review this across all axes", or when a substantial unit of work needs a thorough pre-merge check. Skip for small plan-step reviews — spawn the code-reviewer agent directly. Skip for a single-axis check — the narrower built-in (/security-review, /code-review) is cheaper; panel-review is for all five axes plus the refactoring track, the kill step, and a durable report. Work built THIS session is fine to panel-review; /adversarial-review is the lighter single-reviewer check for work that doesn't warrant five axes.
Consolidation pass over this project's native Claude memory store ($CLAUDE_CONFIG_DIR/projects/<slug>/memory/, default ~/.claude/…): merges duplicate notes, resolves contradictions, prunes stale entries, repairs [[wikilinks]], and rebuilds the MEMORY.md index. Invoke when the store has grown noisy or repetitive, or for periodic cleanup: "dream", "consolidate memory", "clean up project memory". Not for authoring new memories or improving skills/rules — that's kaizen.
Independent, unprimed review of work you produced THIS session — the brief withholds your conclusions so the reviewer reaches its own verdict; findings are relayed in its words. Invoke on "adversarial review", "red-team this", "unbiased second opinion on what I just did". For code you did NOT write (PR review, external audit) → /review or /code-review instead.
Pick up an implementation plan written by /plan (or any .boris/plans/*.md plan) and execute it faithfully in a fresh session. Invoke when the user points at a plan file and wants it built — "build @.boris/plans/...", "implement this plan", "resume", "pick up where we left off". Takes the plan path as an argument; if none is given, list the plan files in .boris/plans/ (those without a -spec/-options/-grilled/-diagnosis suffix) and ask which one.
Investigate a bug or unexpected behavior down to a confirmed root cause. Invoke at the START of looking into a failure, before the cause is known: "debug this", "why is this failing", "investigate this bug". Confirms the cause but lands no fix (/plan → /build) and writes no durable report (/diagnose, run after). Dumping in-flight state to a fresh session → /handoff.
Write a read-only diagnosis report — root cause, rules broken, five-whys — to a durable file once this session's investigation has concluded (cause confirmed, or leads exhausted and best hypothesis recorded). Invoke on "diagnose this", "root-cause report", "document what went wrong". Proposes NO fixes — that's /plan, run later off the report. Fix approach already settled → /plan; cause still under investigation → /debug; pausing that investigation → /handoff.
Interview a rough goal into a durable spec/PRD — need, scope, constraints, and what "done" means. Invoke at the very start of a feature, while the goal is still vague: "spec out X", "discuss adding X", "help me scope X". Spec only: no implementation options (/research, run next), no approach pick (/grill), no plan, no code. Skip for a small, well-understood goal — go straight to /grill or /plan.
Develop or implement a distinctive visual direction for new or substantially redesigned UI. Use during design and authorized implementation. Skip scoped fixes and work that must preserve an established visual system.