explore

name: explore description: Use when the user wants to explore a fuzzy idea, think through a problem, or weigh directions BEFORE committing to a work unit — when it's not yet clear whether there's anything to build, or what. The minerva analog of brainstorming — a divergent, commitment-free dialogue that writes no file, allocates no work unit, and creates no branch/worktree. Asks questions one at a time and weighs multiple high-level directions; may legitimately end in "don't build this" or "reframe the problem". When a direction is chosen, hands off to minerva:propose to design it. Use minerva:propose directly instead when you already know what you want to build and are ready to commit to a proposal.

Explore an idea

Turn a fuzzy idea into clarity through open-ended, collaborative dialogue — before committing to any plan. This is minerva's divergent, exploratory front-end: the phase you reach for when you're not yet sure there's a work unit here at all, or what the real problem even is. It mirrors superpowers:brainstorming, adapted to the minerva lifecycle.

What makes explore different from propose

explore is commitment-free by construction. It writes no file, allocates no work unit (no slug, no NNN), and creates no branch or worktree. Everything it produces lives in the conversation. That is the whole point: exploration should cost nothing to abandon.

minerva:propose, by contrast, is convergent — its job is to produce the proposal.md artifact (plus the branch and worktree). Reach for minerva:propose directly when you already know what you want to build. Reach for explore when you don't yet.

The two diverge on different axes and compose cleanly, so a handoff is never redundant:

• explore diverges on the problem / direction axis — what to build, or whether to build anything at all.
• minerva:propose diverges on the implementation-approach axis — how to build the direction you chose.

explore settles the direction; minerva:propose then designs it.

The process

1. Explore project context first. Skim CLAUDE.md / AGENTS.md, .minerva/knowledge/ (start from index.md, the catalog), and a couple of recent .minerva/work/NNN-*/proposal.md files. Understand what already exists before exploring what might.

2. Ask questions one at a time. Prefer multiple-choice, but open-ended is fine. Only one question per message — if a topic needs more exploration, break it into several questions across several messages. Focus on understanding the problem: who has it, why it matters, what constrains it, what "better" would look like. Resist jumping to solutions.

3. Weigh multiple directions. As understanding forms, surface 2–3 high-level directions (not implementation approaches) with their tradeoffs, leading with your reasoning. The goal is to widen the option space and pressure-test whether the idea is worth pursuing at all — not to pick a design.

4. Be willing to land anywhere. Exploration has three legitimate terminal outcomes, and none is a failure:

   • Drop — "this isn't worth building." A clear, well-reasoned no is a successful exploration.
   • Reframe — "the real problem is Y." The idea mutates into a better one; keep exploring the new framing.
   • Ready — a direction is chosen and the user wants to commit it to a work unit. Proceed to handoff.

Handing off to propose

When — and only when — the user has converged on a direction and wants to turn it into a real work unit, hand off by invoking the minerva:propose skill via the Skill tool, passing the converged direction as the inline argument:

invoke the minerva:propose skill with argument "<the converged direction, in one phrase>"

Passing the direction inline lets minerva:propose pick up exactly where exploration left off: it treats the direction as the draft goal and proceeds straight to designing how to build it, rather than re-asking what you want to build or re-opening the problem space you just closed. Do not merely describe the handoff in prose and stop ("you should now run propose"); actually invoke the skill.

Out of scope

• Writing anything durable. explore produces no proposal.md, no scratchpad.md, no knowledge entry, and no notes file. If exploration surfaces something genuinely durable mid-stream, that is the signal you are ready to hand off to minerva:propose — not a reason to start writing files here.
• Stress-testing a drafted plan. That is minerva:grill-plan's job — it interrogates an already-drafted plan to convergence. explore is upstream of any draft, so the two do not overlap.
• Implementation. explore never writes code. It stops at shared understanding of the problem and a chosen direction (or a decision not to proceed).