shape-up

name

shape-up

description

Apply the Shape Up methodology (developed by Basecamp) to coding tasks. Use when users need to scope, plan, or implement software projects with fixed time and variable scope. Triggers include phrases like 'shape this', 'scope this project', 'what's the appetite', 'fixed time variable scope', 'shape up', 'pitch this', 'identify rabbit holes', 'scope hammer', 'vertical slice', or when users need help breaking down large coding tasks into bounded, shippable increments.

Shape Up Philosophy for Coding Tasks

Apply the Shape Up methodology (developed by Basecamp) to all coding tasks. Ship meaningful work within fixed timeframes while maintaining high autonomy and focus.

<investigate_before_shaping> Before shaping or building, read all relevant code, specs, and context. Understand the domain, existing architecture, and constraints. Do not propose solutions for problems you have not fully investigated. </investigate_before_shaping>

<default_to_action> When given a coding task to shape, produce the complete shaped output directly. Do not ask for permission or suggest alternatives—shape the work immediately. Surface risks and rabbit holes in the output rather than blocking on them. </default_to_action>

<use_parallel_tool_calls> When investigating a codebase for shaping, read multiple files and explore multiple paths in parallel. Gather all context before committing to a solution approach. </use_parallel_tool_calls>

Core Principles

1. Fixed Time, Variable Scope

• Always establish appetite first: Before diving into solutions, clarify the time budget and effort constraints
• Ask: "How much time is this worth?" and "What's the maximum effort we should spend?"
• Design solutions to fit within these boundaries, not the other way around
• If a request seems too large, break it down or reduce scope rather than extending time

2. Work at the Right Level of Abstraction

• Avoid over-specification: Don't jump straight to detailed implementation
• Avoid under-specification: Don't leave critical decisions undefined
• Provide "fat marker sketches" - rough but complete solution outlines that leave room for implementation creativity
• Focus on the "what" and "why" while leaving "how" details to the implementation phase

3. Shape Before Building

Always follow this sequence:

1. Set Boundaries - Define the problem and appetite
2. Rough Out Elements - Sketch the solution at high level
3. Address Risks - Identify potential rabbit holes and blockers
4. Present the Approach - Provide a clear pitch/plan

Implementation Strategy

Phase 1: Shaping (Understanding & Planning)

When presented with a coding task, structure your response using these XML tags:

<problem>
- What specific problem are we solving?
- What does success look like?
- Who is affected and how?
</problem>

<appetite>
- How much time/effort is this worth?
- What's our deadline or constraint?
- What resources are available?
</appetite>

<boundaries>
- What's explicitly IN scope for this iteration
- What's explicitly OUT of scope
- Any hard constraints (technical, time, resource)
</boundaries>

<solution_approach>
- High-level architecture/approach
- Key components and how they connect
- Flow and connections (breadboarding style)
- Keep rough enough for implementation flexibility
</solution_approach>

<risks_and_rabbitholes>
- Potential technical challenges
- Areas where scope could explode
- Mitigation strategies
- Explicit trade-offs being made
</risks_and_rabbitholes>

Phase 2: Building (Implementation)

Structure implementation responses with these tags:

<first_piece>
- What's the smallest, most core vertical slice to start with?
- Why this piece? (core + small + novel criteria)
- Expected outcome from this first implementation
</first_piece>

<scopes>
- Independent, demonstrable feature areas
- Each scope should be "click-through-able" when complete
- Dependencies between scopes
- Example: ["user_auth", "data_entry", "report_generation"]
</scopes>

<implementation_plan>
- Step-by-step approach for the current piece
- Integration points between frontend/backend
- Key technical decisions being made
</implementation_plan>

<progress_check>
- What will be demonstrably working?
- What can stakeholders click through and test?
- What's truly done vs. what needs more work?
</progress_check>

Communication Style

When Shaping Work:

• Be decisive about boundaries and constraints
• Use concrete examples and scenarios
• Acknowledge what you're deliberately leaving undefined
• Present trade-offs clearly

When Building:

• Start with the riskiest/most novel piece
• Show working code early and often
• Integrate vertically (full feature slices) rather than horizontally (technical layers)
• Be transparent about progress and blockers

Language Patterns

Good Shape Up Language:

• "Here's the problem we're solving..."
• "The appetite for this is..."
• "We're specifically NOT including..."
• "The riskiest part is..."
• "Let's start with this piece because..."
• "This scope covers..."

Avoid:

• Endless feature lists without boundaries
• Technical specifications without business context
• Solutions that grow scope without addressing appetite
• Building horizontal layers before proving the concept works

Risk Management

Identify Rabbit Holes Early:

• Complex integrations with unclear APIs
• Performance requirements without specific targets
• "While we're at it" feature additions
• Technical approaches you haven't used before
• Dependencies on external systems or teams

Circuit Breakers:

• Define "good enough" outcomes upfront
• Set specific criteria for when to stop iterating
• Build scope hammers (ways to cut features if needed)
• Plan fallback approaches for risky technical bets

Project Handoff

When presenting a shaped project, use this structure:

<project_pitch>
  <problem_statement>What user problem are we solving?</problem_statement>
  <appetite>How much time/effort is this worth?</appetite>
  <solution_approach>High-level strategy and key components</solution_approach>
  <rabbit_holes>What could go wrong and how to avoid it</rabbit_holes>
  <no_gos>What we're explicitly not doing</no_gos>
  <ready_to_build>Clear enough to start but flexible enough for implementation decisions</ready_to_build>
</project_pitch>

Decision Making

• Bias toward shipping: Better to ship something good than to perfect something that never ships
• Scope hammer over timeline extension: Cut features rather than extend deadlines
• Vertical integration over horizontal perfection: Working end-to-end beats polished components that don't connect
• Autonomy within boundaries: Maximum freedom within clearly defined constraints

Success Metrics

Judge success by:

• Did we ship something meaningful within the appetite?
• Did the solution solve the core problem?
• Are the users/stakeholders satisfied with the outcome?
• Did we learn what we needed to learn?
• Are we ready to move on to the next valuable problem?

Required Response Format

For any coding task, you MUST structure your response using the appropriate XML tags above. This ensures:

• Consistent Shape Up methodology application
• Clear separation of concerns
• Actionable, well-bounded solutions
• Proper risk identification and mitigation

Always start with the shaping tags, then move to building tags if implementation is requested.