Vos traés la idea.
El método construye el resto.
Uscha es una metodología spec-driven y tool-agnóstica para desarrollar con agentes de código. Sin ceremonia donde no la gana — con rigor donde las stakes lo justifican. Su mecanismo central: un ledger determinístico que separa lo medido de lo narrado.
El agente ejecuta · el método gobierna · la evidencia decide · el humano aprueba.
$ npx --yes @andresmassello/uscha@latest install --target claude
El agente dice que terminó. ¿Quién lo contradice?
Loop abierto vs. grafo medido
Hay dos formas de poner un agente a trabajar sobre código. En el loop abierto, el agente decide el recorrido y se pregunta a sí mismo si terminó — nadie afuera lo contradice. En el grafo medido, el humano define los caminos posibles y cada compuerta la contesta evidencia medida, no el agente.
- investiga
- modifica código
- ejecuta tests
- revisa el resultado
- ¿resolvió?
- termina — o vuelve a intentar
- reproducir el bug
- ¿lo reproduce?
- hallar causa · intentar fix
- ¿pasan los tests?
- revisión
- ¿aprobado por un humano?
Uscha es ese grafo medido, con dos particularidades: cada compuerta la contesta un artefacto determinista y auditable — el ledger, los gates, la cobertura, el golden — y el loop no desaparece: se enjaula dentro de un nodo de convergencia acotado que o converge o escala a un humano.
Leé el ensayo completo: por qué existe uscha →
Los gates que leen HECHOS bloquean; los que ADIVINAN sobre prosa, avisan.
Cinco reglas. Nada más — y nada menos.
No hay código sin SPEC + ACCEPTANCE
Antes de construir, existe qué se construye y cómo se sabe que está bien.
La verdad vive en archivos versionados
No en el chat. SPEC.md, ADR, ACCEPTANCE.md, QA-LEDGER.json — todo en el repo.
El humano siempre aprueba el merge
El pipeline frena en el gate de merge. Siempre. Sin excepción.
Los tests deben asertar
El gate nunca se debilita para que pase. Un test que no aserta no es un test.
Migraciones ancladas con golden
El comportamiento viejo se captura mecánicamente antes de tocarlo. El agente jamás authorea el .approved.
De la idea a producción, con compuertas en el camino
Nueve skills que cubren el ciclo completo
Del interrogatorio inicial al dashboard de estado. Cada skill hace una cosa; el ledger las une.
De la idea pelada al paquete de spec: la skill interroga hasta que exista una forma compartida del sistema, y escribe los documentos sobre la marcha.
Entrevistar, después destilar: la misma entrevista aplicada a una feature ya conocida. No es un generador — es un interrogador.
El orquestador de construcción + QA: ciclo disciplinado, cada paso en el ledger, y freno duro en el gate humano del merge.
Congelar el comportamiento actual como verdad de campo: la suite golden — el único artefacto que el agente no puede authorear.
El inverso de discovery, para brownfield: no se inventa nada — se extraen hechos del sistema existente, como mapa + golden.
El ACCEPTANCE de lo no-testeable: puntúa el cambio contra un RUBRIC.md versionado. Advisory por default.
Estado real a vista de pájaro: readiness, sub-scores, fases, invariantes y loops de QA. La skill cablea — no calcula.
El deck de sistema en dos pistas — comercial y técnica — con métricas reales del ledger. Reporte opcional, a pedido.
El statusline a demanda: readout de progreso de una línea, para superficies donde el statusline no se ve.
Para profundizar: la documentación completa
Todo lo de abajo se genera desde el mismo repo del que sale el kit — las docs y el código viajan juntos.
Por qué existe uscha
Loop abierto vs. grafo medido: quién contesta las compuertas, y por qué el loop se enjaula en vez de eliminarse.
deck htmlEl Playbook
El manual del operador: jugadas 00–10, de leer el tablero a saber cuándo saltear el método por completo.
deck htmlReferencia de skills
Las nueve skills, fase por fase: qué lee cada una, qué escribe, y qué no debe hacer jamás.
brief htmlUscha, destilado
El método completo en una página: reglas, gates y el ledger — el brief imprimible.
deck htmlPitch para equipos
El deck extendido para llevar el método a un equipo: el caso, la mecánica, el camino de adopción.
paper html · pdf · inglésEl paper
El tratamiento formal: una metodología fact-gated y tool-agnóstica para desarrollo spec-driven con agentes de código LLM.
Lo medido le gana a lo narrado — también acá
El motor es qa_ledger.py: Python puro, sin pip installs. Ingesta evidencia de
maven, gradle, ant, python, node, go, rust, dotnet, cpp, swift y flutter, y la registra en
QA-LEDGER.json — un ledger determinístico que anota lo que se midió, nunca lo que se afirmó.
"Check" es una pregunta. El agente respondió con un commit.
Un humano pidió "revisá" unos errores de QA remoto. El agente diagnosticó bien — y en el mismo turno, sin mostrar el diagnóstico ni esperar respuesta, anunció "diseño cerrado", editó tests y código de producción, y corrió el build. Entre la pregunta y el código modificado: cero puntos de decisión humana. La ejecución fue competente; la falla fue de gobernanza. Ese es exactamente el agujero que Uscha existe para cerrar.