📐 Planning and architecture
The commands in family 06: turn an objective into a plan with verifiable steps, map dependencies, design the structure, and wrap everything in a repeatable procedure.
🏗️ /blueprint — turn an objective into an executable plan
The parent command for family 06. It takes an objective and returns steps, dependencies, resources, owners, metrics, risks, and the next action — the seven fields that separate a plan from a wish list.
🧱 The 7 fields in a blueprint
- •Steps: each one with a named deliverable — "published landing page," not "work on the landing page."
- •Dependencies and resources: what needs to exist beforehand and who/what gets used.
- •Metrics and risks: how to know it worked and what could bring it down.
- •Next action: the one thing you can do today — without it, the plan is just decoration.
New here? Deliverable is a deliverable that either exists or doesn’t: a file, a live page, a signed contract, a target number reached. If you can’t point to it and say "it’s here," it’s not a deliverable, it’s an activity.
🎯 Copy and run
/blueprint para <objetivo em uma frase, com prazo>; etapas com entregável, dependências, recursos, responsável, métrica de sucesso, 3 riscos e a próxima ação de hoje
How to verify: each step has a noun (the deliverable), and the "next action" fits into an afternoon — if it takes a month, it's a disguised step.
✓ Executable blueprint
- ✓"Step 2: registration form live, tested with 5 people — depends on step 1, owner: Ana, by 12/09."
- ✓Next action: “create the form in Tally and send the link to the group.”
✗ Wish list
- ✗"Phase 2: engage the community" — no deliverable, no owner, no date.
- ✗Next action: “align with the team”—a meeting isn’t an action; it’s postponement with an agenda.
🗺️ /roadmap + /milestones — verifiable sequence
/roadmap organizes the plan in the time — horizons, milestones, and deliverables in sequence. /milestones defines the milestones with completion criterion: a point where you can say "we’ve arrived" without debate.
Time horizons, not exact dates
Now (2 weeks) · Next (1-2 months) · Later (quarter). The farther out, the thicker the line.
Milestones with binary criteria
"Milestone 1: 10 paying customers" — reached or not reached. "Milestone 1: mature product" isn’t a milestone, it’s an opinion.
Deliverables aligned with milestones
Each milestone drives 2-4 deliverables that make it possible. A deliverable without a milestone above it is a candidate for removal.
🎯 Copy and run
/roadmap /milestones para <projeto>; horizontes agora/em seguida/depois, 3-5 marcos com critério binário de conclusão e as entregas que cada marco exige
How to verify: you can strike out a milestone without calling a meeting to decide whether it was reached.
💡 Practical tip
Ask for the roadmap with the question "what needs to be true in 30 days for the 90-day milestone to be possible?" This forces the model to work backward — and exposes optimistic milestones.
🔗 /dependencies — map prerequisites
Identifies prerequisites, blockers, execution order, and external dependencies — those outside your control, and therefore in charge of the entire schedule.
New here? Critical path is the longest sequence of dependent tasks in the project. Any delay along it delays the end; a delay outside it may change nothing. Knowing where it runs tells you where attention is worth spending.
| Type | Example | What to do |
|---|---|---|
| Internal, under control | Landing page depends on the offer copy | Sort; start with the blocker |
| External, predictable | Payment gateway approval (5-7 days) | Launch on day 1, in parallel with everything else |
| External, unpredictable | Partner response / API release | Plan B declared before you need it |
Teaching example: the unpredictable external dependency is what determines whether the deadline is realistic.
🎯 Copy and run
/dependencies para <plano ou lista de etapas>; classifique cada dependência como interna, externa previsível ou externa imprevisível, marque o caminho crítico e sugira o que disparar hoje
How to verify: external factors appear at the top of the "act today" list — if they're at the bottom, the map is upside down.
👥 /resources — estimate people, data, and budget
Estimates people, tools, data, budget, infrastructure, and knowledge necessary. The last category is the one everyone forgets — and the one that causes the most delays.
🧰 Six categories, one question each
- •People: how many hours from whom, in which week?
- •Tools and infrastructure: what we already have, and what requires a subscription or setup.
- •Data: do they exist, are they clean, can someone access them?
- •Budget: how much cash goes out before the first return?
- •Knowledge: what no one here knows how to do yet — and how long it takes to learn or hire for it.
🎯 Copy and run
/resources para <plano>; estime por categoria (pessoas, ferramentas, dados, orçamento, infra, conhecimento), marque o que já existe vs. o que falta e o gap mais caro
How to verify: the “knowledge” column isn’t empty. If it is, the model assumed your team knows everything — and it doesn’t.
📊 40% rule
Initial effort estimates for software and content projects tend to run 30% to 50% over—even on experienced teams. It’s not a moral failing; it’s an asymmetry: what we don’t know we don’t know isn’t counted. Ask for the estimate, then ask, “What would make this cost twice as much?”
🧱 /architecture — design components and interfaces
Define components, interfaces, flows, responsibilities, and structural decisions. This applies to software, but also to an operation, a course, or a business: anything with parts that interact has architecture.
Illustrative: family 06 is an assembly line—the goal goes in vague and comes out as a verifiable routine.
New here? Interface is the contract between two parties: what one delivers and what the other expects to receive. A component without a defined interface becomes "we’ll figure it out later" — and "later" is where projects die.
🎯 Copy and run
/architecture para <sistema, produto ou operação>; liste componentes com responsabilidade única, as interfaces entre eles (o que entra, o que sai), os fluxos principais e as 3 decisões estruturais mais difíceis de reverter
How to verify: each component has ONE responsibility described in one sentence. If it needs "and also," it's two components.
💡 Practical tip
Ask for the "hard-to-reverse decisions" separately from the rest. The database, language, payment platform, and pricing model deserve a red team (Track 3); the button label does not.
🔄 /workflow — process with states and flows
Turns the process into states, inputs, actions, decisions, outputs, and exceptions. The difference from a pretty flowchart is in the last word: exceptions. A process without mapped exceptions breaks on the first Tuesday.
✓ Working workflow
- ✓Each state has a name ("awaiting payment") and a clear exit condition.
- ✓Expected exceptions: "payment declined → notify in 1h, retry in 24h, cancel in 72h".
✗ Decorative flowchart
- ✗Boxes with vague verbs (“process,” “analyze”) and arrows without conditions.
- ✗Happy path only—the error has to figure out where to go on its own, usually to the owner’s inbox.
🎯 Copy and run
/workflow para <processo recorrente>; estados nomeados, entrada e saída de cada um, decisões com condição explícita e as 5 exceções mais prováveis com o que acontece em cada uma
How to verify: you can map the workflow without asking anyone who operates it — and the exceptions cover what went wrong in the last 30 days.
📋 /SOP — repeatable standard procedure
Turns a recurring process into repeatable steps, controls, and quality criteria. SOP (Standard Operating Procedure) is what lets someone else—or an agent—do the task the same way you do, without you.
New here? SOP (Standard Operating Procedure, a standard operating procedure) is the complete recipe for a recurring task: numbered steps, what to check at each one, and how to know the result is good. It’s the document you hand over when you’re truly delegating.
Trigger and preconditions
When this SOP runs (“every Monday at 9 a.m.,” “when a request is received”) and what needs to be ready beforehand.
Numbered steps with control
Each step ends with a 5-second check: “confirm that the email arrived in the test inbox.”
Quality and escalation criterion
How to know it’s good—and who to contact when something goes off plan.
🎯 Copy and run
/SOP para <tarefa recorrente>; gatilho, pré-condições, passos numerados com controle em cada um, critério de qualidade do resultado e regra de escalonamento
How to verify: hand the SOP to someone who has never done the task and leave the room. If they come back with a question, the corresponding step is incomplete.
⚠️ SOP no one opens
A 12-page SOP is a zero-page SOP. If the procedure doesn’t fit on one screen per run, split it in two—or automate the mechanical part (Module 4.2, /automate).
✅ /checklist + /sequence — check and optimize the order
/checklist generates objective items to prevent omissions before, during, or after execution. /sequence finds the shortest sequence of steps that unlocks a result or real learning — the antidote to plans that start with the logo.
🎯 A good checklist vs. a to-do list
- •Binary item: "DNS propagated (dig returns the new IP)" — yes or no, no "in progress".
- •Right timing: pre-flight (before), in-flight (during), post-flight (after). Mixing the three undermines adoption.
- •Short: 5 to 12 items. More than that, and it becomes a form nobody reads.
🎯 Copy and run
/checklist /sequence para <lançamento ou entrega>; checklist pré/durante/pós com itens binários, e a menor sequência de passos que gera o primeiro resultado ou aprendizado verificável
How to verify: the first step in the sequence produces something you can show someone today — not "set up the environment."
💡 Composite recipe
Combine with Track 3: /chain(/blueprint -> /premortem -> /checklist). The premortem finds how the plan could fail; the checklist turns each failure mode into a verification item.
Quick self-check (optional): what makes a plan step "executable" according to /blueprint?
🎓 Module Summary
Next Module:
4.2 - Execution and operations — the plan is ready; now it needs to become today's action, owner, priority, and monitoring.