Gru — The Software Design Document Engine

// SLIDE 01 — HOOK

The minions are very, very eager.

Gru doesn't build the rocket. Gru designs the mission, assigns the minions, checks their work, and takes responsibility for the outcome.

The minions are Claude. They are Cursor. They are enthusiastic. They will build anything.
They will build exactly what they understood you to mean.
That gap — between what you meant and what they understood — is where all the damage lives.

// The question is not whether your minions are capable. The question is whether you have been precise enough about what to build.

// SLIDE 02 — LEARNING OUTCOMES

What you will be able to do.

By the end of this deck, you will be able to…	Bloom's Level
Explain the Gru/Minions model and identify which role you are playing at any moment in an AI-assisted build	Understand
Define the solve-verify asymmetry and explain why human supervisory judgment becomes more consequential as AI capability scales	Understand
Define boondoggling and distinguish it from random prompting	Analyze
Name all five supervisory capacities and assign each to a concrete action in a real build	Apply
Execute the Gru /v1 intake conversation before writing a single line of code	Execute

// The last outcome is the one that matters today. If you run /v1 before you open your editor, this deck worked.

// SLIDE 03 — THE PROBLEM

You didn't build that. You approved it.

Claude wrote the code. You watched it write the code. You pressed Enter again.

There is no architecture. There is no test plan. There are no decisions — only outputs.
Something works. Something else is subtly wrong. You don't know which is which.
The prompts are random. The sequence is improvised. The handoffs are "looks good to me."
This is called vibe coding. It is not a workflow. It is an abdication.

// The problem is not that you used AI. The problem is that you used AI without deciding what to build first.

// SLIDE 04 — THE METAPHOR

Gru doesn't touch the equipment.

GRU — That's You

Designs the mission before the minions touch anything

Assigns each task to the right labor with explicit constraints

Decides what the mission is — not just how to execute it

Checks outputs before the next step begins

Takes full responsibility for the outcome

MINIONS — Claude, Cursor, Copilot

Excellent. Enthusiastic. Ready right now.

Execute exactly what they understood you to mean

Cannot reframe a poorly specified task

Will not stop and ask "are you sure?" before building

Get faster every year. Do not get wiser.

// "Which role am I being right now?" — ask this at every decision point in a build.

// SLIDE 05 — PAUSE & REFLECT

Stop. Think back.

PAUSE.

Think about your last AI-assisted build. At which moments were you Gru — making real decisions, setting direction, verifying outputs? At which moments were you just pressing Enter?

// CHECK FOR UNDERSTANDING — 01 OF 03

// SLIDE 06 — THE ASYMMETRY

AI solves faster every year. That gap will not close.

AI SOLVES Faster Every model iteration. Every year. Asymptotically approaching instant.

HUMAN VERIFIES Irreducibly Structural. Not a skill gap. Not closeable by better prompts or faster models.

AI optimizes for the common and likely. It cannot verify whether its output is grounded in your domain reality.
AI cannot reframe a poorly formulated problem. Cannot interpret an accurate output in the wrong context.
As AI capability scales, the human supervisory role does not diminish — it becomes more consequential.

// The threat narrative — AI replaces engineers — gets the asymmetry exactly backwards. The verifier is doing the consequential work.

// SLIDE 07 — WHAT GRU IS

Gru is a Software Design Document engine.

01

Command-based pre-build thinking

A prompt-loaded tool that runs inside Claude. Forces the architectural conversation vibe coding skips: what problem? For whom? Under what constraints? What does success look like?

02

Two modes — interactive and silent

Interactive mode asks one question at a time, pushes back on weak input, holds phase gates. Silent mode (/silent) executes immediately — no gates, infers and notes assumptions inline.

03

Primary path: /v1 → SDD sections → /claude

Start with /v1 problem intake. Work through systems, domain, and scope. Run /claude to generate the Boondoggle Score — your sequenced build plan with explicit handoff conditions.

04

Not a code generator

Gru does not write your app. It makes you articulate what you're building and why — before the minions touch anything. The two-hour conversation before a line of code is not overhead. It is the work.

// SLIDE 08 — SDD WORKFLOW

Four phases. One document.

Phase 1 — /v1–/v4

Problem & VisionProblem intake, architecture principles, core flows, user needs, non-goals. The mission brief. Nothing else gets built until this is locked.

Phase 2 — /s1–/s4

Systems & ArchitectureComponent design, integrations, data model, edge cases, error handling. The blueprint for how the pieces connect.

Phase 3 — /d1–/d3

Domain & APIDomain model, API contracts, data flow. The formal specification the minions implement against.

Phase 4 — /p1–/p5

Scope & ProductionFeature list, risks, open questions, infrastructure, production readiness. The definition of done for the whole build.

// You don't have to run every phase before building. A partial SDD on a real problem beats a perfect SDD on a hypothetical one.

// SLIDE 09 — THE /v1 INTAKE

What Gru asks before you touch the keyboard.

Q1 — Problem

What problem are you solving?Not "build an app." What pain point, for whom, with what evidence it's real? A feature description is not a problem statement.

Q2 — User

Who is this for?User type, access level, technical sophistication. Gru will not proceed on "users." Audience determines every constraint that follows.

Q3 — Constraints

What constraints exist?Stack, timeline, team size, integration dependencies, non-goals. Minions need explicit boundaries — or they'll build past them.

Q4 — Success

What does success look like?A specific, testable criterion. Define done before building starts — not after you've shipped something that "seems to work."

Q5 — v1 Scope

What does v1 need to do?The minimum. Not the vision. The smallest version that proves the core assumption is real and the architecture can hold it.

// Gru pushes back on vague answers. That pushback is not an obstacle — it is the learning. Resistance at this stage costs an hour. Resistance at week 4 costs a rewrite.

// SLIDE 10 — PAUSE & REFLECT

Stop. Answer honestly.

PAUSE.

Think about a build you started recently. Could you answer all five of Gru's /v1 questions right now — precisely, without hedging? Which question would you have struggled with most?

// CHECK FOR UNDERSTANDING — 02 OF 03

// SLIDE 11 — FIVE CAPACITIES

Gru makes the five capacities visible.

Supervisory Capacity	Where Gru Forces It
[PA] Plausibility Auditing	Every Gru handoff condition requires verification before the next step — not a vibes check, a specific testable criterion.
[PF] Problem Formulation	/v1 is nothing but this. Deciding what the mission is before Claude sees a single line of context.
[TO] Tool Orchestration	The Boondoggle Score sequences every Claude task with explicit trust decisions and dependency ordering.
[IJ] Interpretive Judgment	Gru names which outputs require human accountability before they ship — and cannot be delegated to a minion.
[EI] Executive Integration	Holding all four capacities simultaneously toward a unified SDD — and making the final call when they conflict.

// The five capacities are abstract in a lecture. Gru makes them operational. Each command activates one or more — not as a reminder, but as a phase gate you cannot skip.

// SLIDE 12 — BOONDOGGLING DEFINED

Programming as conducting.

Boondoggling: conducting Claude through a build — assigning each task to the right labor, sequencing by dependency, with explicit handoff conditions between every step.

A boondoggle is not a workaround. It is not clever prompting. It is a decision about what Claude can be trusted to do at this step.
Every prompt is a specification. Every handoff condition is a definition of done.
Every human task names the supervisory capacity being exercised — [PA], [PF], [TO], [IJ], or [EI].
The /claude command generates the Boondoggle Score: the conductor's score, not the music.

// The word "boondoggle" is intentional. It is odd. It is memorable. It signals that this is a specific practice with a name — not just "being careful."

// SLIDE 13 — THE BOONDOGGLE SCORE

Who builds what. In what order. With what handoff.

Claude Task

Complete copy-pasteable prompt — a specification, not a delegation

Sequenced by dependency — no step precedes the thing it depends on

Explicit handoff condition: the testable criterion that must be true before the next step

Trust level assigned: execute blindly / review output / human must decide

Human Task

Names the supervisory capacity: [PA] [PF] [TO] [IJ] [EI]

Identifies the interpretive judgment Claude cannot make in this domain

Specifies what human accountability looks like before the step closes

Available at any SDD stage — a partial score beats no score

// The Boondoggle Score is not a build plan. The SDD is the music. The Score tells you who plays what, in what order, and when to listen for the wrong note.

// SLIDE 14 — HANDOFF CONDITIONS

Not "looks good to me." A definition of done.

Weak Handoff — Do Not Proceed

✗ "Looks right to me"

✗ "Seems to work when I test it"

✗ "Claude says it's done"

✗ "I ran it a few times and it was fine"

✗ "Nothing obviously broke in my last run"

Strong Handoff — Proceed

✓ "All three /api/auth routes return 200 in Postman with a valid token payload"

✓ "Token TTL is exactly 3600s — confirmed in decoded JWT, not assumed from docs"

✓ "Zero 4xx or 5xx in logs after 10 test runs across all user types"

✓ "Response schema matches the contract defined in /d1 exactly"

// The handoff condition is written before the step begins — not evaluated after. It is the answer to: "How will I know this step is actually done?"

// SLIDE 15 — PAUSE & REFLECT

Stop. Name the condition.

PAUSE.

What is the difference between a handoff condition and "looks good to me"? Name one build decision from your own experience where an explicit handoff condition would have caught something before it became a problem.

// CHECK FOR UNDERSTANDING — 03 OF 03

// SLIDE 16 — TWO MODES

Pick the mode that matches what you know.

Interactive Mode — Default

Gru asks one question at a time — no bulk intake forms

Pushes back on vague answers before accepting them

Holds phase gates — won't produce output until input clears

Reflects back a summary and confirms before acting

Use when: the brief is thin, the domain is new, the problem isn't fully formed

The pushback is the learning. The gate is not bureaucracy — it is the asymmetry being honored in practice.

Silent Mode — Append /silent

Executes immediately — no questions, no phase gates

Infers missing inputs from context and notes assumptions inline

Full output in one shot: blueprint, SDD section, Boondoggle Score

Any command: /v1 silent [context]

Use when: you know exactly what you're building, or iterating fast

Silent mode does not skip the thinking. It skips Gru asking you to do the thinking out loud. If you can't name the assumptions, use interactive mode.

// SLIDE 17 — HOW TO START

Paste the prompt set. Type /v1.

01

Get the Gru prompt set from your course materials

Open Claude. Create a new conversation. Paste the full Gru system prompt. The tool is now loaded — Gru is ready to run inside Claude.

02

Type /v1 and answer one question at a time

Do not paste your whole codebase. Do not ask for the full SDD at once. Gru runs in phases — answer the question in front of you before the next one appears.

03

When Gru pushes back, that is the learning

If Gru tells you your problem statement is a feature description, it's right. Resistance at this stage costs you one hour. Resistance at week 4 costs you a rewrite.

04

The conversation before a line of code is not wasted time

It is the difference between being Gru and being a very expensive minion. Gru does not write the code. Gru decides what the code needs to be — before the minions touch anything.

// SLIDE 18 — CLOSE

You are Gru.

SPECIFY CONDUCT VERIFY

The minions are excellent. They are enthusiastic. They will execute exactly what they understood you to mean. Your job is not to type less. Your job is to decide more precisely.

Every prompt is a specification. Every handoff is a decision. Every build is a performance — and the conductor doesn't play an instrument.

// Irreducibly Human · Conducting AI · Northeastern University College of Engineering