1.4 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback-stream-of-thought-design | Mike prefers free-form stream-of-thought design conversations; Claude captures and decomposes them into specs only if/when he decides to build. |
|
Mike likes to brainstorm features as free-form, stream-of-thought conversations,
adding and refining requirements iteratively across several messages. He wants Claude
to absorb the discussion, validate and sharpen the ideas (surface architectural
trade-offs, name the real decisions, push back when an instinct fights the
architecture), and then break it into implementable parts (a /shape-spec) only
if/when he explicitly decides to build it.
Why: He thinks out loud and trusts Claude to do the structuring later. Forcing premature structure, or jumping to implementation mid-brainstorm, gets in his way.
How to apply: During these conversations, engage as a design partner, not an
order-taker — but do NOT start building. When he says to park it, capture the
discussion durably (e.g. a PARKED_*.md doc in the relevant repo, plus coord todos)
with the decided shape + open decisions, so a future session can spec it cleanly. The
2026-06-07 alert-lifecycle redesign + tiered telemetry cadence threads are an example:
parked to projects/msp-tools/guru-rmm/docs/PARKED_alert-lifecycle-and-telemetry-cadence.md.
Related: feedback-dashboard-beta-first.