Your first project

A repository (or "repo") is just the folder that holds all of your project's files plus its full history, every saved version, all the way back. A commit is one of those saved versions: a labeled snapshot you can always return to. Here's the good news: you don't have to make any of this yourself. When you name a new project, Sparkle creates the repo, wires up the history, and tracks the commits behind the scenes. Starting fresh? Just describe the idea, like "a habit-tracker with a calendar view." Already have a folder of code? Point Sparkle at it and it picks up right where you left off.

New project = fresh repository and workspace, set up for you. Got something already? Point Sparkle at the existing repo and it works in place, in real git, with real commits you can inspect. No proprietary black box, no lock-in. Name it, aim it, go.

New project initializes a git repository and workspace; or attach an existing repo and Sparkle operates on it in place. Nothing leaves your machine. Real git, real history, real commits, no proprietary sandbox pretending to be a workflow.

Here's the secret the pros know, and it's almost embarrassingly simple: the better you describe what you want before anyone writes code, the better the result. So Sparkle puts Think first, on purpose.

You sit down with Chief's AI thought partners and just talk it through, like brainstorming with a thoughtful friend who keeps asking "but what about…?" until the idea is sharp. Then Plan quietly turns that conversation into a checklist of tasks. Only then does Build start making the real thing, and even then, you get to look before you keep anything.

Jumping straight to Build feels faster. It almost never is. And if your first try isn't great? That's not failure. That's the normal, universal beginning of doing anything good:

Nobody tells this to people who are beginners… all of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it's just not that good… the most important thing you can do is do a lot of work.

So keep going. Think a little more, build a little more, and the gap closes. It always does.

You want to ship. Good, so do we. But the fastest way to ship something real is brutally simple: don't build the wrong thing twice.

That's what Think and Plan are for. Five minutes shaping a spec with Chief beats an hour watching agents confidently implement a feature you didn't actually want, then burning more tokens unwinding the mess. Think sharpens the idea, Plan turns it into ordered tasks, Build executes. Spec first, ship faster. Every time.

Talk is cheap. Show me the code.

Exactly. And the code worth showing is the code that does the right thing on the first pass. Think and Plan are how you get there once instead of three times.

Three phases, cleanly separated, no ceremony:

• Think = produce a spec/PRD. An interview-driven design pass with Chief's thought partners. Zero code mutation.
• Plan = a dependency-ordered task graph, generated from the spec via beads and superpowers. This is a real work breakdown, prioritized, not a vibe and a prayer.
• Build = orchestrated worker agents, each in its own isolated worktree and branch, executing tasks off the graph. You review diffs before anything merges.

What's genuinely useful here, and you'll feel it fast: the spec-to-task-graph step makes the agents' work legible and reviewable, and worktree isolation means you can fan out without cross-contamination. The gate is human review, exactly where it belongs and exactly where you'd put it.