/kickoff: An Interview, Not a Prompt

You forked the repo. You have a working application — sidebar, header, protected routes, a design system, sign-in that works. You open supabase/migrations/ and it's empty.

That is not an oversight. It's the part of the product that took longest to decide.

The two bad ways to start

The blank repo. You describe your product to an agent and it writes something structurally plausible. It's a guess — and a different guess every session. Ask again tomorrow and you get a different tenancy model, a different naming convention, a different opinion about whether roles live on the user or the membership. The people selling against this say it plainly: "Don't let an agent invent your login system." They're right about the failure. I disagree about the fix.

The loaded starter. So you buy a boilerplate that already decided — accounts, memberships, roles, role_permissions, invitations, subscriptions. A complete tenancy model for a product nobody has described yet. If yours happens to be shaped like that, you saved a week. If it isn't:

"every boilerplate ships with some overcomplicated auth setup with 5 different providers pre-configured… but good luck ripping it out without breaking 20 other things that depend on it."

Both fail the same way. The schema gets decided by something that doesn't know what you're building — an agent that was never told, or a vendor who wrote it months ago for someone else.

A better prompt doesn't fix it

The obvious move is to write a longer prompt. It doesn't work, and the reason is precise: you don't know what you left out. Whether one record can belong to two groups. Whether an admin of one workspace should see anything in another. Whether the thing you called a "job" has states, and who's allowed to move it between them. Nobody puts those in a prompt, because they don't feel like decisions until something depends on them.

An interview gets them out — not because the questions are clever, but because a conversation notices a thin answer and asks again. A prompt cannot.

The four phases

/kickoff is a skill that ships inside Shells. You run it in the repo you just forked.

It talks first. One question — What are you building, and who is it for? — then it follows the thread. No questionnaire: the skill's own instruction is that its topic list is "a menu to draw from, not a script to run." It mirrors your vocabulary, because your words are the domain model and they should survive into the table names. It never asks you to design the database — that's how you end up back at a prompt. If you're escaping a spreadsheet, it asks for the column headers: your schema, already written, in your own words. It stops when it can describe the product back in a paragraph you'd sign off on, usually three to five exchanges.

It reflects it back. Before anything is written to disk, it says the product back to you and asks: What did I get wrong? People correct a draft far more readily than they answer an open question, so a slightly-wrong summary beats a cautious one. It also forces assumptions out loud — "I am assuming invoices belong to a group and not to an individual user." That's the sentence that saves a rewrite, and the one a prompt never produces, because a prompt has no reason to admit it guessed.

It writes the brief. docs/BRIEF.md: what the product does and who for, roles, your core objects and what each is scoped to, the first slice, what's deferred — and what's still genuinely undecided, recorded as undecided rather than invented. The point isn't documentation, it's durable context. CLAUDE.md tells every agent to read it first, so future sessions start from the interview instead of re-deriving it, differently, every time.

Then it builds one wave. The brief becomes a checklist you cut before anything is written: the migration with RLS, row types, real navigation, a dashboard that reflects your product, one or two screens you'd demo. The governing instruction is to end with something you can click, not a schema and four empty pages.

The identity model is designed in that last phase, not inherited. Single-player gets an owner column. A team product gets a tenant table and a membership table, with role on the membership, never on the user — a global role column can't express "admin of A, member of B", and every workaround denormalises. And it answers what most starters quietly decide for you: how does someone get their first tenant? Auto-created at signup, invite-only and admin-provisioned are three different products. Shells ships no sign-up screen, so choosing the first means building one — which the skill says out loud rather than letting it look free.

What it refuses to do

• No files during Phase 1 — nothing is written while you're still working out what you meant.
• No invented requirements — a gap gets asked about, or recorded as open.
• Not the whole product in wave one — one working screen beats five stubs.
• No reaching for the service key to work around a policy — if RLS can't express the rule, the rule needs rethinking.

That last one matters more than it reads. An agent that will quietly escalate privileges to make something work will do it at 2am in week six, too.

Why this only works on an empty database

An interview that ends in a migration is only honest if there's nothing already there. If Shells shipped accounts, memberships and roles, the interview would be theatre — a conversation whose conclusion was written before it started.

Empty migrations are what make your answers load-bearing. When the skill asks whether your product has shared spaces, the answer genuinely determines whether those tables exist. Scope is the one decision that's expensive to reverse once there's data, which is exactly why it should come from a conversation with you rather than a vendor's default. The long version, including the strongest arguments against it, is why Shells ships zero database tables.