Propose

Start a new work unit by brainstorming, creating its branch + worktree, and writing its proposal inside the worktree.

Usage

• minerva:propose — brainstorms a new work unit; infers intent from current-session context, or asks if context is blank
• minerva:propose "add rate limiting" — inline description used as the starting point for Q&A

Pre-flight check

If .minerva/ doesn't exist yet at the project root, suggest the user run minerva:init first so the directory layout and agent-file Routing section are in place. You can still write the proposal without it, but minerva:init is the cleaner entry point.

Protocol

This skill mirrors the superpowers:brainstorming flow but writes to .minerva/work/NNN-<slug>/proposal.md instead of a generic spec path.

Convergent step — relationship to minerva:explore. minerva:propose is the convergent step of the lifecycle: its job is to produce the proposal.md artifact (plus the branch and worktree). Its optional upstream counterpart is minerva:explore — the divergent, commitment-free phase for exploring a fuzzy idea before any work unit exists. The two diverge on different axes and compose: minerva:explore diverges on the problem / direction axis (what or whether to build), while propose diverges on the implementation-approach axis (how to build the chosen direction). When you arrive here from a minerva:explore handoff, the converged direction is passed as the inline description (see step 1) — the problem-space exploration is already done, so do not re-litigate whether or what to build; confirm the chosen direction and proceed to designing how (the approach work in steps 5–6). This boundary rides propose's existing inline-argument intake; there is no separate "did exploration happen?" detection to perform.

1. Context-sensitive intake. Determine what the user wants to build before asking clarifying questions:

   • If a description was passed inline → treat it as the draft goal; skip the "what do you want to build?" question and confirm/refine it. (A handoff from minerva:explore arrives exactly this way — the converged direction is the inline description.)
   • If no description but current-session chat history is present → read the history and repo structure, state the inferred intent ("Based on our conversation, it sounds like you want to X — is that right?"), and let the user confirm or redirect.
   • If no description and no relevant current-session history → ask "What would you like to build?"

2. Scope check. Before asking clarifying questions, decide whether the request fits a single work unit. If it spans multiple independent subsystems ("build a platform with chat, billing, analytics", "rewrite the entire data layer"), surface this immediately and help the user decompose into smaller work units. Each sub-unit gets its own minerva:propose run. Do not produce a 500-line proposal for work that should be three separate units.

3. Explore project context. Read CLAUDE.md / AGENTS.md if present, skim .minerva/knowledge/ (and .minerva/decisions/ if it still exists — legacy directory), glance at recent .minerva/work/NNN-*/proposal.md files for tone and conventions. This informs the questions you'll ask.

4. Ask clarifying questions one at a time. Cover purpose, constraints, and success criteria. Prefer multiple-choice. Don't batch.

5. Propose 2–3 approaches with tradeoffs and a recommendation. Lead with the recommendation. Iterate based on user feedback.

6. Draft the design internally, then stress-test it before showing it for approval. Pull the chosen approach plus everything gathered so far into a complete first-pass draft of Goal / Why / Approach / Success criteria / Open Questions — keep it in conversation, do not write any file yet. Then invoke the minerva:grill-plan skill via the Skill tool against that draft (it takes no argument — it reads the drafted design from conversation); do not paraphrase its protocol inline. Let grill-plan walk the decision tree, edit affected sections of the draft in place as answers surface, and return only once shared understanding is reached. The draft that exits grilling is what step 7 presents.

7. Present the design in sections (Goal, Why, Approach, Success criteria, Open Questions). Get approval per section before moving on.

8. Pre-write hard gate: do not write any file until the user has explicitly approved every section.

On approval — worktree setup + file writes

The full on-approval sequence — slug derivation, duplicate check, NNN computation across all three sources, default-branch resolution, gitignore pre-flight, git worktree add, worktree-prefixed addressing (no EnterWorktree), the proposal.md + scratchpad.md templates, self-review, initial commit, and the post-write user gate — lives verbatim in references/on-approval.md. Read it in full the moment every section is approved, before writing anything.

Out of scope

• Implementation. This skill stops at writing and confirming the files. minerva:work is the next phase.
• Worktree abandonment. If the user rejects at the post-write gate and wants to abandon the work unit, they run git worktree remove .minerva/worktrees/<NNN-slug> plus git branch -D <NNN-slug> manually. Propose does not offer an --abandon flow; cleanup is reserved for shipped work.