Exportacion

La fase de exportacion transforma los archivos spec en un formato optimizado para un agente IA especifico.

intake export <SPEC_DIR> -f <formato> -o <output>

---

Formatos disponibles

Formato	Estado	Que genera	Agente destino
architect	Implementado	pipeline.yaml + copia de spec	Architect
generic	Implementado	SPEC.md + verify.sh + copia de spec	Cualquier agente
claude-code	Implementado	CLAUDE.md + tareas individuales + verify.sh	Claude Code
cursor	Implementado	.cursor/rules/intake-spec.mdc	Cursor
kiro	Implementado	requirements.md + design.md + tasks.md (formato Kiro)	Kiro
copilot	Implementado	.github/copilot-instructions.md	GitHub Copilot

---

Architect

Genera un pipeline.yaml compatible con architect y una copia de los archivos spec.

intake export specs/mi-feature/ -f architect -o output/

Estructura generada

output/
├── pipeline.yaml       # Workflow con un step por tarea
└── spec/               # Copia de todos los archivos spec
    ├── requirements.md
    ├── design.md
    ├── tasks.md
    ├── acceptance.yaml
    ├── context.md
    └── sources.md

pipeline.yaml

name: mi-feature
description: "Pipeline generated by intake from spec 'mi-feature'"
steps:
  - name: task-1
    agent: build
    prompt: |
      Implement task 1: Setup project structure

      Create the initial project structure with the following files...

      Project context:
      [primeros 2000 chars de context.md]
    checkpoint: true

  - name: task-2
    agent: build
    prompt: |
      Implement task 2: Implement user model
      ...
    checkpoint: true

  # ... un step por cada tarea en tasks.md ...

  - name: final-verification
    agent: review
    prompt: "Verify that the entire implementation meets the spec requirements."
    checks:
      - "python -m pytest tests/ -q"
      - "ruff check src/"
      # ... todos los command checks requeridos de acceptance.yaml ...

Cada step incluye:

Campo	Descripcion
name	task-{id} basado en el ID de la tarea
agent	build para tareas, review para verificacion final
prompt	Titulo + descripcion + contexto del proyecto
checkpoint	true — pausa despues de cada tarea para revision
checks	Solo en el step final: lista de comandos de verificacion

Opciones

El ArchitectExporter acepta include_guardrails (configurable via export.architect_include_guardrails).

---

Generic

Genera un SPEC.md consolidado, un verify.sh ejecutable, y una copia de los archivos spec. Compatible con cualquier agente o flujo de trabajo manual.

intake export specs/mi-feature/ -f generic -o output/

Estructura generada

output/
├── SPEC.md            # Markdown consolidado con todas las secciones
├── verify.sh          # Script bash ejecutable
└── spec/              # Copia de todos los archivos spec
    ├── requirements.md
    ├── design.md
    ├── tasks.md
    ├── acceptance.yaml
    ├── context.md
    └── sources.md

SPEC.md

Un unico archivo Markdown que consolida:

1. Project Context — contenido de context.md
2. Requirements — contenido de requirements.md
3. Design — contenido de design.md
4. Tasks — contenido de tasks.md
5. Sources — contenido de sources.md

Util para pegarlo directamente en el contexto de un agente.

verify.sh

Script bash auto-contenido que ejecuta los command checks de acceptance.yaml:

#!/usr/bin/env bash
set -euo pipefail

PROJECT_DIR="${1:-.}"
PASS=0
FAIL=0

check() {
    local name="$1"
    local cmd="$2"
    if (cd "$PROJECT_DIR" && eval "$cmd") > /dev/null 2>&1; then
        echo "PASS: $name"
        PASS=$((PASS + 1))
    else
        echo "FAIL: $name"
        FAIL=$((FAIL + 1))
    fi
}

check "Tests pasan" "python -m pytest tests/ -q"
check "Lint limpio" "ruff check src/"

echo ""
echo "Passed: $PASS  Failed: $FAIL"

if [ "$FAIL" -gt 0 ]; then
    exit 1
fi

El script:

• Acepta un argumento opcional PROJECT_DIR (default: .)
• Ejecuta cada check con la funcion check()
• Reporta PASS/FAIL por cada check
• Muestra totales al final
• Exit code 1 si algun check fallo, 0 si todos pasaron
• Se genera con chmod +x automatico

Uso sin intake

El exporter generic permite verificar sin tener intake instalado:

# En CI o en la maquina del desarrollador
./output/verify.sh /path/to/project

---

Claude Code

Genera una estructura optimizada para Claude Code: tareas individuales, script de verificacion, y un bloque en CLAUDE.md.

intake export specs/mi-feature/ -f claude-code -o .

Estructura generada

./
├── CLAUDE.md                    # Se agrega/actualiza seccion "## intake Spec"
└── .intake/
    ├── spec-summary.md          # Referencia rapida (requisitos, tareas, checks)
    ├── verify.sh                # Script ejecutable con checks de aceptacion
    ├── tasks/
    │   ├── TASK-001.md          # Una tarea por archivo con contexto
    │   ├── TASK-002.md
    │   └── ...
    └── spec/                    # Copia de los archivos spec originales
        ├── requirements.md
        ├── design.md
        ├── tasks.md
        ├── acceptance.yaml
        ├── context.md
        └── sources.md

CLAUDE.md

El exporter agrega (o reemplaza) una seccion ## intake Spec en el CLAUDE.md existente. Si no existe, lo crea. Incluye:

• Resumen de la spec (cantidad de requisitos, tareas, checks)
• Path a la referencia completa (.intake/spec-summary.md)
• Path al script de verificacion (.intake/verify.sh)
• Lista de archivos de tareas individuales

Tareas individuales

Cada archivo TASK-NNN.md contiene:

• Titulo y descripcion de la tarea
• Archivos a crear/modificar
• Dependencias con otras tareas
• Checks de aceptacion asociados
• Resumen del contexto del proyecto

verify.sh

Script bash auto-contenido que ejecuta los command checks de acceptance.yaml. Funciona igual que el de Generic pero se ubica en .intake/.

---

Cursor

Genera un archivo de reglas compatible con Cursor en formato .mdc (YAML frontmatter + Markdown).

intake export specs/mi-feature/ -f cursor -o .

Estructura generada

./
├── .cursor/
│   └── rules/
│       └── intake-spec.mdc      # Reglas de Cursor con la spec completa
└── .intake/
    └── spec/                    # Copia de los archivos spec

intake-spec.mdc

El archivo .mdc usa YAML frontmatter para metadatos de Cursor:

---
description: "Spec generated by intake: Mi Feature"
globs: "**/*"
---

# intake Specification: Mi Feature

## Requirements
[contenido de requirements.md]

## Design
[contenido de design.md]

## Tasks
[tabla resumen de tareas con estado]

## Acceptance Checks
[checks formateados por tipo]

---

Kiro

Genera archivos en el formato nativo de Kiro con requisitos, diseno y tareas como checkboxes.

intake export specs/mi-feature/ -f kiro -o .

Estructura generada

./
├── requirements.md              # Requisitos con criterios de aceptacion como checkboxes
├── design.md                    # Documento de diseno en formato Kiro
├── tasks.md                     # Tareas con verificacion como checkboxes
└── .intake/
    └── spec/                    # Copia de los archivos spec originales

Formato de requisitos

Los requisitos se formatean con criterios de aceptacion como checkboxes:

## Requirements

### FR-001: User Registration
Users must be able to register with email and password.

**Acceptance Criteria:**
- [ ] Email validation works
- [ ] Password strength check enforced

Formato de tareas

Las tareas incluyen checks de verificacion como checkboxes:

### Task 1: Setup project structure
Description of the task...

**Verification:**
- [ ] python -m pytest tests/ -q
- [ ] ruff check src/

---

Copilot

Genera instrucciones para GitHub Copilot en el formato oficial de customization.

intake export specs/mi-feature/ -f copilot -o .

Estructura generada

./
├── .github/
│   └── copilot-instructions.md  # Instrucciones para GitHub Copilot
└── .intake/
    └── spec/                    # Copia de los archivos spec

copilot-instructions.md

Archivo Markdown con instrucciones estructuradas para Copilot:

• Contexto del proyecto (stack, convenciones)
• Requisitos funcionales y no funcionales
• Tareas a implementar
• Checks de aceptacion

Este archivo es leido automaticamente por GitHub Copilot cuando se trabaja en el repositorio.

---

Exporter Protocols

intake soporta dos generaciones de protocolos para exporters:

V1 — Exporter (core)

@runtime_checkable
class Exporter(Protocol):
    def export(self, spec_dir: str, output_dir: str) -> list[str]: ...

Retorna la lista de archivos generados. Usado por architect y generic.

V2 — ExporterPlugin (plugins)

@runtime_checkable
class ExporterPlugin(Protocol):
    @property
    def meta(self) -> PluginMeta: ...

    @property
    def supported_agents(self) -> list[str]: ...

    def export(self, spec_dir: str, output_dir: str) -> ExportResult: ...

Retorna un ExportResult con mas metadata:

@dataclass
class ExportResult:
    files_created: list[str]    # Todos los archivos generados
    primary_file: str           # Archivo principal de entrada
    instructions: str           # Mensaje al usuario

Usado por claude-code, cursor, kiro y copilot.

Agregar un nuevo exporter

Opcion 1: Built-in

1. Crear un archivo en src/intake/export/ (ej: windsurf.py)
2. Implementar ExporterPlugin (V2) o Exporter (V1)
3. Registrarlo como entry_point en pyproject.toml y en el fallback manual

Opcion 2: Plugin externo

1. Crear un paquete Python separado
2. Implementar el protocolo ExporterPlugin de intake.plugins.protocols
3. Registrar como entry_point en el grupo intake.exporters

El exporter sera descubierto automaticamente al instalar el paquete. Ver Plugins para detalles.

Nota: Los exporters se descubren automaticamente via el sistema de plugins. El ExporterRegistry intenta plugin discovery primero y cae back a registro manual si falla.

---

Helpers compartidos

Los 4 nuevos exporters (V2) comparten utilidades de export/_helpers.py:

Funcion	Que hace
read_spec_file(path, filename)	Lee un archivo de la spec (retorna "" si no existe)
parse_tasks(tasks_content)	Extrae tareas estructuradas de tasks.md (id, titulo, descripcion, status)
load_acceptance_checks(path)	Carga los checks de acceptance.yaml
summarize_content(content, max_lines)	Trunca contenido largo con indicador de lineas omitidas
count_requirements(content)	Cuenta requisitos (FR-NNN, NFR-NNN) por headings

---

Configuracion relacionada

export:
  default_format: generic                    # architect | claude-code | cursor | kiro | copilot | generic
  architect_include_guardrails: true         # Guardrails en pipeline.yaml
  architect_pipeline_template: standard      # Template del pipeline
  claude_code_generate_claude_md: true       # Generar CLAUDE.md al exportar para Claude Code
  claude_code_task_dir: .intake/tasks        # Directorio para archivos de tarea
  cursor_rules_dir: .cursor/rules            # Directorio para reglas de Cursor

El formato por defecto se puede sobreescribir con --format en la CLI:

# Usa el default de config
intake init "Mi feature" -s reqs.md

# Sobreescribe con un formato especifico
intake init "Mi feature" -s reqs.md -f claude-code
intake export specs/mi-feature/ -f cursor -o .

---

Export CI

Ademas de los formatos para agentes, intake puede generar configuracion CI para verificacion automatica:

intake export-ci specs/mi-feature/ -p gitlab    # Genera .gitlab-ci.yml
intake export-ci specs/mi-feature/ -p github    # Genera .github/workflows/intake-verify.yml

Ver Guia CLI > export-ci y Integracion CI/CD para mas detalles.