Communitygithub.com

Autoprompt

Autoprompt es una habilidad para agentes de codificación que reduce los fallos en un 45 % en tareas de codificación agénticas.

¿Qué es Autoprompt?

Autoprompt es un bucle de orquestación que prioriza la utilidad, diseñado para tareas de codificación agénticas con agentes como Claude Code, Cursor y Codex. Reduce los fallos en un 45 % al garantizar que cada misión se almacene una vez, se produzca una hoja de ruta ejecutable aprobada de forma independiente y se envíen directamente carriles listos para implementar. La habilidad emplea una estricta estructura de gobernanza con `PROMPTS.txt`, `ROADMAP.md` y `GATELOG.md`, y utiliza una topología de alcance adaptativa (acotada, multisuperficie o inusualmente grande) para descomponer tareas complejas. Soporta pruebas unitarias reales (≥95 % de cobertura), revisión ciega y verificación en tiempo de ejecución, al tiempo que gestiona la concurrencia a través de modos como `tokensaver` o `wide`. Autoprompt se basa en el estándar OMP (Orquestación de Múltiples Agentes) v17.4.0 o posterior y utiliza personajes `ap-*` registrados para la ejecución jerárquica, evitando la auto-revisión y garantizando una gobernanza sólida de los artefactos.

Compatible con~Claude Code~Codex CLI~Cursor✓Antigravity
npx skills add Spielewoy/autoprompt-skill

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

¿Qué hace Autoprompt?

Autoprompt es un bucle de orquestación que prioriza la utilidad. Almacena la misión una vez, produce una hoja de ruta ejecutable aprobada de forma independiente, envía directamente carriles listos para implementar y prueba el comportamiento entregado con pruebas reales y una revisión fresca.

1. Contrato de inicio

La invocación autoriza la misión. No pidas al usuario que reformule, limite o apruebe la misión.

Cargar la habilidad o invocarla sin una misión nunca inicia ni reanuda una ejecución, independientemente de los artefactos sobrantes. Una invocación simple solo realiza la comprobación de frontera de la sección 10, informa del resultado y se detiene.

Antes de iniciar, resuelve solo los parámetros de operador no definidos:

  • Concurrencia: tokensaver (predeterminado, hasta seis en vivo), wide/billionaire (todo el trabajo listo y disjunto hasta el límite global), o custom max_subs=N.
  • Selección de agente: off/heredar. Los subagentes OMP heredan el modelo en tiempo de ejecución, por lo que la capacidad de esfuerzo es exactamente solo-heredada; nunca afirmes un esfuerzo seleccionable.

En una sesión con supervisión, pregunta todos los parámetros no definidos en una sola pregunta antes del trabajo con el repositorio/herramientas. En una ejecución supervisora no supervisada, no preguntes: usa por defecto tokensaver y agents=off y registra las suposiciones. Una bandera de omisión de permisos no es falta de supervisión.

Después del selector, envía al coordinador de alcance L1 ap-scope-coordinator; este envía al autor de la hoja de ruta que prioriza la utilidad. No hay un viaje de ida y vuelta de ingesta separado ni un agente de verificación previa obligatorio.

Una misión invocada siempre entra en orquestación: la topología de alcance acotada es la topología mínima, y el agente principal nunca se autotria silenciosamente una misión invocada para ejecutarla directamente. Omitir o limitar el envío es una decisión explícita registrada en GATELOG.md con su justificación, nunca una decisión silenciosa.

2. Ruta rápida de capacidad

Un supervisor puede proporcionar una atestación de capacidad versionada vinculada al proveedor/entorno de ejecución, versión de CLI, perfil de permisos, selector de agente, hash de definición de agente, hash de casting, estado/fuente de esfuerzo y éxito exacto de RUN/READ/WRITE. Úsala solo cuando cada vinculación coincida con el lanzamiento en vivo. Las ausencias, atestaciones mal formadas, obsoletas, desconocidas o contradictorias son fallos seguros.

Sin una atestación confiable, el primer autor de la hoja de ruta útil demuestra RUN, READ y WRITE contra una ruta de prueba desechable antes de la inspección del repositorio y luego continúa inmediatamente. Cualquier fallo detiene la ejecución antes de la implementación. La personalidad de verificación previa es solo de diagnóstico/recuperación.

3. Topología de alcance adaptativa

El alcance produce un único ROADMAP.md canónico.

  • Acotado: autor de la hoja de ruta, luego revisor independiente y verificador ciego fresco concurrentemente - 3 agentes, 2 rondas, objetivo inferior a un minuto;
  • Multisuperficie: exactamente 5 agentes, 3 rondas, objetivo inferior a cinco minutos; conserva la hoja de ruta completa del autor y la evidencia, agrega exactamente dos exploradores complementarios, luego revisor concurrente más verificador fresco sin un envío de síntesis redundante;
  • Inusualmente grande: puede exceder el presupuesto ordinario de 6 agentes solo con una razón de escalada concreta registrada.

La investigación externa se ejecuta solo cuando se requieren hechos externos actuales. Ante el rechazo, conserva la evidencia aceptada y repara solo los elementos nombrados. Las hojas de ruta vacías, los DAG inválidos, la propiedad superpuesta, los marcos/pruebas faltantes y la capacidad fallida son fallos graves.

4. Hoja de ruta ejecutable

ROADMAP.md es la única fuente de alcance/descomposición/plan de la nueva ejecución. Incluye puntero/hash de misión y nonce; perfil de alcance/escalada; inteligencia del repositorio; decisiones de marco/herramientas; IDs de elementos estables; categoría/etiqueta/nivel/marco; límites de propiedad; dependencias y grupos de lanzamiento; carril de integración; pasos de implementación; criterios de aceptación positivos; caminos infelices; pruebas primero; verificación real; cobertura >=95 % de líneas cambiadas y módulos tocados; y requiresDetailedPlan solo cuando sea necesario.

Los elementos listos para implementar se envían directamente a la compilación. Agrega G1 solo para trabajo de depuración/bloqueo profundo, una bifurcación de diseño no resuelta nombrada, requiresDetailedPlan: true, o un conflicto de plan informado por el trabajador.

Descompone la misión en cada carril genuinamente disjunto. Nunca colapses una misión multisuperficie en un solo carril "acotado" para reducir la hoja de ruta; las superficies disjuntas obtienen carriles disjuntos con propiedad disjunta.

5. Gobernanza de nueva ejecución

La gobernanza de nueva ejecución es exactamente:

  1. PROMPTS.txt - bloques de instrucciones exactos de solo añadidura;
  2. ROADMAP.md - hoja de ruta ejecutable canónica;
  3. GATELOG.md - transiciones de solo añadidura, procedencia de personalidad/modelo/esfuerzo, veredictos, hashes, tiempo transcurrido y frontera de reanudación.

No crees archivos de gobernanza de nueva ejecución como BRIEF.md, PLAN.md, AGENTS.md, COVERAGE.md, BACKLOG.md, ANCHOR.md, bucketlist.md, intake.md, scope-map.md o archivos de alcance por ángulo. Conserva la evidencia sustantiva de implementación/prueba/revisión/verificación. Los libros de contabilidad heredados permanecen legibles y los formatos mixtos contradictorios fallan en estado cerrado.

La gobernanza reside en la raíz de gobernanza de la ejecución fuera del repositorio de destino de la misión: PROMPTS.txt, ROADMAP.md y GATELOG.md nunca se escriben en el árbol de trabajo de destino y nunca deben aparecer en su diff.

6. Informes compactos con puntero

El primer autor de la hoja de ruta almacena la misión exacta en PROMPTS.txt. Los informes posteriores llevan:

MISSION POINTER: lee el libro de contabilidad de instrucciones exacto antes de actuar; detente si su hash o longitud en bytes difiere.
ruta=<PROMPTS.txt> hash=sha256:<64 hex> bytes=<longitud en bytes UTF-8> nonce=<NONCE-DE-EJECUCIÓN>

Los trabajadores verifican la ruta, el hash, la longitud en bytes y el nonce antes de actuar. Envía solo rol, objetivo, límite, dependencias, criterios de aceptación, punteros de hoja de ruta/evidencia con hashes, esquema/ruta de salida y estado de modelo/esfuerzo. No pegues la misión, la transcripción, la hoja de ruta completa, la doctrina o el razonamiento adversario previo. Conserva la revisión ciega.

7. Jerarquía y envío

Cada trabajador es una personalidad ap-* instalada y registrada. Su definición de agente personalizada más el informe de tarea enviado son su contexto operativo completo. Un trabajador nunca debe cargar, invocar o reinvocar la habilidad Autoprompt ni iniciar una ejecución anidada de Autoprompt; ejecuta solo las instrucciones de su personalidad y el informe asignado. Cada envío vincula el nombre registrado de la personalidad prevista como tipo de agente: un agente anónimo, de "propósito general" o inventado dinámicamente es un envío inválido, y cualquier envío hijo debe nombrar otra personalidad ap-* registrada.

  • Conductor L0: inicia la ejecución e informa del veredicto final. En una nueva ejecución, envía solo los coordinadores L1 nombrados - ap-scope-coordinator para alcance, ap-feature-coordinator para compilación, ap-sweep-coordinator para convergencia - nunca un administrador L2 o un trabajador L3/L4 directamente; un inicio de trabajador directo es un colapso que omite al coordinador. ap-preflight-probe y ap-intake siguen siendo excepciones de diagnóstico y reanudación heredadas, nunca inicios rutinarios.
  • Coordinadores L1 (ap-scope-coordinator, ap-feature-coordinator, ap-sweep-coordinator): poseen el alcance, el grupo de características o la convergencia y solo envían. Cada uno envía ap-manager para un segmento multifuncional o multipista, o trabajadores L3/L4 nombrados directamente en un solo carril acotado.
  • Administrador L2 (ap-manager): opcional para un segmento multifuncional o multipista; envía trabajadores L3/L4 nombrados y nunca ejecuta.
  • Ejecutores L3 (ap-scoper, ap-researcher, ap-synthesizer, ap-planner, ap-implementer, ap-reviewer, ap-verifier, ap-sweeper, ap-execharness-resolver, ap-framework-generator): realizan trabajo de hoja de ruta/exploración/investigación/síntesis/planificación/compilación/revisión/verificación/barrido.
  • Hojas terminales L4 (ap-fresh-verifier, ap-depth-prober, ap-framework-validator, ap-juror, ap-goal-checker, ap-arbiter, ap-re-anchor, ap-scribe, ap-janitor): realizan verificación ciega, bloqueo profundo, validación de marcos, jurados, verificación de objetivos, arbitraje, reanclaje, registros y limpieza.

L1 nunca ejecuta. Un solo carril acotado omite L2. Envía trabajo listo y disjunto juntos: emite cada inicio de un grupo listo antes de recolectar cualquier informe; el envío en segundo plano paralelo es la forma predeterminada, y la serialización solo está permitida para dependencias reales declaradas. Sin autorevisión. Reutiliza la evidencia válida y evita la propiedad duplicada.

Los subagentes extienden el trabajo del agente que los envía; nunca lo reemplazan. El despachador mantiene la síntesis, la integración y el juicio final. Los trabajadores de implementación, planificación y retransmisión de lectura ordinarios no deben rederivar el contexto que el despachador ya posee. Los agentes de aseguramiento independientes deben rederivar de forma independiente la verdad relevante sin leer los veredictos de los demás ni consumir las afirmaciones de éxito del autor.

Cada envío es recolectar-y-detener: detén ese agente explícitamente una vez que se recolecte su informe final; un agente reanudable estacionado sigue siendo un agente en vivo y cuenta contra el límite en vivo. Nunca dejes un agente finalizado inactivo para posibles seguimientos.

8. Modelo y esfuerzo OMP

OMP utiliza subagentes nativos de markdown con listas de spawns explícitas. Los roles generados omiten una anulación de modelo y heredan el modelo principal seleccionado. El casting y el esfuerzo son, por lo tanto, solo-heredados; agents=auto y las listas de modelos explícitas no se pueden enrutar a través de este adaptador.

OMP descubre la habilidad instalada y los archivos de agente ap-* desde su directorio de agentes. Las listas nativas de spawns aplican los bordes secundarios canónicos y OMP aplica el límite de recursión.

9. Compilación y verificación

Usa TDD estricto: escribe y ejecuta la prueba de comportamiento fallida correcta, implementa el cambio mínimo, refactoriza bajo verde, ejecuta los módulos tocados y los dependientes directos, y demuestra cobertura >=95 % de líneas cambiadas/módulos tocados. Usa ejecutores y sistemas reales. No simules el sistema bajo prueba ni las bases de datos en las pruebas de integración.

La revisión de implementación independiente y la verificación en tiempo de ejecución se ejecutan concurrentemente cuando ninguna consume el veredicto de la otra. El trabajo de depuración requiere evidencia de rojo a verde derivada del problema y bloqueo profundo en la función responsable más profunda.

HECHO requiere cobertura total de la misión/hoja de ruta, cero hallazgos abiertos, usabilidad, sin regresiones de verde a rojo preexistentes, cobertura >=95 % de líneas cambiadas, ejercicio completo de extremo a extremo, validación exitosa del libro de contabilidad, cero subagentes en vivo y limpieza cuando esté habilitado.

10. Reanudación, dirección, arbitraje y git

La reanudación es explícita: solo una instrucción explícita de resume o un relanzamiento del supervisor reanuda una ejecución; la carga de la habilidad, la invocación simple o los artefactos sobrantes nunca lo hacen. La única lectura de inicio es la cola de GATELOG.md: su última fila de frontera lleva el puntero/hash de la misión, el nonce, la última compuerta aceptada y los IDs de elementos abiertos; informa ese estado en menos de 150 palabras y detente cuando no haya frontera activa. Ante una reanudación explícita, verifica el hash del puntero y envía la frontera abierta con informes compactos con puntero; los trabajadores, no el contexto de reanudación, leen ROADMAP.md, PROMPTS.txt y la evidencia sustantiva. Trata los artefactos temporales, vacíos o no analizables como ausentes. Agrega la dirección posterior autogenerada al siguiente bloque de PROMPTS.txt sin reescribir el historial.

El árbitro decide las bifurcaciones técnicas. Pregunta al usuario a mitad de la ejecución solo por acciones irreversibles/destructivas genuinamente propiedad del usuario, dinero real/cuota, credenciales no disponibles o dirección del producto. Nunca arbitres fallos de capacidad, bloqueadores, cobertura o verificación real.

No hagas commit, push, publicar, desplegar, gastar dinero, eliminar datos del usuario, force-push, reset hard o limpiar el árbol de trabajo sin autorización explícita del usuario.

11. Ejecución

Usa OMP 17.4.0 o posterior e invoca explícitamente:

/skill:autoprompt <misión>

OMP descubre la habilidad instalada y los archivos de agente ap-* desde su directorio de agentes. Las listas nativas de spawns aplican los bordes secundarios canónicos y OMP aplica el límite de recursión.

Skills relacionados