moiri-gamboni

design

Architecture design with competing approaches, adversarial review, test design, and implementation planning

implement

Decompose a large task into independent units and implement them in parallel with sub-agents in worktrees

Use when building the first working version of something real — a prototype, MVP, or proof-of-concept — quickly, but as a sound and extensible base rather than a throwaway. Covers timed or scoped builds like hackathons and take-homes. Not for hardening an established system or pure problem-space exploration.

review

Multi-dimensional code review using all specialized reviewer agents, organized by logical code path units rather than by file. Multi-wave with cross-unit pass and verification. Optional git range argument scopes the review.

ship

PR-first shipping. On main, opens a PR. On feature branches, opens a PR or pushes to an existing one. With "merge" arg, performs an explicit local merge after acceptance.

clean-gone

Clean up local branches deleted on remote, including associated worktrees

simplify

Run a simplification pass on recently modified code

Web & Frontend Listed

frontend-design

Use when the user asks to build web components, pages, or applications with high design quality

ideate

Use when the user is in problem-space exploration — figuring out what to build, whether to build it, or what existing solutions already address the problem. Stops before architecture/implementation planning (that's `/design`).

receiving-code-review

Use when receiving code review feedback OR adversarial design review (red-team) feedback, before implementing suggestions, especially if feedback seems unclear, complexity-positive, or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

systematic-debugging

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

test-driven-development

Use when implementing any feature or bugfix, before writing implementation code

verification-before-completion

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always