Construye con IA.
Sin dejarla improvisar.
Framework Spec-Driven que implementa la metodología MARK.
Un solo riel: /stark-init → requirements → design → tasks → build. Con gates humanos.
Un producto de iamgabstark_
El sello
Especificación exhaustiva.
Implementación mínima.
stark une dos mundos: specs primero (EARS, trazabilidad, gates humanos) y no escribir una sola línea que no gane su lugar. Tres cosas distintas que no se confunden:
SDD · el género
Spec-Driven Development
La práctica de la industria: escribes especificaciones formales y el agente IA genera el código. Las specs son el artefacto versionado; el código es consecuencia. En fase "Assess" del Tech Radar de Thoughtworks.
MARK · el método
La metodología
La adaptación propia de la autora dentro del género SDD. Define el cómo: el pipeline fase-gate de 7 fases. Conocer MARK →
stark · la herramienta
El framework
Este proyecto. La herramienta que implementa MARK sobre Claude Code: 8 subagentes especializados, 9 skills y 8 comandos /stark-*.
El flujo
Un solo riel.
Seis fases.
Los comandos /stark-* orquestan los subagentes. Cada fase termina en un
gate humano: revisión y aprobación explícita antes de la siguiente.
Saltarte uno propaga el error 10× hacia adelante.
01
/stark-init
Detecta tu caso de uso y prepara el terreno.
02
/stark-requirements
Material → requirements.md en notación EARS.
✋ gate humano03
/stark-prototype
Mockup desplegable para validar con el cliente.
✋ gate cliente04
/stark-design
Requirements → design.md (9 secciones).
✋ gate humano05
/stark-tasks
Design → tasks.md: walking skeleton + rebanadas.
✋ gate humano06
/stark-build
Un Slice por sesión. Tú apruebas cada lote.
✋ por loteTransversales, cuando quieras: /stark-review revisa el diff contra los principios · /stark-audit audita el repo completo.
Casos de uso
Cuatro formas
de empezar.
Nuevo · greenfield
Construir desde cero
Tienes entrevistas, formularios o imágenes. Clonas stark como repo nuevo y pones el material en docs/inputs/.
Reingeniería · brownfield
Reescribir un legacy
Modernizas un sistema existente. Partes de tu arqueología en docs/analysis/ y del código legacy; stark levanta los requirements desde ahí.
Mantenimiento
Feature a producción
Agregas una funcionalidad sin romper lo que funciona. Solo el delta, con Surface of Contact e Invariantes Preservadas; tasks ordenadas por riesgo de regresión.
Prototipo · transversal
Validar una idea
Un mockup desplegable a partir de un requirements ligero, con loop de validación con el cliente. Paras ahí o sigues a design → tasks → build.
La filosofía
Cuatro principios
que no se negocian.
1
No sobre-ingeniería
La escalera YAGNI: lo especulativo no se construye, lo que no aporta se recorta. Nada gana su lugar por defecto.
2
Seguridad por diseño
Perezoso, no negligente. Nunca se sacrifican validación, manejo de errores, protección de datos ni secretos fuera del código.
3
Despliegue simple
Si desplegar exige un ritual, el diseño falló. "¿Cómo se despliega esto?" es criterio de primera clase.
4
Documentación limpia
Cada documento gana su lugar. Sin redundancia, sin relleno, sin secciones "por completitud".
Un framework que predica contra la sobre-ingeniería no puede ser él mismo sobre-ingeniado. Estos principios aplican al código que stark genera y a stark como producto.
Quick start
Clona y arranca.
# Nuevo o reingeniería — clona como repo propio
$ cd mi-proyecto && rm -rf .git && git init
# luego, dentro de Claude Code:
> /stark-init ← detecta tu caso y te dice el siguiente paso
# Mantenimiento — sobre un repo en producción (no toca tu código)
$ cp -r /tmp/stark/.claude /tmp/stark/templates .
# agrega .claude/ y templates/ · el resto queda intacto