Conducty Shape

Conducty Shape — Appetite, Boundaries, Design

Turn unclear or complex goals into bounded, executable designs. Shaping answers three questions before any prompt is written: How much is this worth? What's in scope? What's explicitly out?

This is not brainstorming in the open-ended sense. Shaping is opinionated — you propose boundaries, cut rabbit holes, and produce a design that fits the declared appetite. The output is a design doc that [[conducty-plan]] can decompose into prompts.

[!warning] Hard gate Do NOT generate prompts for a non-trivial goal until you have presented a design with appetite, scope, and no-go zones, and the user has approved it.

When to Use

Mandatory (invoked by [[conducty-plan]]):

• Goal is Medium or High complexity
• Goal spans multiple subsystems or projects
• Goal requirements are ambiguous or underspecified

Optional (user-triggered):

• User says "shape", "design", "brainstorm", "think through"
• User wants to explore approaches before committing

Skip when:

• Goal is Low complexity with clear requirements and obvious implementation
• Goal is a straightforward bugfix with known root cause
• Goal is a mechanical refactor with a clear before/after

The Shaping Process

Step 1: Set the Appetite

Before asking what to build, ask what it's worth.

"How much time should we spend on this? An hour? Half a day? A full day?"

The appetite is a hard constraint, not an estimate. If the design can't fit the appetite, cut scope — don't extend time. This prevents unbounded exploration and forces prioritization decisions early.

If the user hasn't thought about appetite, help them: "This feels like a half-day effort based on what you've described. Does that match your expectation?"

Step 2: Understand the Goal

Ask questions one at a time to understand what the user wants:

• Prefer multiple-choice questions — faster to answer, forces you to have a hypothesis
• One question per message — don't overwhelm
• Check the project context note first ([[Context {Project}]] in the vault — see [[conducty-obsidian]]) before asking questions the context already answers
• Focus on: purpose, constraints, what "done" looks like, who benefits

Keep it tight. You have the appetite as a constraint — don't spend 30 minutes of questions on a 2-hour task.

Step 3: Scope Check and Decomposition

Before designing, assess scale:

• If the goal describes multiple independent subsystems, flag this immediately
• Help decompose into sub-goals: what are the independent pieces, what order should they be built?
• Each sub-goal gets its own shaping cycle
• A goal that can't be decomposed to fit the appetite is too big

Step 4: Breadboard the Solution

Define the key components and how they connect — not wireframes, not full specs, just the essential shape:

• What are the main pieces?
• How do they connect?
• What are the critical interactions?
• What existing code is involved?

Think of this as a fat marker sketch — detailed enough to execute, abstract enough to leave room for the implementer to make tactical decisions.

Step 5: Identify Rabbit Holes and No-Go Zones

This is what separates shaping from open-ended brainstorming.

Rabbit holes — areas that could consume disproportionate time:

• Identify them explicitly
• For each: time-box it ("spend max 30 min on this") or cut it ("use the simple approach, don't optimize")
• If a rabbit hole is essential and can't be time-boxed, the appetite is wrong — renegotiate

No-go zones — what is explicitly OUT of scope:

• Write these down as carefully as what's IN scope
• "We are NOT building X" / "We will NOT handle Y in this round"
• No-go zones prevent scope creep during execution

Step 6: Propose Approaches

Present 2-3 approaches with trade-offs:

• Lead with your recommendation and explain why
• Frame trade-offs in terms of the appetite: "Approach A fits the appetite. Approach B is better but needs another half-day."
• Keep it conversational — this is a planning discussion, not a formal document