dotfiles

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.

Interview the user relentlessly to stress-test a design before building — and, handed an options doc from /research, pick the winning approach off its lean, then harden it. Use after an approach is on the table (or once /research has surveyed options) but before writing it up — to resolve open decisions, surface edge cases, and harden the design. Invoke on "grill me", "poke holes in this", "stress-test this plan", or when the user wants the design interrogated before a /plan. This runs BEFORE /plan, not after. Skip when the design is already hardened and nothing is contested — go straight to /plan.

Compact in-flight work into a briefing a fresh session can pick up cold. Use it for live investigation or partially executed plans; use /plan for a settled design that has not started.

End-of-session retrospective on the instruction artifacts actually exercised — skills, agents, rules, CLAUDE.md/AGENTS.md — where a fresh critic reads the transcript cold and proposes grounded improvement diffs. Invoke at the END of a session: "kaizen", "retro on this process", "how could this skill/agent/rule be better". Skip mid-task (no evidence yet). Improving the work product itself → /adversarial-review or /code-review, not this.

Stop building and write the agreed approach as a self-contained implementation plan saved to a file, so a fresh session with zero memory of this conversation can execute it (via /build). Invoke when the user says to stop and write a plan, or signals the approach is settled and they want to continue in a new session ("let's write this up", "start a fresh session", "I'm happy with this"). Do NOT invoke mid-debate, while trade-offs are still open, or when the user is still asking "what do you think about X" — that's exploration. For dumping in-flight context with no settled approach, that's /handoff, not /plan.

Take a spec/PRD and survey genuinely different implementation options in this codebase, with pros/cons — leans toward one but does NOT decide (/grill converges, /plan writes it up). Invoke once a spec exists, before /grill: "research options for this spec". Takes the spec path as argument; no spec yet → /discuss first. Codebase-grounded only — a web-only report is the built-in deep-research. Skip when there's one sane implementation — go to /plan (or /grill if it needs hardening).

Review public-facing prose for formulaic AI writing patterns without changing technical meaning. Skip source code and precision-first technical artifacts unless the user explicitly asks for a prose pass.