Referencia
Catálogo de prompts
Cada prompt que envía la cadena de herramientas, qué pide y cómo se degrada cada uno cuando la respuesta es inservible.
Cada punto de contacto con el LLM en la cadena de herramientas. Todas las llamadas que
producen JSON se ejecutan a temperatura 0 (se descarta automáticamente en los modelos de
tipo razonamiento). La narración en chino (--narrate-lang zh) mantiene en inglés las
claves JSON, los valores de enum, los ids y las rutas de archivo; solo cambian los valores
en prosa.
| # | Prompt (módulo) | Phase | Propósito | Contrato de salida |
|---|---|---|---|---|
| 1 | reglas de ficha brief (pipeline/cards.ts) | 2a | propósito en lenguaje llano de 1–2 frases + enum de role + pista de lifecycle por cada archivo del lote | {"purposes":[{file,purpose,role,lifecycle}]} |
| 2 | reglas de ficha deep (pipeline/cards.ts) | 2a | recorrido del archivo completo (120–300 palabras) + purpose / data_flow / relations por función, indexados por el qualname exacto; los hechos del grafo se declaran autoritativos | añade description, functions[] |
| 3 | fallback por fragmentos (pipeline/cards.ts) | 2a | las mismas reglas deep sobre un fragmento-función de un archivo sobredimensionado | una entrada purposes que cubre el fragmento |
| 4 | síntesis del esqueleto (pipeline/skeleton.ts) | 2b | espina narrativa ordenada a partir de los resúmenes agregados por directorio + los puntos de entrada; el orden de lifecycle es obligatorio; los transversales van tras el flujo principal | {"metadata":{archetype},"stages":[{id,title,description,parent,crosscut}]} |
| 5 | asignación de archivos (pipeline/assign.ts) | 2b | una etapa primaria por archivo desde un menú fijo; also 0–2; escape unassigned para código vendorizado o muerto | {"assignments":[{file,stage,also}]} |
| 6 | actor del doctor (pipeline/doctor.ts) | 2b | ≤3 cambios estructurales (add_stage / remove_stage / merge_stages / split_stage), priorizados: sin asignar → sobrecarga → inanición → muerto | {"changes":[…],"rationale"} |
| 7 | roles de crítico (llm/critic.ts) | 2b | revisión con rol interpretado (ingeniero / arquitecto / lector / editor) de una propuesta frente a evidencia de referencia; APPROVE con generosidad, REJECT solo cuando no tiene arreglo | {"decision","concerns","suggested_revision","rationale"} |
| 8 | prompt de revisión (llm/critic.ts) | 2b | revisión del actor que aborda los puntos [role] concern agregados | el mismo esquema que la propuesta original |
| 9 | organización de etapas (pipeline/organize.ts) | 2c | 2–8 subgrupos ordenados por etapa; cada archivo exactamente una vez; orden narrativo que respeta las pistas de llamadas | {"groups":[{title,summary,files}]} |
| 10 | clasificación de miembros (pipeline/member.ts) | 2b (member) | asigna funciones/métodos individuales a las etapas escritas por el usuario | {"assignments":[{member,stage}]} |
| 11 | resumen agregado de etapa (pipeline/narrate.ts) | 3 | resumen de etapa de 100–200 palabras para no expertos, a partir de los resúmenes hijos + las frases de una línea de cada archivo | solo prosa llana (sin JSON, sin encabezados) |
| 12 | resumen agregado del sistema (pipeline/narrate.ts) | 3 | resumen del sistema de 200–350 palabras que hilvana las etapas de nivel superior | solo prosa llana |
| 13 | extracción de registros (pipeline/narrate.ts) | 3 ronda 1 | registros de estado transversales (id + semántica en una línea + etapas tocadas) a partir de los resúmenes de etapa + las fichas data_model | {"registers":[{id,semantics,stages}]} |
| 14 | pasada de huecos de registros (pipeline/narrate.ts) | 3 rondas 2+ | SOLO los registros que faltan dada la lista ya encontrada; array vacío cuando no hay nada (el bucle se detiene tras 2 rondas secas) | el mismo esquema, solo entradas nuevas |
| 15 | prompt de sistema del planificador (planner/prompt.ts) | plan | enrutar con el handbook → leer el código fuente real → emitir bloques EDIT byte-exactos + JSON de declaraciones; reglas de «el ejecutor confía a ciegas» (unicidad, sin solapamiento, el menor tramo posible) | plan en markdown que termina en un bloque {"will_modify","will_add","will_remove"} |
| 16 | protocolo de herramientas del planificador (planner/prompt.ts) | plan | una acción JSON por turno: list_dir / read_file / grep / finish | bloque de acción {"tool": …} |
| 17 | etiqueta de evolución de resync (studio/server.ts) | studio resync | una frase de ≤40 caracteres que nombra QUÉ capacidades/módulos ha tocado un cambio, a partir de los propósitos de los archivos tocados; adivinar la intención está prohibido (el resync de studio no tiene diff); sin cliente recurre a una lista determinista de archivos | prosa llana, una línea (renderizada atenuada + etiquetada auto) |
Reglas de diseño que comparten los prompts
- Los hechos se inyectan, nunca se piden. Los inventarios de funciones, los rangos de líneas y las relaciones de llamada vienen del grafo y se marcan como verdad de referencia; el modelo escribe prosa alrededor de ellos, y se le indica que no los vuelva a listar.
- Los menús son cerrados. Los prompts de asignación y clasificación enumeran los ids
de etapa válidos e instruyen «nunca inventes»; cualquier cosa fuera del menú se fuerza a
unassignedal parsear, así que la deriva del prompt no puede corromper artefactos. - Todo contrato JSON tiene un validador mecánico en el lado que lo consume (zod o comprobaciones hechas a mano); las entradas descartadas o mal formadas se rellenan de forma determinista y se contabilizan en los artefactos de cobertura, en lugar de parchearse en silencio.
- Los finales solo-JSON / solo-prosa mantienen el parseo sin ambigüedades; el extractor de JSON tolera bloques de código delimitados y escaneos de llaves balanceadas, pero los prompts siguen pidiendo un único bloque delimitado.
- Los prompts de crítico se resisten a aprobar por inercia en ambas direcciones: aprueban las propuestas suficientemente correctas (nada de REVISE vacíos — se normalizan a APPROVE), pero una llamada de crítico rota cuenta como REJECT, de modo que los fallos de infraestructura nunca aprueban cambios.
Soporte de lenguajes
18 lenguajes repartidos en dos niveles de análisis — qué extensiones reclama cada uno, a qué renuncia el nivel generic y las dos salvedades que conviene conocer antes de toparte con ellas.
Índice de paquetes
Once paquetes npm, qué exporta cada uno y cuáles funcionan sin ningún LLM.