// Use when completing a feature, before creating a PR, or when the user asks "what do my experts think?" Dispatches the expert panel as parallel subagents for structured code review from multiple perspectives.
Break an issue into tasks so small and precise that each has exactly one correct implementation. Refuses to launch execution until the plan contains actual code shapes, verified file paths, and scope locks. Use before any implementation session.
Use when implementing a milestone with multiple issues. Thesis-first approach: write failing E2E tests before issues, expert-review acceptance criteria before implementation, use dedicated terminal sessions (not subagents), and verify E2E yourself before merging. Includes review cycle that creates follow-up issues when expert review surfaces new gaps.
Use when the user wants to find, catalog, or address technical debt. Also use when starting a cleanup sprint, looking for code quality improvements, or asking "what needs cleaning up?"
Babysit open PRs — auto-rebase, fix CI, address review comments. Use with /loop 5m /babysit for hands-free PR management.
Run Holzmann "Power of Ten" discipline review on changed code. Checks nesting depth, loop bounds, function size, preconditions, mutable state, side effect surfacing, and indirection depth. Use after writing code, before committing, or as part of PR review. Outputs a weighted letter grade (A-F) with stoplight color.
Commit staged changes, push branch, and create a PR with full pre-flight verification.
| name | expert-review |
| description | Use when completing a feature, before creating a PR, or when the user asks "what do my experts think?" Dispatches the expert panel as parallel subagents for structured code review from multiple perspectives. |
Dispatch expert panel agents in parallel for multi-perspective code review.
| Agent | Perspective | Tier | When to dispatch |
|---|---|---|---|
expert-fielding | REST, HATEOAS, HTTP semantics | 1 | Always for HTTP/middleware changes |
expert-darrel-miller | API discovery, ALPS, JSON Home, standards | 1 | Always for discovery/profile changes |
expert-fowler | ASP.NET Core, DI, middleware, perf | 2 | Implementation/middleware changes |
expert-7sharp9 | F# idioms, allocation, perf | 2 | Implementation changes |
expert-seemann | Purity boundaries, functional architecture | 3 | Architecture changes, new modules |
expert-harel | Statechart formalism, runtime correctness | 3 | Statechart changes only |
expert-don-syme | F# API design, naming, type design | 3 | Public API changes |
expert-amundsen | ALPS profiles, affordance design | 4 | ALPS/profile changes only |
expert-wlaschin | F# DX, explainability, domain modeling | 4 | API surface, DX changes |
expert-claude-agent | Agentic consumption, demo readiness | 4 | Feature additions, scope changes |
git diff --stat <base>..<head>
Categorize the change:
Pick 2-4 experts. Don't dispatch all 10 — focused reviews are better than diluted ones.
Launch selected experts as parallel subagents. Each gets:
Collect all [EXPERT-{severity}] findings. Deduplicate (multiple experts may flag the same issue).
Do NOT triage by severity. The user decides severity. Instead, assess each finding by probability of successfully resolving in the current session (0-100%) with reasoning.
Present all findings in a single table:
| Finding | Fix probability | Reasoning |
|---------|----------------|-----------|
| [FIELDING] src/Foo.fs:42 — Response missing Allow header | 95% | One-line fix, clear spec |
| [FOWLER] src/Bar.fs:15 — Singleton service resolved per-request | 80% | Straightforward DI change |
| [SEEMANN] src/Baz.fs:8 — Pure function extraction | 30% | Needs design discussion |
Let the user decide what to fix. Do not sort into "fix now" vs "follow-up" or recommend severity tiers.
If experts disagree, use the priority tiers to break ties (Fielding > Fowler > Harel).