Guia CLI

intake proporciona 13 comandos y subcomandos. Todos siguen el patron:

intake <comando> [argumentos] [opciones]

Para ver la ayuda de cualquier comando:

intake --help
intake <comando> --help

intake init

Genera una spec completa a partir de fuentes de requisitos. Este es el comando principal.

intake init <DESCRIPCION> -s <fuente> [opciones]

Argumento

Argumento	Tipo	Requerido	Descripcion
`DESCRIPCION`	texto	Si	Frase corta describiendo que construir. Se convierte en slug para el nombre del directorio (max 50 caracteres).

Opciones

Flag	Corto	Tipo	Default	Requerido	Descripcion
`--source`	`-s`	texto	—	Si	Fuente de requisitos (repetible). Path a archivo, URL, o `-` para stdin.
`--mode`		opcion	auto	No	Modo de generacion: `quick`, `standard`, `enterprise`. Si no se especifica, se auto-clasifica.
`--model`	`-m`	texto	config o `claude-sonnet-4`	No	Modelo LLM a usar para el analisis.
`--lang`	`-l`	texto	config o `en`	No	Idioma del contenido generado en la spec.
`--project-dir`	`-p`	path	`.`	No	Directorio del proyecto existente (para auto-deteccion del stack).
`--stack`		texto	auto-detectado	No	Stack tecnologico. Ej: `python,fastapi,postgresql`.
`--output`	`-o`	path	`./specs`	No	Directorio de salida para la spec.
`--format`	`-f`	opcion	config o ninguno	No	Formato de exportacion: `architect`, `claude-code`, `cursor`, `kiro`, `generic`.
`--preset`		opcion	ninguno	No	Preset de configuracion: `minimal`, `standard`, `enterprise`.
`--interactive`	`-i`	flag	false	No	Modo interactivo: pregunta antes de generar cada seccion.
`--dry-run`		flag	false	No	Muestra que haria sin generar archivos.
`--verbose`	`-v`	flag	false	No	Output detallado.

Ejemplos

# Desde un archivo Markdown
intake init "API de usuarios" -s requirements.md

# Desde multiples fuentes
intake init "Pasarela de pagos" -s jira.json -s confluence.html -s notas.md

# Con modelo especifico y preset enterprise
intake init "Sistema critico" -s reqs.yaml --model gpt-4o --preset enterprise

# Con stack manual y formato de exportacion
intake init "Microservicio" -s reqs.md --stack python,fastapi -f architect

# Spec en espanol
intake init "Carrito de compras" -s historias.md --lang es

# Modo rapido (solo context.md + tasks.md)
intake init "Fix login bug" -s notas.txt --mode quick

# Modo enterprise (todos los archivos + riesgos detallados)
intake init "Sistema critico" -s reqs.yaml --mode enterprise

# Desde una URL
intake init "API review" -s https://wiki.company.com/rfc/auth

# Desde un export de Slack
intake init "Decisiones de sprint" -s slack_export.json

# Desde GitHub Issues
intake init "Bug fixes" -s issues.json

# URI de esquema (preparacion para conectores futuros)
# intake init "Feature" -s jira://PROJ-123  # muestra warning "connector not available yet"

# Dry run para ver que haria
intake init "Prototipo" -s ideas.txt --dry-run

# Desde stdin
cat requisitos.txt | intake init "Feature X" -s -

Que hace internamente

Carga la configuracion (preset + .intake.yaml + flags CLI)
Auto-detecta el stack tecnologico del proyecto (si no se especifica --stack)
Slugifica la descripcion para el nombre del directorio
Resolucion de fuentes: cada fuente se resuelve via parse_source():
- Archivos locales → se parsean con el registry
- URLs (http://, https://) → se procesan con UrlParser
- URIs de esquema (jira://, confluence://, github://) → warning “connector not available yet”
- Stdin (-) → se lee como texto plano
- Texto libre → se trata como plaintext
Clasificacion de complejidad: si no se especifica --mode, se auto-clasifica:
- quick: <500 palabras, 1 fuente, sin estructura
- standard: caso por defecto
- enterprise: 4+ fuentes O >5000 palabras
Fase 1 — Ingest: parsea todas las fuentes via el registry
Fase 2 — Analyze: extraccion LLM, deduplicacion, validacion, riesgos, diseno
Fase 3 — Generate: renderiza archivos segun el modo (quick: 2, standard/enterprise: 6) + spec.lock.yaml
Fase 5 — Export: exporta al formato elegido (si se especifico --format)

intake add

Agrega fuentes a una spec existente.

intake add <SPEC_DIR> -s <fuente> [opciones]

Argumento

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec existente.

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--source`	`-s`	texto	—	Nuevas fuentes a agregar (repetible).
`--regenerate`		flag	false	Regenerar toda la spec incluyendo las nuevas fuentes.
`--verbose`	`-v`	flag	false	Output detallado.

Ejemplo

# Agregar una fuente nueva a una spec existente
intake add specs/api-de-usuarios/ -s feedback-qa.md

# Agregar y regenerar todo
intake add specs/api-de-usuarios/ -s nuevos-reqs.yaml --regenerate

intake verify

Verifica que la implementacion cumple con la spec ejecutando los checks de acceptance.yaml.

intake verify <SPEC_DIR> [opciones]

Argumento

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec.

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--project-dir`	`-p`	path	`.`	Directorio del proyecto a verificar.
`--format`	`-f`	opcion	`terminal`	Formato del reporte: `terminal`, `json`, `junit`.
`--tags`	`-t`	texto	todos	Solo ejecutar checks con estos tags (repetible).
`--fail-fast`		flag	false	Detenerse en el primer check requerido que falle.

Exit codes

Codigo	Significado
`0`	Todos los checks requeridos pasaron
`1`	Al menos un check requerido fallo
`2`	Error de ejecucion (spec no encontrada, YAML invalido, etc.)

Ejemplos

# Verificar con reporte en terminal
intake verify specs/api-de-usuarios/ -p .

# Solo checks con tag "api"
intake verify specs/api-de-usuarios/ -p . -t api

# Formato JUnit para CI
intake verify specs/api-de-usuarios/ -p . -f junit > test-results.xml

# Fail fast
intake verify specs/api-de-usuarios/ -p . --fail-fast

# Formato JSON
intake verify specs/api-de-usuarios/ -p . -f json

intake export

Exporta una spec a un formato listo para un agente IA.

intake export <SPEC_DIR> -f <formato> [opciones]

Argumento

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec.

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--format`	`-f`	opcion	—	Formato: `architect`, `claude-code`, `cursor`, `kiro`, `generic`. Requerido.
`--output`	`-o`	path	`.`	Directorio de salida.

Ejemplos

# Exportar para architect
intake export specs/api-de-usuarios/ -f architect -o output/

# Exportar formato generico
intake export specs/api-de-usuarios/ -f generic -o output/

intake show

Muestra un resumen de una spec: requisitos, tareas, checks, costos.

intake show <SPEC_DIR>

Argumento

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec.

Que muestra

Archivos en la spec
Modelo LLM usado
Cantidad de requisitos
Cantidad de tareas
Costo total del analisis
Fecha de creacion
Cantidad de fuentes
Cantidad de checks de aceptacion

Ejemplo

intake show specs/api-de-usuarios/

intake list

Lista todas las specs en un directorio.

intake list [opciones]

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--dir`	`-d`	path	`./specs`	Directorio donde buscar specs.

Detecta subdirectorios que contengan requirements.md o acceptance.yaml.

Ejemplo

# Listar specs en el directorio por defecto
intake list

# Listar specs en otro directorio
intake list -d ./mi-proyecto/specs

intake diff

Compara dos versiones de una spec y muestra los cambios.

intake diff <SPEC_A> <SPEC_B> [opciones]

Argumentos

Argumento	Tipo	Requerido	Descripcion
`SPEC_A`	path	Si	Primera version de la spec.
`SPEC_B`	path	Si	Segunda version de la spec.

Opciones

Flag	Tipo	Default	Descripcion
`--section`	opcion	`all`	Que seccion comparar: `requirements`, `design`, `tasks`, `acceptance`, `all`.

Que compara

requirements: Requisitos por ID (FR-XX, NFR-XX)
tasks: Tareas por numero
acceptance: Checks por ID

Los cambios se muestran como:

Added (verde): elementos nuevos en SPEC_B
Removed (rojo): elementos que estaban en SPEC_A pero no en SPEC_B
Modified (amarillo): elementos con cambios

Ejemplo

# Comparar dos versiones completas
intake diff specs/v1/ specs/v2/

# Solo comparar requisitos
intake diff specs/v1/ specs/v2/ --section requirements

intake doctor

Diagnostica el entorno y la configuracion.

intake doctor [opciones]

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--fix`		flag	false	Intentar corregir los problemas detectados automaticamente.
`--verbose`	`-v`	flag	false	Output detallado.

Checks que ejecuta

Check	Que verifica	Auto-fixable
Python version	Python >= 3.12	No
LLM API key	`ANTHROPIC_API_KEY` o `OPENAI_API_KEY` definida	No
pdfplumber	Paquete instalado	Si
python-docx	Paquete instalado	Si
beautifulsoup4	Paquete instalado	Si
markdownify	Paquete instalado	Si
litellm	Paquete instalado	Si
jinja2	Paquete instalado	Si
Config file	`.intake.yaml` existe y es YAML valido	Si (crea uno basico)

—fix

Con --fix, intake intenta corregir automaticamente:

Paquetes faltantes: ejecuta pip install <paquete> (detecta pip3.12, pip3 o pip)
Config faltante: crea un .intake.yaml basico con defaults

Ejemplos

# Solo diagnosticar
intake doctor

# Diagnosticar y corregir
intake doctor --fix

# Con output detallado
intake doctor -v

intake plugins list

Lista todos los plugins descubiertos (parsers, exporters, connectors).

intake plugins list [opciones]

Opciones

Flag	Corto	Tipo	Default	Descripcion
`--verbose`	`-v`	flag	false	Mostrar columnas adicionales: modulo y errores de carga.

Que muestra

Una tabla con:

Columna	Descripcion
Name	Nombre del plugin
Group	Grupo: parsers, exporters, connectors
Version	Version del paquete que lo provee
V2	Si implementa el protocolo V2
Built-in	Si es un plugin built-in de intake

Con -v se agregan columnas de modulo y errores de carga.

Ejemplo

# Lista basica
intake plugins list

# Con detalles
intake plugins list -v

intake plugins check

Valida la compatibilidad de todos los plugins descubiertos.

intake plugins check

Ejecuta check_compatibility() en cada plugin y reporta OK o FAIL con detalles del error.

intake task list

Lista las tareas de una spec con su estado actual.

intake task list <SPEC_DIR> [opciones]

Argumento

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec.

Opciones

Flag	Tipo	Default	Descripcion
`--status`	opcion	todos	Filtrar por estado (repetible): `pending`, `in_progress`, `done`, `blocked`.

Que muestra

Tabla con ID, titulo y estado de cada tarea
Resumen de progreso: total, pending, in_progress, done, blocked

Ejemplo

# Listar todas las tareas
intake task list specs/mi-feature/

# Solo tareas pendientes y en progreso
intake task list specs/mi-feature/ --status pending --status in_progress

intake task update

Actualiza el estado de una tarea en tasks.md.

intake task update <SPEC_DIR> <TASK_ID> <STATUS> [opciones]

Argumentos

Argumento	Tipo	Requerido	Descripcion
`SPEC_DIR`	path	Si	Directorio de la spec.
`TASK_ID`	entero	Si	ID de la tarea a actualizar.
`STATUS`	opcion	Si	Nuevo estado: `pending`, `in_progress`, `done`, `blocked`.

Opciones

Flag	Tipo	Default	Descripcion
`--note`	texto	ninguno	Nota o anotacion para agregar a la actualizacion.

Ejemplo

# Marcar tarea 1 como completada
intake task update specs/mi-feature/ 1 done

# Marcar como en progreso con nota
intake task update specs/mi-feature/ 2 in_progress --note "Iniciando implementacion"

# Marcar como bloqueada
intake task update specs/mi-feature/ 3 blocked --note "Esperando API de terceros"

Opciones globales

Flag	Descripcion
`--version`	Muestra la version de intake
`--help`	Muestra la ayuda del comando

intake --version    # intake, version 0.2.0
intake --help       # Ayuda general
intake init --help  # Ayuda del comando init

Exit codes

Todos los comandos siguen un esquema de exit codes consistente:

Codigo	Significado
`0`	Exito
`1`	Check requerido fallo (solo `verify`)
`2`	Error de ejecucion