Início rápido

As skills fazem as partes mecânicas (criar a estrutura, frontmatter, regeneração de índices, validação) para que você gaste o tempo na parte que só você pode fazer: decidir o que a coisa é.

Você pode escrever cada arquivo à mão, e é um jeito legítimo de trabalhar. O que você não deveria pular é o próprio _eidos/.

As skills são opcionais. O Framework não é.

O Framework (a estrutura) é o que te mantém fiel ao padrão. Sem ele em disco, a forma com que você escreve mora na sua cabeça: ela se desvia um pouco a cada Blueprint, e deixa de ser um padrão no momento em que uma segunda pessoa escreve um. Crie _eidos/ mesmo que você nunca execute uma skill.

1. Instale as skills

   Nove vêm com o repositório. Uma skill é uma pasta com um SKILL.md dentro, então qualquer agente que leia esse formato pode executá-las.

   Claude Desktop / Web

   Customize → Plugins → + → Add marketplace from repository, e informe o repositório:

   https://github.com/BuildableWorks/Eidos

   Depois instale eidos a partir desse marketplace. Disponível em qualquer plano pago.

   Claude Code

   O repositório é um marketplace público de plugins:

   /plugin marketplace add BuildableWorks/Eidos
   /plugin install eidos@eidos

   Ou aponte para um clone local por uma sessão:

   claude --plugin-dir /path/to/eidos

   Codex

   O Codex carrega skills de .agents/skills/. Copie as pastas para lá:

   git clone https://github.com/BuildableWorks/Eidos.git
   mkdir -p .agents/skills && cp -r Eidos/skills/* .agents/skills/

   Use ~/.agents/skills/ em vez disso para tê-las em todos os repositórios. Não precisa de configuração: o Codex reconhece qualquer pasta cujo SKILL.md carregue name e description, o que toda skill do Eidos faz.

   Manual

   Pule este passo. Copie uma semente de seeds/ do repositório para o _eidos/ da sua raiz você mesmo, e siga os shapes que ela te dá.

   O resto destes passos nomeia uma skill para cada tarefa; cada uma descreve o que faz, então o trabalho é o mesmo de um jeito ou de outro.

   Sem etapa de build

   Cada skill é autocontida: as três que precisam de parte do padrão carregam uma cópia versionada dele, e o resto lê o seu Framework em tempo de execução. Uma skill se comporta igual onde quer que esteja instalada.

2. Crie uma raiz

   Execute install. Ele pergunta o que você está definindo, oferece os três Frameworks semente e cria uma raiz em torno do que você escolher.

   Semente	Para
   software	Um produto, serviço ou sistema em construção. O padrão.
   book	Um livro, um argumento longo ou um curso.
   research	Uma pergunta, um estudo ou um programa de investigação.

   Escolha o mais próximo. Tudo o que uma semente te dá é remodelável depois, então “perto o suficiente” é a resposta certa: você não está escolhendo uma jaula.

   Duas coisas serão perguntadas, e são incômodas de mudar depois:

   • O nome da pasta raiz. Blueprints/ por padrão; pode ser qualquer um, porque nada aponta para ela por caminho. Uma raiz é encontrada pelo _eidos/ oculto que há dentro.
   • A convenção de nomes. kebab-case (padrão), TitleCase ou Title Case. Uma única convenção rege a raiz inteira, e mudá-la depois significa renomear cada arquivo. Veja Nomes.

   O que aterrissa em disco:

   • DirectoryBlueprints/

     • README.md o “comece aqui” humano
     • Directory_eidos/ o Framework — a forma

       • Directoryshapes/ modelos de corpo, um arquivo por flavor

         • …
       • Directoryroles/ como o agente fala com cada papel

         • …
       • Framework.md índice + configuração + o Schema de propriedades
       • me.md quem está no assento (pessoal, no gitignore)
     • Directoryframes/ a coleção de enquadramento

       • …
     • Directoryspecs/ as unidades, agrupadas em um nível

       • …

3. Defina quem você é

   Execute whoami. Ele oferece os papéis que o seu Framework instalou e depois calibra o que você escolher em três eixos: o que você possui nesta raiz, a sua experiência com o escopo e a sua capacidade técnica.

   Ele escreve _eidos/me.md, que é pessoal e está no gitignore. O agente o lê antes de agir para decidir como responder: vocabulário, profundidade, o que trazer à tona e quem decide o quê. Em branco está tudo bem; o padrão é facilitação completa.

   Nota

   Este é um passo de dois minutos que as pessoas pulam. Não pule. É a diferença entre um agente explicando coisas que você já sabe e um calibrado para a pessoa que está de fato lendo.

4. Preencha os frames primeiro

   A coleção de enquadramento reúne os Blueprints que descrevem o que a coisa inteira é; para a semente software: architecture, audience, criteria, market.

   Preencha-os antes de escrever um único Blueprint. Eles definem aquilo contra o que qualquer outro Blueprint é julgado, que é a razão de todo Framework ser obrigado a declarar uma coleção de enquadramento.

   Preencha o que se sabe e deixe o resto. Um frame não escrito é uma lacuna a trazer à tona depois, não uma falha agora.

   Mais sobre os frames →

5. Pense uma unidade até o fim

   Se você já sabe exatamente qual é a unidade, pule para o próximo passo. Se você tem uma ideia em vez de uma decisão (e esse é o caso normal), execute primeiro o iterate.

   Ele questiona uma ideia bruta até ela ficar parada: o que ela é, o que ela não é e onde ela se encaixa entre o que já existe. Ele não escreve arquivo nenhum. O resultado é um entendimento que você consegue defender, que o próximo passo transforma em um Blueprint.

   O passo que as pessoas pulam

   Um Blueprint escrito direto a partir de uma linha de instrução se lê como algo resolvido enquanto ninguém decidiu nada. O custo aparece depois como escopo que ninguém combinou.

6. Escreva o seu primeiro Blueprint

   Invoque a skill eidos e converse sobre uma unidade da coisa.

   Ela lê o seu Framework para saber o Schema, a convenção de nomes e os flavors da coleção de destino; gera o frontmatter a partir das propriedades que se aplicam; e dá ao corpo a forma do flavor que você escolheu. Comece pelo flavor leve (micro na semente software): um Blueprint cresce para o mais completo quando as seções deste ganham o seu lugar.

   Duas coisas decidem se o Blueprint presta:

   • Comece pela seção de abertura do shape. Na semente software é ## Intent: por que isto existe, e quem tem o problema. É a parte estável do Blueprint. Se Intent muda substancialmente, você tem outro Blueprint, não uma edição deste.
   • Aperte mais forte na seção de não-objetivos. ## Out of Scope é a seção em que o padrão mais se apoia, porque é onde a gestão de escopo de fato acontece. Escreva-a primeiro, não por último. Por quê →

   O agente não vai fazer esta parte por você

   Por design. Ele formata, complementa, pergunta e pressiona sobre o escopo: ele não inventa o propósito de um Blueprint nem te entrega um Blueprint pronto para você carimbar. Quando está em dúvida, ele pergunta, e a resposta certa é uma resposta, não um “você decide”.

7. Regenere o índice e faça commit

   Execute a skill index para reconstruir o index.md de cada coleção: a folha gerada que lista seus Blueprints com o seu summary de uma linha.

   Depois faça commit da raiz inteira, _eidos/ e tudo. O único arquivo que fica de fora é o me.md pessoal, do qual o .gitignore da semente já cuida.

   git add Blueprint
   git commit -m "add product blueprints"

   Não coloque nada disso no gitignore

   O Eidos se apoia no histórico do git para a trilha de auditoria que ele deliberadamente não duplica no frontmatter. Uma raiz no gitignore perde justamente o que a torna confiável.

Daqui em diante

Revise a raiz nos pull requests ao lado do código que ela descreve. Quando ela tiver forma suficiente para valer a pena ser vista espacialmente, execute canvas para gerar um mapa do Obsidian: cada coleção um grupo, cada link connects_to uma aresta dirigida.

• Escrevendo um Blueprint: a mecânica, em detalhe.
• Dando forma ao seu Framework: quando uma semente deixa de servir.
• Skills: as nove, e quando recorrer a cada uma.