|
|
|
@@ -11,48 +11,12 @@ 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>
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
</HARD-GATE>
|
|
|
|
|
|
|
|
|
|
## Three Paths
|
|
|
|
@@ -89,17 +53,18 @@ 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 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.
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
## Red Flags
|
|
|
|
|
|
|
|
|
|
| Thought | Reality |
|
|
|
|
|
|---------|---------|
|
|
|
|
|
| "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. |
|
|
|
|
|
| "This is too simple to need a design" | Simple means a short design, not no design. Two sentences in chat, then approval. |
|
|
|
|
|
| "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. |
|
|
|
|
|
Jesse Vincent