Inicio rápido

Las skills hacen las partes mecánicas (crear estructura, frontmatter, regeneración de índices, validación) para que dediques el tiempo a la parte que solo puedes hacer tú: decidir qué es la cosa.

Puedes escribir cada archivo a mano, y es una forma legítima de trabajar. Lo que no deberías saltarte es el propio _eidos/.

Las skills son opcionales. El Framework no.

El Framework (el marco) es lo que te mantiene fiel al estándar. Sin él en disco, la forma con la que escribes vive en tu cabeza: se desvía un poco con cada Blueprint, y deja de ser un estándar en el momento en que una segunda persona escribe uno. Crea _eidos/ aunque nunca ejecutes una skill.

1. Instala las skills

   Nueve vienen con el repositorio. Una skill es una carpeta con un SKILL.md dentro, así que cualquier agente que lea ese formato puede ejecutarlas.

   Claude Desktop / Web

   Customize → Plugins → + → Add marketplace from repository, y dale el repositorio:

   https://github.com/BuildableWorks/Eidos

   Luego instala eidos desde ese marketplace. Disponible en cualquier plan de pago.

   Claude Code

   El repositorio es un marketplace público de plugins:

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

   O apunta a un clon local para una sesión:

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

   Codex

   Codex carga skills desde .agents/skills/. Copia las carpetas dentro:

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

   Usa ~/.agents/skills/ en su lugar para tenerlas en todos los repositorios. No hace falta configuración: Codex recoge cualquier carpeta cuyo SKILL.md lleve name y description, que es el caso de todas las skills de Eidos.

   Manual

   Sáltate este paso. Copia una semilla desde seeds/ del repositorio al _eidos/ de tu raíz tú mismo, y sigue los shapes que te da.

   El resto de estos pasos nombra una skill para cada tarea; cada una describe lo que hace, así que el trabajo es el mismo de una forma u otra.

   Sin paso de compilación

   Cada skill es autocontenida: las tres que necesitan parte del estándar llevan una copia versionada de él, y el resto leen tu Framework en tiempo de ejecución. Una skill se comporta igual esté donde esté instalada.

2. Crea una raíz

   Ejecuta install. Pregunta qué estás definiendo, ofrece los tres Frameworks semilla y crea una raíz alrededor del que elijas.

   Semilla	Para
   software	Un producto, servicio o sistema que se está construyendo. La opción por defecto.
   book	Un libro, un argumento extenso o un curso.
   research	Una pregunta, un estudio o un programa de investigación.

   Elige el más cercano. Todo lo que te da una semilla es remodelable después, así que «lo bastante cerca» es la respuesta correcta: no estás eligiendo una jaula.

   Se te preguntarán dos cosas que son incómodas de cambiar más tarde:

   • El nombre de la carpeta raíz. Blueprints/ por defecto; puede ser cualquiera, porque nada apunta a ella por ruta. Una raíz se encuentra por el _eidos/ oculto que hay dentro.
   • La convención de nombres. kebab-case (por defecto), TitleCase o Title Case. Una sola convención gobierna toda la raíz, y cambiarla después significa renombrar cada archivo. Consulta Nombres.

   Lo que aterriza en disco:

   • DirectorioBlueprints/

     • README.md el “empieza aquí” humano
     • Directorio_eidos/ el Framework — la forma

       • Directorioshapes/ plantillas de cuerpo, un archivo por flavor

         • …
       • Directorioroles/ cómo habla el agente con cada rol

         • …
       • Framework.md índice + configuración + el Schema de propiedades
       • me.md quién está en el asiento (personal, en gitignore)
     • Directorioframes/ la colección de encuadre

       • …
     • Directoriospecs/ las unidades, agrupadas un nivel

       • …

3. Define quién eres

   Ejecuta whoami. Ofrece los roles que instaló tu Framework y luego calibra el que elijas en tres ejes: qué posees en esta raíz, tu experiencia con el alcance y tu capacidad técnica.

   Escribe _eidos/me.md, que es personal y está en gitignore. El agente lo lee antes de actuar para decidir cómo responder: vocabulario, profundidad, qué sacar a la luz y quién decide qué. En blanco está bien; por defecto es facilitación completa.

   Nota

   Este es un paso de dos minutos que la gente se salta. No lo hagas. Es la diferencia entre un agente que te explica cosas que ya sabes y uno calibrado a la persona que de verdad está leyendo.

4. Rellena los frames primero

   La colección de encuadre reúne los Blueprints que describen qué es la cosa entera; para la semilla software: architecture, audience, criteria, market.

   Rellénalos antes de escribir un solo Blueprint. Fijan aquello contra lo que se juzga cualquier otro Blueprint, que es la razón misma de que todo Framework esté obligado a declarar una colección de encuadre.

   Rellena lo que se sepa y deja el resto. Un frame sin escribir es un hueco que sacar a la luz después, no un fallo ahora.

   Más sobre los frames →

5. Piensa una unidad hasta el final

   Si ya sabes exactamente cuál es la unidad, salta al paso siguiente. Si tienes una idea en lugar de una decisión (y ese es el caso normal), ejecuta primero iterate.

   Cuestiona una idea en bruto hasta que se queda quieta: qué es, qué no es y dónde encaja entre lo que ya existe. No escribe ningún archivo. El resultado es una comprensión que puedes defender, que el paso siguiente convierte en un Blueprint.

   El paso que se salta la gente

   Un Blueprint escrito directamente a partir de una línea de instrucción se lee como algo zanjado cuando nadie ha decidido nada. El coste aparece más tarde como alcance que nadie acordó.

6. Escribe tu primer Blueprint

   Invoca la skill eidos y habla sobre una unidad de la cosa.

   Lee tu Framework para conocer el Schema, la convención de nombres y los flavors de la colección destino; genera el frontmatter a partir de las propiedades que aplican; y da al cuerpo la forma del flavor que elegiste. Empieza por el flavor ligero (micro en la semilla software): un Blueprint crece hacia el más completo cuando las secciones de ese se ganan su sitio.

   Dos cosas deciden si el Blueprint es bueno:

   • Empieza por la sección de apertura del shape. En la semilla software es ## Intent: por qué existe esto, y quién tiene el problema. Es la parte estable del Blueprint. Si Intent cambia sustancialmente, tienes otro Blueprint, no una edición de este.
   • Aprieta más fuerte en la sección de no-objetivos. ## Out of Scope es la sección en la que más se apoya el estándar, porque es donde de verdad pasa la gestión del alcance. Escríbela primero, no la última. Por qué →

   El agente no va a hacer esta parte por ti

   Por diseño. Formatea, complementa, pregunta y presiona sobre el alcance: no inventa el propósito de un Blueprint ni te entrega un Blueprint terminado para que lo sello sin más. Cuando duda, pregunta, y la respuesta correcta es una respuesta, no un «decide tú».

7. Regenera el índice y haz commit

   Ejecuta la skill index para reconstruir el index.md de cada colección: la hoja generada que lista sus Blueprints con su summary de una línea.

   Luego haz commit de toda la raíz, _eidos/ incluido. El único archivo que se queda fuera es el me.md personal, del que ya se encarga el .gitignore de la semilla.

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

   No pongas nada de esto en gitignore

   Eidos se apoya en el historial de git para el registro de auditoría que deliberadamente no duplica en el frontmatter. Una raíz en gitignore pierde justo lo que la hace fiable.

A partir de aquí

Revisa la raíz en los pull requests junto al código que describe. Cuando tenga suficiente forma como para valer la pena verla espacialmente, ejecuta canvas para generar un mapa de Obsidian: cada colección un grupo, cada enlace connects_to una arista dirigida.

• Escribir un Blueprint: la mecánica, en detalle.
• Dar forma a tu Framework: cuando una semilla deja de encajar.
• Skills: las nueve, y cuándo echar mano de cada una.