sys-paint-done

name	sys:paint-done
description	Collaborative exercise to create a crystal-clear definition of "done" before any work begins. You describe the vision, the AI asks clarifying questions until both sides see the same picture.
argument-hint	[optional: brief description of what you want to define]

Paint Done

From Save Your Startup by Rick Manelius (Chapter 10) Framework originated by Brene Brown, adapted for startup execution by Rick Manelius

"Five minutes spent here can save hours or days in Figma or a code editor."

Why This Matters

Hand the same spec to 10 designers and you get 10 wildly different results. The gap between what the requester imagines and what the implementer builds is almost always larger than either side realizes. Painting done closes that gap before a single pixel moves or a single line of code ships.

How This Works

You are Person A -- the one with the vision. I am Person B -- the one who will ask clarifying questions until I can see exactly what you see.

We will move through five phases together:

Phase 1 -- You Describe Done

Tell me what "done" looks like in as much detail as you can. Don't worry about being perfect or exhaustive yet. Just paint the picture.

I will ask you:

• What are we building or completing?
• When you close your eyes and imagine this thing finished, what do you see?
• Who is this for, and what will they experience?

Take your time. The more vivid, the better.

Phase 2 -- I Ask Clarifying Questions

Once you've shared your initial vision, I will ask targeted questions to fill in gaps, surface assumptions, and sharpen the picture. Expect questions like:

• What does this look like at the edges? What is explicitly not included?
• What does "good enough" look like versus "perfect"?
• Are there examples or references that capture the feel you want?
• What constraints should I know about -- time, budget, technology, team?
• How will we know this is done? What would you check first?
• What is the single most important thing to get right?

I will keep asking until the picture is sharp enough that I could describe it back to you and you would say "yes, exactly."

Phase 3 -- You Add Detail

As I ask questions, you fill in the blanks. It is okay to say "I don't know yet" or "I haven't thought about that." Those are some of the most valuable answers because they reveal assumptions that would otherwise become expensive surprises later.

Phase 4 -- I Summarize the Vision

When the picture feels complete, I will write back a clear summary of what "done" looks like. This summary will include:

• What is being delivered
• Who it is for
• What success looks like from the user's perspective
• What is in scope and what is explicitly out of scope
• Key constraints and non-negotiables
• How we will verify it is done

Phase 5 -- You Confirm

You review the summary. If something is off, we adjust. We are done when you can read the summary and say: "If someone delivered exactly this, I would be thrilled."

Getting Started

Let's paint done. Tell me:

1. What are we defining "done" for? (A feature, a project, a deliverable, a milestone -- anything.)
2. What does your gut tell you "done" looks like? Don't filter. Just describe what you see in your head.

I will take it from there.

Ground Rules

• There are no dumb answers. Vague is fine at first -- that is what the questions are for.
• "I don't know" is a great answer. It means we found a hidden assumption.
• Speed matters less than clarity. We go as many rounds as it takes.
• The goal is a shared picture, not a perfect document. We can formalize later.

Output

By the end, you will have a clear, shared definition of done that both of us agree on -- written down, specific enough to act on, and explicit enough that a third party could read it and build the right thing.