lemurOS:brainstorming

lemurOS:brainstorming

Overview

Brainstorming is cheap. Rework is expensive. Before any creative work in a LemurOS-managed project, surface intent, constraints, and 2-3 candidate approaches with the user. No implementation begins until the user picks one.

When to use

• New feature request, new flow, new component, new agent skill.
• Ambiguous request ("make it nicer", "improve the kanban").
• A choice exists between approaches and the user has not picked one.
• Conflict with an existing invariant (PRD §5 Non-Goals, architecture §8.1) is plausible.

When NOT to use

• The user is reporting a bug — use lemurOS:systematic-debugging first.
• The plan already exists and is approved — use lemurOS:executing-plans.
• The user has explicitly asked you to skip and assume an answer — record their answer, proceed.

Hard gates

No implementation code is written until the user explicitly picks one of the proposed approaches.

No more than 5 clarifying questions per round. If you have more, prioritise; the rest can be asked in round 2.

If you find a conflict with PRD §5 Non-Goals or architecture §8.1 invariants, surface it as a question, not as a refusal. The user may want to override the PRD.

The loop

1. Clarify — ≤5 questions: scope, user, success, constraints, deadline.
2. Constrain — list hard constraints (invariants, prior decisions, deadlines) discovered.
3. Propose — 2-3 approaches; for each: one-line summary, key tradeoff, rough effort.
4. Recommend — pick one with rationale.
5. Confirm — explicit user pick. Record their pick verbatim.

Handoff

Output of brainstorming is a confirmed approach + constraint list + open questions, persisted directly to <project>/docs/specs/<YYYY-MM-DD>-<slug>.md using the Write tool (the project working tree is user/agent-writable per architecture §8.10). The vault mirror at vault/projects/<slug>/specs/ is updated by lemurOS:close-session at session end, or on demand via /lemur-os:sync.

Hand off to:

• lemurOS:writing-plans for multi-step work.
• lemurOS:interview for new-project / new-feature discovery.

Red flags - STOP and reconsider

Thought	Reality
"This is small enough to just build"	Small changes break invariants too. The PRD says light-mode-only; a "small" dark toggle violates §5.
"We already brainstormed this"	If there's no spec artefact in <project>/docs/specs/ or vault, you didn't. Conversational memory rots.
"I know what they want"	You know what they said. You don't know what they want until they confirm an approach.
"Let's just start and iterate"	Iteration on a wrong frame is wasted work. The frame is what brainstorming locks in.

Verdict

• DONE — user confirmed an approach; spec artefact captured.
• NEEDS_CONTEXT — user can't answer key constraint questions; pause until they can.
• BLOCKED — a hard requirement contradicts an architectural invariant and the user has not authorised overriding it.