arbe-mull

Run a mull session: it walks through clarify, research questions, codebase research, design discussion, outline, and plan stages, each gated by a review check. The output is a phased implementation plan with concrete file changes and runnable verification commands.

The research stage uses ticket isolation: it reads only the research questions, never the original request or clarified intent. This prevents findings from being shaped by the desired solution, and every claim must carry a file:line citation.

Use it for unfamiliar code, cross-cutting features, data-model changes, or async and UI state work where a bad assumption compounds across files. Skip it for small, obvious changes — the workflow itself says to say so and move on.

No. Mull stops at the implementation plan and never implements. After the plan passes review, you create a branch or worktree and hand the artifacts to a separate implementing agent that works phase by phase.

Yes. If the runtime supports subagents, each stage and check runs in a fresh one, and research fans out to 2–6 parallel subagents grouped by codebase area. Without subagents it runs in a single context with the same structure.

The check emits a verdict of pass, revise, or go_back. Revise fixes the current stage with what it has; go_back returns to an earlier stage when the gap is upstream, such as thin research blocking a design decision.