|
|
@@ -11,12 +11,48 @@ Start by classifying how much process the request needs, then work
|
|
|
through your path: understand the context, refine the idea, present a
|
|
|
design, and get your human partner's approval.
|
|
|
|
|
|
+## Establish Shared Understanding
|
|
|
+
|
|
|
+The outcome of brainstorming is an understanding your human partner can
|
|
|
+recognize and correct, grounded in what they want to accomplish.
|
|
|
+
|
|
|
+1. **Discover intent.** Use the request and available context to identify
|
|
|
+ the intended outcome, who it is for, and what success looks like. When
|
|
|
+ that information is missing, ask one focused question about purpose or
|
|
|
+ intended use before proposing features or an approach. Knowing the app
|
|
|
+ genre does not tell you why your partner wants it. Gathering missing
|
|
|
+ requirements does not ask them to authorize the task again.
|
|
|
+2. **Write back your understanding.** Summarize the intended outcome,
|
|
|
+ relevant constraints, and success criteria in a short note your partner
|
|
|
+ can assess. Separate what they said from assumptions. Invite correction
|
|
|
+ and incorporate their answer before treating this as the design brief.
|
|
|
+3. **Carry intent into the design.** Preserve the agreed understanding in
|
|
|
+ the selected path's design artifact: the written spec for architectural
|
|
|
+ work, or the in-chat design/probe for bounded work and spikes. Check
|
|
|
+ proposed features and technical choices against that understanding.
|
|
|
+
|
|
|
+When the request already supplies the purpose and constraints, reflect
|
|
|
+that understanding instead of asking the same questions again. Keep the
|
|
|
+note concise; its accuracy and the opportunity to correct it matter.
|
|
|
+
|
|
|
<HARD-GATE>
|
|
|
-Do NOT invoke any implementation skill, write any code, scaffold any
|
|
|
-project, or take any implementation action until you have told your
|
|
|
-human partner what you intend and they have approved it. This applies
|
|
|
-to EVERY task on EVERY path below — the ceremony scales with the task;
|
|
|
-the approval gate never does.
|
|
|
+Before taking any implementation action, including invoking an
|
|
|
+implementation skill, writing product code, scaffolding, installing
|
|
|
+product dependencies, or creating an external project, complete the
|
|
|
+selected path's prerequisites:
|
|
|
+
|
|
|
+- Spike: the human partner approves the question and probe.
|
|
|
+- Bounded: the human partner approves the short in-chat design.
|
|
|
+- Architectural: the human partner reviews and approves the written spec,
|
|
|
+ then reviews the written implementation plan and selects its execution
|
|
|
+ method. Conversational design approval only permits writing the spec;
|
|
|
+ written-spec approval only permits invoking writing-plans.
|
|
|
+
|
|
|
+A reply approves the stage actually presented. Approval of an idea or
|
|
|
+feature scope does not approve artifacts that do not exist yet. Resume
|
|
|
+at the earliest incomplete stage; do not turn one approval into permission
|
|
|
+to skip the rest of the selected path. Read-only project exploration is
|
|
|
+allowed while those prerequisites remain incomplete.
|
|
|
</HARD-GATE>
|
|
|
|
|
|
## Three Paths
|
|
|
@@ -53,18 +89,17 @@ stop, say so, and step up. Nothing downgrades mid-task.
|
|
|
|
|
|
## Anti-Pattern: "Too Simple To Need Approval"
|
|
|
|
|
|
-Every path ends with your human partner approving your intent before
|
|
|
-implementation. A todo list, a single-function utility, a config
|
|
|
-change — the design may be two sentences in chat, but you MUST present
|
|
|
-it and get approval. "Simple" tasks are where unexamined assumptions
|
|
|
-cause the most wasted work. What scales with simplicity is the
|
|
|
-artifact, never the approval.
|
|
|
+Every path ends with your human partner approving the required design
|
|
|
+before implementation. A bounded change may need only two sentences in
|
|
|
+chat. A new todo-list project is architectural and requires the written
|
|
|
+spec and planning handoffs. Scale the artifact to the selected path;
|
|
|
+complete that path's reviews before implementation.
|
|
|
|
|
|
## Red Flags
|
|
|
|
|
|
| Thought | Reality |
|
|
|
|---------|---------|
|
|
|
-| "This is too simple to need a design" | Simple means a short design, not no design. Two sentences in chat, then approval. |
|
|
|
+| "This is too simple to need a design" | Follow the selected path: a bounded change gets a short chat design; an architectural change gets the written spec and planning handoffs. |
|
|
|
| "I'll call it bounded and skip the spec" | Reaching for a label to skip work IS the doubt — take the heavier path. |
|
|
|
| "It's bounded and the design is obvious — I'll start while they read it" | The gate is the approval, not the design's length. Present, then stop until you hear yes. |
|
|
|
| "I understand this kind of app, so it's bounded" | Bounded measures the repo, not your familiarity. A new project has no existing flow — it is architectural. |
|
Drew Ritter