Meet Gru & Scope Your App: The /v0 Gate

Meet Gru & Scope Your App: The /v0 Gate

Gru is a software-design-documentation system built on the Irreducibly Human curriculum. You load it as a Claude Project with the Gru system prompt, or you paste the prompt directly into a new session and run /help to confirm it loaded. When /help returns the list of phase commands — /v0 through /s1 — Gru is active. It is not a chatbot. It is a phase-gate engine: it will not move forward until each gate passes. That distinction matters. A chatbot will accept a vague idea and generate something that looks like output. Gru will refuse and tell you exactly what is missing. The gates are: /v0 name

Every claim in this video was fact-checked against the source chapter and primary sources before rendering.

youtube.com/@NikBearBrown

Transcript

A lightly formatted transcript of the video, with timestamps so you can jump to any section on YouTube.

[0:00] Ciao, this is Liam, episode one of four. Before you can evaluate an AI system, you have to specify one precisely. Groo is the fastest way to build that muscle, and its first gate will stop a vague idea cold. Good. This week runs in four episodes. Scope your app in Groo, build the full SDD, generate and read the boondoggle score, then write the reflection and ship. Every episode has a concrete deliverable. This one has one job. Your app passes the /v0 gate. Let's go. Groo is a software design documentation system built on the irreducibly human curriculum. You load it as a Claude project with the Groo system prompt, or

[0:33] You paste the prompt directly into a new session and run /help to confirm it loaded. When /help returns the list of phase commands /v0 through /s1, Groo is active. It is not a chatbot. It is a phase gate engine. It will not move forward until each gate passes. That distinction matters. A chatbot will accept a vague idea and generate something that looks like output. Groo will refuse and tell you exactly what is missing. The gates are /v0 names the thing being built. /v1 through /v4 build the problem summary, principles, flows, and need statements. /s1 assembles the full software design document. Each gate requires the previous one to pass. You

[1:09] Cannot jump to /s1 from /v0. The order is the curriculum. Before you run /v0, you need an app worth scoping. Good candidates share three properties: a specific domain, a specific user making a specific decision, and an output that is a document, score, flag, or structured artifact, not a conversation. Examples: a finance claim flagger that checks submitted invoices for policy violations, an annotation tool that routes ambiguous medical images to the right reviewer, a clinic scheduler that assigns appointment slots based on patient triage priority, a moderation dashboard that surfaces borderline posts for human review, a test generator that produces domain-specific assessment questions from a syllabus, a calibration

[1:50] Tracker that monitors how a team's confidence scores compare to their outcomes. Anti-patterns: an AI assistant for X, too broad, no insertion point, no output you can test. Two or three generic components, too simple, Gru will flag the missing domain knowledge immediately. And thin domain knowledge, if you cannot describe the domain's edge cases, the SDD will expose that. The test before you run {slash} v0, can you name the domain, the user, the decision, and the output in one sentence? If you need two sentences, the scope is still loose. Run {slash} v0, the gate asks you to name the thing being built, not the problem it solves, not the user it

[2:25] Helps, but the thing itself. The exact naming convention, a noun phrase that describes the artifact or system, followed by its insertion point, followed by its output. A claim flagging tool that sits between the invoice intake form in the payment queue, and produces a binary pass or flag with a violation reason passes. An AI that helps finance teams with compliance does not pass. It names a problem, not a thing. If the gate stops you, that is the assignment working. Do not argue with Gru's pushback. Rewrite the one-sentence naming until it is specific enough that the gate passes. Every rewrite is progress. You are learning to specify, not to negotiate. The students

[3:01] Who get frustrated by {slash} v0 pushback are the same students who will miss the scores' hardest handoffs in episode 3. The gate is training your eye. Verdict for Meet Gru and Scope Your App. Gru is a phase gate engine loaded as a cloud project or paste the system prompt and confirm {slash} help. {Slash} v0 names the thing being built, not the problem it solves. Noun phrase, insertion point, output. Pushback is evidence the gate is working. Write, don't argue. Good candidates: finance flagger, annotation router, clinic scheduler, moderation dashboard, test generator, calibration tracker. Anti-patterns: an AI assistant for X, too few components, thin domain knowledge, one deliverable, screenshot

[3:39] Of the past {slash} v0. That screenshot is your week one starting artifact. Your turn. Paste this prompt into Gru with your own app filled in. The prompt reads, "I want to build a app name. The domain is domain. The user is role. The system takes an input and produces output, not a decision, an artifact, a flag, a score, a document, a queue entry. Run {slash} v0. If you get pushback, don't argue. Rewrite the one sentence naming until the gate passes. End quote. That's the full prompt. Fill in the four brackets before you send it. If you're stuck on the output field, remember, the output is never a

[4:09] Recommendation or a result. It is the specific artifact the system writes to the world. A PDF, a binary flag with a reason field, a ranked list with confidence scores. After the gate passes, take a screenshot of the past {slash} v0 exchange. That's your week one starting artifact and the foundation for every episode that follows. Meet, groom, and scope your app the {slash} v0 gate. Lay them in for bare.