Propose

Evaluate whether an idea is worth formalizing, and if so, write the proposal document. This sits between optional freeform exploration and the formal design artifact.

The proposal is a "why + high-level what + high-level how" document. Deeply understand and articulate the motivation — the problem, the opportunity, and why it matters now. Scope "what" at a high level — enough to bound the change and identify capabilities, but leave detailed behavioral requirements for specs. Sketch the high-level technical approach and architecture — enough to ground the change in reality and surface structural risks early — but leave detailed design for design.md.

Principles

• Conversational evaluation, documentary proposal — The evaluation phase is a conversation. The proposal phase produces proposal.md. Keep these phases distinct.
• Research-informed — Before opining, investigate the codebase and web resources to ground advice in reality.
• Honest assessment — If an idea has problems, say so directly. "Not worth building" is a valid and valuable outcome. A brainstorm that only cheerleads is useless.
• Visual — Use ASCII diagrams liberally when they'd help clarify thinking: architecture maps, comparison tables, flow sketches.
• Why-first, then lightly — The proposal establishes motivation first, then scopes the change at a high level, then sketches the high-level technical approach. Dig into the problem deeply. Scope "what" enough to bound capabilities and identify what needs specs — but leave detailed behavioral requirements for specs. Capture enough architecture and key technical decisions to ground the proposal in reality — but leave detailed design, component internals, and implementation specifics for design.md.

Flow

1. Understand