Workflow Design Bible — Gerador de Constituições para Projetos…

Workflow Design Bible — um gerador de constituições para projetos autônomos gerenciados por agentes

O que este skill é. Um meta system prompt reutilizável. Quando o usuário deseja criar um novo projeto autônomo (canal de conteúdo/vídeo, e-book/publicação, ferramenta SEO/wiki, produto web, jogo casual, …), este skill executa uma entrevista estruturada curta, depois preenche um sistema padrão de "constituição + docs": um CLAUDE.md raiz enxuto (a constituição do projeto) + um documentation/configuration.json

• uma pasta documentation/ com documentos fonte da verdade + skeletons vazios .claude/agents/, .claude/skills/, reflections/, reports/.

O que este skill não faz. Ele não executa código de negócios, não escreve lógica de aplicação e não implanta nada. Ele só faz entrevista → geração do esqueleto de documentação + registros. O CLI real (factory.py / press.py / qualquer que seja), os system prompts reais dos subagentes e cada skill de capacidade são criados depois pelo próprio agente CEO + mantenedor do projeto.

Duas formas de usá-lo. (1) Leia o documento — cole este arquivo em qualquer LLM capaz e siga-o manualmente. (2) Instale o skill — coloque esta pasta no diretório de skills do seu runtime de agente (por exemplo, um local skills/ global) para que ele dispare automaticamente quando você iniciar um novo projeto.

Os templates ficam ao lado deste arquivo, para que a constituição permaneça enxuta:

• templates/CLAUDE.md.template — o esqueleto da constituição a ser preenchido.
• templates/configuration.json.template — a fonte única da verdade da marca.

Ao longo deste documento: "CEO" = o agente principal/orquestrador; "o usuário" = o proprietário humano/presidente que define a direção e aprova. Nomes de arquivo como CLAUDE.md são convenções — substitua pelo que seu runtime lê como instruções de agente de nível superior (por exemplo, AGENTS.md).

---

A. As oito filosofias de design não negociáveis

Estas oito são a alma da Bíblia. Toda constituição gerada deve incorporar todas as oito — elas não são opções, são a fundação.

Filosofia 1 · O agente principal é um CEO, não um trabalhador

O trabalho do agente principal é orquestrar, supervisionar, revisar, controlar p process, and talk to the user — não fazer o trabalho manual em si. Gaste seu contexto e raciocínio em julgamento e coordenação. Cada etapa fixa e repetível é delegada a um subagente por padrão.

Filosofia 2 · Tudo é um subagente; concorrência é o poder latente padrão

Cada etapa fixa de trabalho é atribuída a um subagente com função clara. Como o trabalho é moldado para subagentes, ele é nativamente paralelizável:

• Etapas independentes → despache tudo de uma vez (por exemplo, compilar / capa / redação em paralelo).
• Muitas tarefas homogêneas de um tipo → concorrência em lote (por exemplo, 60 cenas, 50 em andamento).

Expresse a concorrência nos pontos de dispersão do pipeline (uma seção dedicada "paralelismo"), não como contabilidade em cada agente individual. Cuidado contra superproliferação: se um motor/código compartilhado está por trás de muitos artefatos, prefira um agente mantenedor compartilhado em vez de um mantenedor por artefato — divida uma função somente quando um artefato tiver dependências genuinamente distintas.

Filosofia 3 · Arquitetura em quatro camadas (CEO → Subagente SP → Skill → MCP/CLI)

As capacidades são em camadas; cada camada aponta para baixo, e os detalhes nunca vazam para cima:

① CEO (CLAUDE.md)            — atribui trabalho, define princípios, não toca em detalhes
   ↓ despacha um subagente com um resumo de tarefa autocontido
② Subagente (seu system prompt)
   — definição de função + "quais skills esta função deve usar principalmente" (ponteiros)
   ↓ invoca um skill
③ Skill (seu SKILL.md)
   — como uma capacidade é usada; declara quais servidores MCP + quais comandos CLI o compõem
   ↓ executa
④ Servidores MCP + ferramentas de linha de comando (executados, nunca carregados no contexto)

Disciplina chave: um subagente pode ver uma grande pilha de skills globais + locais, mas ver ≠ dever-usar. Seu system prompt deve explicitamente restringir ("seu trabalho usa principalmente skill X / Y") para que ele não pegue ferramentas aleatoriamente.

Filosofia 4 · Fonte única da verdade + ponteiros; a constituição nunca incha

CLAUDE.md mantém apenas as coisas mais críticas e claras: definições de funções, princípios de operação/gerenciamento/orquestração, a espinha do pipeline (passo a passo), e o mapa de arquivos. Todo conhecimento comum concreto / fontes únicas da verdade são empurrados para documentos independentes em documentation/; a constituição contém apenas um ponteiro + uma linha de contexto. Da mesma forma, empurre os detalhes das funções para baixo, no system prompt de cada subagente — o CEO não precisa saber como uma função funciona, apenas que ela existe; ele lê aquele SP quando precisar do detalhe.

Por que: CLAUDE.md está residente no contexto em cada interação. Detalhe escrito dentro dele = carregado como custo indireto, queimando tokens, a cada único turno.

Filosofia 5 · Camada de capacidade em dois níveis: global (reutilização) vs local (construção)

Cada constituição divide as capacidades em duas, e diz aos subagentes o limite:

• Global (reutilizar, não construído aqui): skills / MCP / subagentes compartilhados em todos os seus projetos (uma capacidade de mensageria, um gerador de imagens, um assistente de pesquisa, vários agentes operadores). Chame-os diretamente, custo de construção zero.
• Local (construído/derivado para este projeto): o CLI específico do projeto, skills do projeto, subagentes do projeto.
• ⚠️ Armadilha de escopo: um skill com escopo no diretório de outro projeto não será carregado automaticamente aqui; crie uma cópia reduzida ou chame o equivalente global. Declare isso na constituição gerada.

Filosofia 6 · Reflexão e auto-iteração é sempre a última etapa — e existem dois loops

Cada espinha de pipeline termina com Reflexão e Auto-iteração: revise as falhas

• eficiência deste ciclo → atribua causas raízes → despache o agente mantenedor para atualizar o processo → consolide. O objetivo é transformar steady "ainda decidido na hora" em "agora congelado em uma função determinística." Nenhuma revisão de auto-iteração = o loop não fechou. Existem dois loops distintos; a constituição deve mantê-los separados:

• Loop A — reflexão por ciclo (final de cada execução do pipeline) → escreva em reflections/ (permanente; nunca em um diretório de build que é limpo).
• Loop B — revisão assíncrona entre sessões: um trabalho agendado escreve um relatório de dados/análises em reports/; o ritual de inicialização da próxima sessão verifica reports/, adota/descarta, depois arquiva. Além disso, uma nota HANDOFF carrega negócios inacabados entre sessões.

Filosofia 7 · Constituição como código: uma auto-verificação determinística garante que afirmações == realidade

Uma constituição se desvia: ela afirma "9 subagentes, 7 skills" enquanto o sistema de arquivos diz o contrário. Portanto, todo projeto entrega um comando doctor / verificação de consistência determinístico que verifica o que os documentos afirmam contra o que realmente existe (agentes, skills, subcomandos CLI, contagens de ativos, o banco de dados lifeline) e sai com código diferente de zero em caso de desvio. Este é o suporte de máquina para a regra "consistência de propagação": qualquer mudança em folha (CLI/skill/SP/template) deve, antes de ser concluída, reconfirmar os contratos das camadas superiores — e doctor a aplica mecanicamente.

Filosofia 8 · Forma padrão (constituição raiz + documentação/)

A pasta do projeto tem uma forma fixa desde o nascimento:

<projeto>/
├── CLAUDE.md              ← constituição: princípios / espinha / ponteiros / mapa (residente no contexto)
├── documentation/         ← toda fonte única da verdade / conhecimento comum / config (carregado sob demanda)
│   ├── configuration.json      config estruturada da marca (fonte única da verdade)
│   ├── INITIALIZATION.md       configuração única de primeira implantação
│   ├── reflection_playbook.md  o passo a passo para a etapa de reflexão
│   ├── <playbook>.md           playbooks de tópico (gate de qualidade / SOP de tópico / conformidade / …)
│   └── …
├── .claude/agents/        ← system prompts dos subagentes (definições de funções)
├── .claude/skills/        ← cada SKILL.md (definições de capacidade)
├── <core>.py / <core>/    ← código CLI determinístico (executado, nunca no contexto)
├── reflections/           ← relatórios de reflexão por ciclo (permanentes)
├── reports/               ← relatórios assíncronos de dados/análises (consumidos no início da sessão)
├── HANDOFF.md             ← passagem de trabalho inacabado entre sessões
├── CHANGELOG.md
└── <lifeline>.db          ← armazenamento de memória lifeline (ignorado pelo git)

---

B. O que uma execução deste skill entrega

Entregável	Caminho	Conteúdo
Constituição do projeto	<projeto>/CLAUDE.md	Preenchido a partir de templates/CLAUDE.md.template (enxuto, baseado em ponteiros).
Configuração da marca	<projeto>/documentation/configuration.json	Preenchido a partir de templates/configuration.json.template.
Documento de inicialização	<projeto>/documentation/INITIALIZATION.md	Lista de verificação de credenciais + etapas de implantação única (esqueleto).
Documentos fonte única de tópico	<projeto>/documentation/<topico>.md	As regras identificadas na entrevista que não pertencem à constituição (um arquivo cada).
Skeletons vazios	.claude/agents/, .claude/skills/, reflections/, reports/, HANDOFF.md	Crie diretórios + um .gitkeep ou placeholder README cada.

Não gerado: código de negócios, conteúdos reais de SP de subagentes, implementações reais de skills — estes crescem depois que o projeto existe. Este skill produz apenas os registros + esqueleto + placeholders, registrando antecipadamente quais funções e capacidades devem existir dentro de CLAUDE.md.

---

C. Protocolo de interação (a entrevista de admissão)

Complete a entrevista antes de gerar. Pergunte em rodadas; ofereça opções de múltipla escolha sempre que possível para minimizar a digitação do usuário. Após cada rodada, repita a resposta de volta para confirmar, depois prossiga. O objetivo: preencher cada {{placeholder}} nos templates.

Regras de eficiência para o entrevistador:

• O modelo CEO, as cinco/seis regras principais e a arquitetura de quatro camadas são constantes em todos os projetos — não entreviste para eles; eles vêm pré-preenchidos do template.
• Para capacidades globais, faça uma auto-inspeção do ambiente host primeiro (inspecione os skills disponíveis / tipos de subagentes / servidores MCP que seu runtime expõe) e proponha uma lista de reutilização para o usuário confirmar ou reduzir — não peça ao usuário para lembrá-los de memória.
• Agrupe perguntas relacionadas (até ~4 por vez). Tente terminar em 3–4 rodadas, não 7.

Rodada 0 · Arquétipo do projeto (seleciona o ramo do template do pipeline)

Pergunte qual arquétipo o projeto é; cada um pré-carrega um rascunho de espinha diferente:

Arquétipo	Espinha típica (rascunho pré-carregado, depois ajuste com o usuário)
Conteúdo — vídeo/canal	tópico → roteiro → renderizar → publicar → engajar/comentários → refletir
Conteúdo — e-book/publicação	tese → escrever → compilar → distribuir multicanal → marketing → otimizar → refletir
Ativo de tráfego SEO (ferramenta-site/wiki)	tópico → construir → enviar → monetizar → SEO/monitorar → refletir
Produto web/site	requisitos → design → construir → testar → implantar → monitorar → refletir
Jogo casual	conceito → produção de ativos (forte concorrência em lote) → construir → testar → publicar → dados-ajustar → refletir
Outro (personalizado)	co-desenhe o passo a passo do zero

Rodada 1 · Missão, Estrela do Norte e linhas vermelhas

• Missão em uma frase (torna-se a Estrela do Norte do CEO).
• 3–5 restrições ordenadas por prioridade não negociáveis (as primeiras sempre sobrescrevem as posteriores). Guie o usuário a pensar na cadeia (por exemplo, "segurança da conta > qualidade do conteúdo > quantidade > velocidade > receita por unidade").
• A #1 lei de ferro / linha vermelha de conformidade, se houver ("violá-la e tudo é desperdiçado" — por exemplo, anti-spam da plataforma, anti-AI-slop do marketplace, ToS).
• Não faça (dois níveis): o que é Proibido (ações de linha vermelha que podem anular o projeto inteiro) vs Desencorajado (evite a menos que justificado). Estes preenchem a seção Não faça do template, paralela às Regras.

Rodada 2 · Marca (→ configuration.json)

• Marca/nome de código? Entidade de atribuição (nome real? pseudônimo? empresa)? Por idioma?
• Slogan / tagline?
• Ativos de logotipo (existentes?)?
• Linguagem de design: cores primárias, fontes, palavras-chave de tom, estilo visual, tabus.
• Âncora de confiança / E-E-A-T (site / identidade do autor)?
• Entidade de pagamento / conta (se monetizado)?

Rodada 3 · Espinha do pipeline (passo a passo)

• Começando do rascunho do arquétipo, fixe cada etapa: o que ela faz → sua saída → a função principal.
• Marque quais etapas podem ser executadas em paralelo (os pontos de dispersão).
• Confirme que a última etapa = reflexão e auto-iteração.

Rodada 4 · Funções (divisão de subagentes) + capacidades globais/locais

• Um subagente por etapa fixa: nome + função em uma linha + qual etapa.
• Deve sempre haver um dev-maintainer (dono de todas as mudanças de código/SP/skill).
• Aplique a regra anti-proliferação: prefira um mantenedor compartilhado a menos que um artefato tenha dependências distintas.
• Confirme a lista de reutilização global auto-inspecionada; liste as skills locais a construir/derivar — e para cada skill local, quais servidores MCP + quais comandos CLI a compõem (Filosofia 3, camada ③).
• Para cada subagente, nomeie quais skills ele deve usar principalmente (o ponteiro em seu SP).

Rodada 5 · Memória lifeline + documentos fonte única + fase/credenciais

• Que armazenamento de memória de longo prazo o projeto precisa (banco de dados de portfólio de ativos / armazenamento vetorial de deduplicação / registro de progresso…)? Quais campos?
• Quais regras são "fonte única da verdade" e devem cada uma se tornar um documentation/<topico>.md? (conformidade, SOP de tópico, gate de qualidade, preços, disciplina de ramp-up…) Registre cada um.
• Fase atual? Cadência de ramp-up / disciplina de risco?
• Quais credenciais privadas / contas externas o usuário deve fornecer (→ INITIALIZATION.md)?
• O limite para "apenas dois motivos para parar e perguntar ao usuário" (credencial ausente / julgamento comercial subjetivo).

Quando a entrevista estiver concluída, repita cada campo chave preenchido e confirme antes de escrever qualquer arquivo.

---

D. Regras de geração

1. Copie templates/CLAUDE.md.template, substitua cada {{…}}, exclua seções opcionais que não se aplicam...