Módulo 1.3 · O Stack de Prompts é o Produto

🍰 As 6 camadas da stack

Discovery + identity + DESIGN + SKILL + metadata + side-files.

O que é

O system prompt enviado ao agente é construído por composeSystemPrompt() empilhando 6 camadas em ordem fixa:

Discovery directives — workflow do turn 1 (perguntas) e turn 2 (direção)
Identity charter — quem o agente é, anti-slop, junior-mode
DESIGN.md ativo — vocabulário visual escolhido pelo usuário
SKILL.md ativo — workflow do tipo de artefato
Project metadata — nome do projeto, plataforma, tom
Skill side-files — assets/template.html + references/*.md auto-injetados

Por que aprender

Cada camada tem um autor diferente: discovery vem do core do OD; identity é fixo da Anthropic huashu; DESIGN é da comunidade; SKILL pode ser sua. Quando você muda uma camada, precisa saber se as outras assumem comportamento ou se vão entrar em conflito.

Conceitos-chave

composeSystemPrompt(): função em packages/contracts/src/prompts/system.ts
Ordem é prioridade: camadas anteriores ganham se houver conflito
Injeção dinâmica: conteúdo de DESIGN/SKILL é lido por sessão
Deck framework: 7ª camada opcional, só quando skill = guizang-ppt

🔧 Por que componível

Cada camada é um arquivo, cada arquivo é editável.

O que é

"Componível" = você pode trocar uma camada sem reescrever as outras. Quer mudar só o vocabulário visual? Trocar DESIGN.md. Quer mudar só o tipo de artefato? Trocar SKILL.md. Quer afrouxar o anti-slop? Editar identity. Cada arquivo tem responsabilidade única e contrato estável com as outras camadas.

Por que aprender

No Claude Design tudo é interno e fechado. No OD, o produto é a composição. Saber componibilidade = saber customizar o agente para seu contexto sem fork: brand do cliente vira DESIGN.md específico, formato de deck do investidor vira SKILL.md específico, sem mudar uma linha do core.

Conceitos-chave

Single responsibility: SKILL define workflow, DESIGN define visual, identity define caráter
Hot-swap: trocar camada não exige restart do daemon
Read-only para o agente: agente lê camadas, não as edita
Contrato implícito: nomes de tokens (--bg, --accent) são compartilhados

📋 DISCOVERY directives — RULES 1, 2, 3

Turn 1 form → Turn 2 brand branch → TodoWrite.

O que é

A camada discovery.ts (263 linhas) define um protocolo conversacional obrigatório:

RULE 1 (Turn 1)

Antes de qualquer pixel, mande um question form: superfície, audiência, tom, contexto de marca, escala

RULE 2 (Turn 2)

Branch de marca: A=escolher direção, B=extrair brand-spec, C=improvisar

RULE 3 (Turn 3+)

TodoWrite plano visível, live updates, redirecionável

Por que aprender

Sem discovery, o agente simula trabalho em vez de fazer trabalho. RULE 1 trava decisões antes do CSS; RULE 2 evita inventar paleta quando o cliente já tem marca; RULE 3 deixa o usuário redirecionar antes de gastar tokens. É a parte do prompt que mais economiza retrabalho.

Conceitos-chave

Question form: 5-7 perguntas fechadas, formato consistente
Branch A/B/C: caminhos diferentes para "tem marca" vs "não tem"
TodoWrite: ferramenta de plano live (Claude Code-compatível)
Direções visuais: 5 templates (Editorial Monocle, Modern Minimal, Tech Utility, Brutalist, Soft Warm) — detalhe no Módulo 1.6
Override por usuário: "pula direto pro deck" desativa RULE 1

⚖️ Identity charter (OFFICIAL_DESIGNER_PROMPT)

Anti-slop fixo, junior-pass.

O que é

A camada de identidade (official-system.ts, ~118 linhas) define quem o agente é: um designer-engineer sênior, junior-pass mode (faz perguntas como júnior simulando sênior), com blacklist anti-slop hardcoded. Não é editado por usuário — é o caráter do produto.

Por que aprender

A maioria das "alucinações estéticas" vêm da ausência dessa camada em outros produtos. Quando o agente "decide sozinho" usar Inter como display ou gradient roxo, não é o modelo errando — é falta de identity charter. Saber que esse arquivo existe e o que ele contém = saber por que o OD não cai nessas armadilhas.

Conceitos-chave

OFFICIAL_DESIGNER_PROMPT: string exportada em official-system.ts
Junior-pass: agente faz perguntas em vez de assumir
Anti-slop blacklist: ~15 regras curtas inline
Não-customizável por padrão: exigiria editar o pacote contracts
Tom imperativo: "Never do X. Always do Y."

📎 Pre-flight de side-files

Auto-injeção de assets/template.html + references/*.md.

O que é

Antes do agente começar a escrever, o daemon faz "pre-flight": lê todos os side-files da skill ativa (assets/template.html, references/layouts.md, references/checklist.md) e injeta no prompt. O agente nunca "esquece" de seguir o template ou checar o checklist — porque já tá no contexto.

Por que aprender

Esse é o mecanismo que faz a diferença prática entre "OD tem skills" e "skills funcionam de verdade". Sem pre-flight, o agente teria que "lembrar" de abrir o template — coisa que LLMs falham 30% do tempo. Pre-flight = checklist mecânico, não confiando em memória.

Conceitos-chave

Side-files: arquivos auxiliares ao SKILL.md em assets/ e references/
Auto-injeção: daemon faz fs.readFile e concat no system prompt
Token budget: hard cap em ~8k tokens por skill (cuidado com side-files gigantes)
Cache: arquivos lidos uma vez por skill ativa em sessão
Diff hygiene: mudou template? cache invalida e injeta nova versão

🪜 Override hierarchy

Discovery domina sobre identity; metadata adapta.

O que é

Quando duas camadas dão instruções conflitantes, há uma hierarquia explícita de override: Discovery > Identity > SKILL > DESIGN > Metadata > Side-files. Discovery pode pausar a regra "no roxo" se o usuário explicitamente pedir — porque RULE de discovery está mais alta. Identity é next; só pula se discovery overridou.

Por que aprender

Sem hierarquia, conflitos viram comportamento aleatório. Saber a ordem permite prever o que ganha. Quando o cliente diz "aqui usa roxo", você confia que discovery vai aceitar (porque tem prioridade) e a identity charter não vai brigar — mesmo com a blacklist.

Conceitos-chave

Discovery wins: intent do usuário tem mais peso que blacklist genérica
Identity wins sobre SKILL: blacklist anti-slop não é apagada por skill nova
Metadata adapta: "platform: mobile" muda hit-targets, não cores
Side-files são autoritativos no escopo: template.html dita estrutura
Conflitos = escalar: agente reporta conflito ao usuário antes de decidir

🛠️ Hands-on

Mesmo sem o OD instalado, você pode ler o produto. Esse é o exercício mais útil deste módulo:

Abra os 3 prompts: system.ts, discovery.ts, directions.ts em packages/contracts/src/prompts/ do repo open-design.
Identifique cada camada: sublinhe ou anote onde começam discovery directives, identity charter, instruções de DESIGN/SKILL.
Encontre RULE 1, 2, 3: em discovery.ts, marque exatamente as 3 RULEs e o que cada uma exige.
Bonus: escreva um pequeno DESIGN.md do seu site favorito e veja se ele obedeceria à hierarquia (cores ganham? tipografia ganha?).

Listagem de prompts no repo

cd /caminho/para/open-design
ls -la packages/contracts/src/prompts/
wc -l packages/contracts/src/prompts/*.ts

📚 Fontes

No repositório

packages/contracts/src/prompts/system.ts (334L)
packages/contracts/src/prompts/discovery.ts (263L)
packages/contracts/src/prompts/official-system.ts (118L)
packages/contracts/src/prompts/directions.ts (284L)

Externas

Anthropic prompt-engineering guide
OpenAI: stable system prompts
huashu-design (origem do junior-pass)

📌 Resumo do Módulo

1. System prompt = 6 camadas empilhadas: discovery + identity + DESIGN + SKILL + metadata + side-files.

2. Componibilidade significa que cada camada é editável sem fork — esse é o "produto" do OD.

3. Discovery RULES 1/2/3 estruturam o turn 1 (form), turn 2 (branch), turn 3+ (TodoWrite).

4. Identity charter (OFFICIAL_DESIGNER_PROMPT) injeta caráter, junior-pass e blacklist anti-slop.

5. Pre-flight injeta side-files (template + checklist) antes do agente escrever — checklist mecânico.

6. Override hierarchy: Discovery > Identity > SKILL > DESIGN > Metadata > Side-files.

Próximo módulo:

Módulo 1.4 · Skills (SKILL.md) →

← Módulo 1.2 Módulo 1.4 →