conducty-shape

name	conducty-shape
description	Defines appetite, scope, no-go zones, and design before any prompts are written. Use when a goal is Medium or High complexity, requirements are unclear, scope needs bounding, or the user says "shape", "design", "brainstorm", "think through".
aliases	["conducty-shape","shape"]
tags	["conducty/skill","conducty/shape"]
cluster	conductor
version	1.0.0
origin	robertbarclayy/conducty (MIT)

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

Step 7: Present the Design

Once the approach is chosen, present the design:

• Scale each section to its complexity — a paragraph for simple parts, more detail for complex parts
• Ask after each section: "Does this look right so far?"
• Be ready to revise

Design for isolation and clarity:

• Break into units with one clear purpose each
• Well-defined interfaces between units
• Each unit should be testable and understandable independently
• Smaller units are easier for agents to implement reliably — a file that can be held in context produces better results than one that can't

Working in existing codebases:

• Explore the current structure (use Glob/Grep) before proposing changes. Follow existing patterns.
• Where existing code has problems that affect the work, include targeted improvements as part of the design
• Don't propose unrelated refactoring. Stay focused on what serves the current goal.
• Identify characterization needs: which existing behavior must be verified before changes begin?

Step 8: Save the Design Note

Write the approved design to the vault as Designs/Design YYYY-MM-DD HHmm {Topic Title Case}.md (see [[conducty-obsidian]] for full conventions). The timestamp matches the plan that will consume the design.

---
type: design
date: YYYY-MM-DD
time: HHmm
topic: {Topic Title Case}
project: {project-name}
appetite: {time budget}
tags: [conducty, conducty/design]
---

# Design: {Topic}

**Goal**: {one-sentence goal}

## Approach
{chosen approach and why}

## Components
{what gets built/changed, with file paths where known}

## Acceptance Criteria
- {criterion 1 — concrete and verifiable}
- {criterion 2}

## No-Go Zones
- {what is explicitly out of scope}
- {what we are deferring}

## Rabbit Holes
- {area of risk} — {mitigation: time-box or cut}

## Characterization Needs
- {existing behavior to verify before changing}

## Trade-offs
- Chose: {what we chose}
- Traded away: {what we gave up and why that's acceptable}

## Testing Strategy
{how to verify the whole thing works}

## Related

- Index: [[Designs Index]]
- Project: [[Context {Project}]]
- Consumed by: [[Plan YYYY-MM-DD HHmm {Topic}]]

Then prepend the new design's wikilink to [[Designs Index]] (Edit, not Write).

Step 9: Return to Planning

Hand control back to [[conducty-plan]] with:

• The design note wikilink (e.g. [[Design 2026-04-27 0930 Auth Cleanup]])
• The acceptance criteria (become prompt verification steps)
• The components list (become individual prompts)
• Suggested decomposition: which components are parallel vs. sequential
• The appetite (constrains prompt count and time budgets)
• The no-go zones (included in each prompt to prevent scope creep)

Core Principles

Fixed time, variable scope

Shape Up (Singer) — The appetite is a circuit breaker. When the design doesn't fit, cut scope — never extend time. Half-finished prompts all need rework.

The boundaries ARE the design

Shape Up (Singer) — What you exclude determines the shape more than what you include. Write no-go zones first, then scope what remains.

One bet per question

The Pragmatic Programmer (Hunt & Thomas) — Every question should carry a hypothesis. Prefer multiple choice. One per message. Exhaust what you know before asking what you don't.

Rabbit holes are budget items, not risks

Shape Up (Singer) — Time-box it or cut it. A rabbit hole without one of those is an unbounded liability in the plan.

Fat marker over fine tip

Shape Up (Singer) — Design at components, interfaces, and data flow. Finer than that and the agent fights you when reality diverges. Vaguer and the agent invents scope.

Separate what changes from what doesn't

Working Effectively with Legacy Code (Feathers) — Find the seam before you cut. Characterization needs go into the design doc before components do.

Decompose until each piece fits one prompt

A Philosophy of Software Design (Ousterhout) — If a component can't be one prompt with clear criteria, file paths, and a verification command, it's too big. Split it.

Trade-offs are named, not buried

Designing Data-Intensive Applications (Kleppmann) — "We chose X over Y because Z." A design that claims no trade-offs hasn't been examined.

Kill your darlings early

The Mythical Man-Month (Brooks) — The most valuable shaping output is often the feature you decided NOT to build. Shaping is cheap. Execution is expensive.