vladyslav-betterme/autopilot-skill

Autopilot

Un bucle autónomo portátil porque pregunta al trabajo qué significa «hecho» en lugar de asumirlo, y no se detiene hasta que esa respuesta esté satisfecha.

Tres afirmaciones que esta habilidad existe para hacer imposibles:

• «Funciona» cuando nada lo ejecutó.
• «Está hecho» cuando el único juez fue quien lo hizo.
• «Trabajé en ello» sin registro de lo que se intentó, falló o por qué.

El tema no importa. Una refactorización, una migración, un informe, un conjunto de datos, una granja de renderizado, un clúster: el bucle a continuación es idéntico y solo la verificación difiere.

0. Inicio — una vez por proyecto

<skill> a continuación es el directorio donde se encuentra este archivo — .agents/skills/autopilot después de una instalación CLI, o donde sea que se haya clonado. Ejecuta todo desde la RAÍZ del proyecto.

node <skill>/scripts/discover.mjs        # verificaciones, hogares de memoria, señales de peligro
node <skill>/scripts/bootstrap.mjs       # crea el libro de contabilidad si está ausente
node <skill>/scripts/skills.mjs          # la biblioteca de habilidades — elige los nichos de este proyecto
node <skill>/scripts/tools.mjs           # lo que esta máquina ya puede ALCANZAR: servidores MCP, plugins

discover imprime el comando de verificación propio del proyecto. Ese comando es la definición de hecho para cada iteración posterior.

Si imprime checks: [], no le creas todavía. El descubrimiento solo lee archivos que declaran una verificación; la verificación real de un proyecto a menudo se nombra en prosa. Busca en cada ruta que aparezca en memoryHomes, más el README y la configuración de CI, un comando ejecutable — un proyecto con checks: [] tenía un CLAUDE.md que nombraba ./tests/run_all.sh, que ejecutaba 63 pruebas en cuatro segundos, mientras que la verificación que un agente habría inventado (node --check) estaba verde en una aplicación muerta.

Solo cuando esa búsqueda vuelve vacía, el proyecto realmente no tiene una verificación automática — común para prosa, investigación y operaciones, y no es permiso para juzgar tu propio trabajo. Acuerda una verificación de aceptación antes de la iteración uno y escríbela en el objetivo (§1). Cualquiera de estas es una verificación; «Lo revisé y parece correcto» no lo es:

El trabajo	Una verificación que no es tu propia opinión
código	un comando que sale 0, ejecutado en primer plano
un documento	una lista afirmación por afirmación con una fuente o un comando por afirmación
datos	una consulta que otra persona pueda re-ejecutar y que devuelva la forma esperada
infra / ops	una observación del propio sistema, antes y después
investigación	la consulta o extracción que produce el número, más el resultado que registraste DE ANTEMANO como refutador — ambos re-ejecutables por otra persona

Lee lo que el descubrimiento encontró antes de tocar nada:

• memoryHomes — donde ya vive el conocimiento duradero. Usa esos archivos. Nunca crees un segundo CHANGELOG.md, un segundo directorio de aprendizajes, un segundo AGENTS.md. Un segundo hogar para un tipo de conocimiento es la forma más común en que un agente empeora un repositorio.
• signals.envFilesPresent y signals.remote — antes de la primera iteración, pregunta si el entorno de trabajo apunta a producción. Así ha sido, en proyectos donde nada en el repositorio lo decía y cada ejecución local parecía inofensiva. Asume que sí hasta que te digan lo contrario.
• signals.vcs — none significa que no existe deshacer. Copia las entradas en un lugar seguro antes de la iteración uno, y di dónde en goal.md; el «hacer commit de lo que está verde» de §8 no tiene significado aquí y es exactamente cuando se pierde trabajo.
• signals.dirty — el trabajo sin commit es de alguien. Rama, nunca construyas encima.

Ármate antes de la iteración uno

skills.mjs es la lista corta de habilidades públicas que vale la pena tener, etiquetadas por nicho. Las etiquetas son el vocabulario — any y review en cada proyecto, luego web, react, db, docs, perf, a11y, mac, infra, research, design según lo que el proyecto realmente necesite.

node <skill>/scripts/skills.mjs                            # el catálogo y sus etiquetas
node <skill>/scripts/skills.mjs --install any --dry-run    # lo que EJECUTARÍA
node <skill>/scripts/skills.mjs --install any              # el conjunto siempre útil
node <skill>/scripts/skills.mjs --install react,perf,db    # los nichos de este proyecto

Elige, no acumules. La descripción de cada habilidad instalada se carga en cada turno: cien habilidades no son cien capacidades, es una ventana más pequeña y un modelo que hojea.

Instalar es ejecutar código de terceros con tus permisos, por lo que es un acto anunciado: --dry-run primero, di lo que estás a punto de agregar y por qué, luego instala. Si el proyecto no coincide con ningún nicho en el catálogo, any solo es la respuesta correcta — y find-skills es el punto de entrada para un nicho en el que el catálogo es escaso (investigación, infra, datos son escasos hoy).

Luego mide lo que acabas de gastar. skill-cleaner viene con el conjunto any y es cómo «elige, no acumules» deja de ser un consejo:

node --experimental-strip-types <skills-root>/skill-cleaner/scripts/skill-cleaner.ts \
  --root .agents/skills --root-only --no-logs

Informa del presupuesto que ocupan las descripciones instaladas, duplicados (dos habilidades que responden una pregunta — el defecto que este bucle caza, un nivel arriba) y descripciones largas que vale la pena comprimir. Actúa al respecto: desinstala lo que este proyecto no usa y fusiona un duplicado en lugar de mantener ambos. Una auditoría que lees e ignoras cuesta el mismo contexto que ninguna auditoría.

Las habilidades son la mitad — la otra mitad es el alcance

skills.mjs dice lo que el agente SABE. tools.mjs dice lo que puede TOCAR: los servidores MCP que encuentra en los archivos de configuración que sabe leer, los plugins que traen más, y lo que nada en el disco puede decirte. Un resultado vacío significa «no en estos archivos», nunca «no en esta máquina».

node <skill>/scripts/tools.mjs

Una capacidad que te falta no es una razón para reducir el objetivo. Es una escalera — ya alcanzable → la propia CLI de la aplicación → un servidor público → un conector (estacionarlo, §6) → escribir uno con new-mcp.mjs. Los peldaños, lo que cuesta cada uno y las trampas en cada uno están en references/tooling.md; léelo antes de construir nada, porque los dos fallos que previene son invisibles desde aquí: decidir que una capacidad falta cuando ya está configurada, y construir una segunda respuesta a una pregunta que algo ya responde.

El que te morderá: la mayoría de los arneses leen su configuración MCP al INICIO, por lo que un servidor escrito a mitad de la ejecución suele ser invisible para la sesión que lo escribió. Por eso el andamio es también una CLI — node server.mjs --call <tool> '<json>', los mismos manejadores. Usa esa forma ahora y deja que la próxima sesión obtenga el servidor. «Continuar después de un reinicio» es un bucle estancado que sostiene un archivo.

Luego, a lo largo del proceso: lo que aprendes aquí se convierte en una habilidad propia (§5), escrita por el bucle y usada en la misma sesión — y una capacidad que le faltaba se convierte en una herramienta propia, usada de la misma manera.

1. El objetivo — lo que el bucle ejecuta hasta

Antes de la iteración uno, escribe una oración falsificable y 2–5 criterios de finalización. En goal.md, o lo que el descubrimiento haya encontrado que ya lo contiene.

• Falsificable: «mejorar X» no puede ser. «Cada ruta que gasta dinero está detrás de un grifo explícito, y cada uno está respaldado por un tipo o una prueba fallida» sí puede.
• Cada criterio debe ser verificable por alguien que no seas tú — el mismo estándar que §0. Un criterio que solo tú puedes confirmar no es un criterio; reescríbelo.
• Las incógnitas están permitidas, como criterios propios: «sabemos si N es la causa» es un criterio de finalización legítimo para investigación.
• Un objetivo grande se alcanza a través de pequeños, y los criterios SON esa descomposición — cada uno un segmento que puede ser entregado, verificado y validado por sí mismo. Un criterio demasiado grande para una iteración se divide en criterios propios; la profundidad está bien, y cada nivel mantiene el mismo estándar (verificable por alguien que no seas tú). Un nivel que deja de ser falsificable es un plan, no un criterio.
• Una capacidad que te falta es un criterio, no un desvío. «El bucle puede manejar X sin cabeza, comprobado por un viaje de ida y vuelta» va en la tabla junto al trabajo que desbloquea (references/tooling.md). Escrito, construir una herramienta está acotado y su ausencia es visible; no escrito, se convierte en una tarde que no produjo ningún criterio y se lee como progreso.
• Si nadie te dio un objetivo — «продовжуй» y nada más — la única salida de la primera iteración es un goal.md propuesto y la pregunta para el humano. Un criterio que tú creaste y luego satisfaciste es la afirmación #2 de arriba, con una lista de verificación.
• goal.md también lleva el estado FIJO: el comando de verificación, su salida base, la respuesta a la pregunta de producción, la rama (o dónde está la copia de las entradas) y qué habilidades se instalaron. Una reanudación que tiene que re-derivar eso no se ha reanudado.

El bucle entonces se ejecuta hasta que cada criterio se cumple Y se verifica. No hasta que el modelo se sienta terminado, no hasta que los críticos se callen — nunca lo hacen. Cada iteración termina marcando en goal.md qué criterio se movió y qué lo demuestra.

Detén el bucle temprano solo por las razones en §6 (preguntar), §7 (agitar) y §8 (contexto).

2. La iteración

Una iteración = un cambio entregado, verificado, validado, registrado. No un archivo, no un turno.

Elige. De los criterios no cumplidos del objetivo. Si varios están abiertos, toma aquel cuyo fallo invalidaría la mayor parte del otro trabajo — ordena por riesgo×alcance, no por lo que es fácil.

Comprende antes de acortar. Rastrea la cosa real de extremo a extremo. Luego, antes de construir algo nuevo, pregunta si ya existe — consulta references/premise-check.md, el hábito de mayor rendimiento individual en esta habilidad y el que más tiempo tomó aprender.

Construye la cosa más pequeña que sea realmente correcta. Causa raíz, no el síntoma que la solicitud nombra: encuentra todos los otros lugares con la misma forma primero, y arréglalo donde todos pasan a través.

Demuestra. Ejecuta la verificación descubierta, en primer plano, leyendo el código de salida en el shell que la ejecutó — o, mejor, deja que algo que no está escribiendo el resumen la lea por ti:

node <skill>/scripts/prove.mjs --record -- npm run verify   # la verificación, su estado real, en goal.md
node <skill>/scripts/prove.mjs --times 3 -- <check>         # una verificación que no está de acuerdo consigo misma es inestable

Probar y Verificar son los dos pasos que un modelo puede NARRAR — los otros dejan un archivo, un commit o un diff, mientras que «la verificación pasó» y «el revisor estuvo de acuerdo» fueron ambos texto escrito por el contexto que quería que fueran verdad. El ejecutor responde al primero: genera sin un shell, por lo que el estado que reporta es el propio del hijo; rechaza una verificación cuyo propio script npm contiene una tubería (`