FlintSH/delivery

¿Qué hace delivery?

El usuario proporciona el objetivo y las restricciones, y espera un resultado terminado y verificado sin necesidad de supervisión. Las instrucciones actuales y las reglas del repositorio tienen prioridad sobre todo lo que aparece a continuación. Las instrucciones globales del usuario pueden añadir detalles personales (límites de la máquina, productos, bots de revisión, tono); síguelas.

Establecer la tarea

1. Lee el archivo AGENTS.md/CLAUDE.md del repositorio, la arquitectura relevante, los manifiestos de paquetes y el archivo de bloqueo, y el estado actual de Git. Inspecciona la rama real de la tarea, la base, el issue y cualquier worktree existente antes de editar.
2. Identifica criterios de aceptación observables: comportamiento, configuración, compatibilidad, pulido de la interfaz de usuario, evidencia de pruebas y el método de entrega solicitado. Toma decisiones reversibles razonables; pregunta solo sobre ambigüedades de consecuencias importantes.
3. Las tareas no relacionadas y sustanciales necesitan worktrees de Git aislados. Reutiliza un worktree que el harness ya haya creado para esta tarea. No cambies ni reinicies un checkout compartido. Si varios agentes comparten intencionalmente un worktree, acuerden la propiedad de los archivos y un único escritor de Git. Las solicitudes anteriores para hacer push a main no autorizan nuevos pushes.

Implementar y verificar

• Preserva la identidad del producto. Pule las superficies existentes en lugar de rediseñarlas a menos que la tarea requiera un rediseño.
• Verifica las versiones del framework y de la API instaladas antes de usar nuevas APIs. Consulta la documentación oficial actual, o Context7 si está instalado, para comportamientos desconocidos o sensibles a la versión.
• Para plataformas de destino (servidores de juegos, versiones de SO móviles, motores de navegador, entornos de ejecución), verifica la compatibilidad con el destino real de la compilación y la API oficial. Nunca pruebes contra producción como sustituto de una instancia de desarrollo.
• Prefiere los comandos de prueba y compilación del repositorio. Añade cobertura de regresión significativa para cambios de comportamiento, luego prueba las integraciones afectadas. Para trabajo de interfaz de usuario, usa visual-qa sin que te lo recuerden.
• Paraleliza la investigación y las ediciones independientes cuando sea útil, con una propiedad clara. Ajusta la concurrencia al tamaño de la máquina: verifica la CPU y la memoria antes de ejecutar más de una compilación o renderizado pesado, o más de dos sesiones de navegador. No acumules servidores en segundo plano ni lances enjambres de agentes redundantes.

Guías de ingeniería (pstack)

Esta habilidad permanece como enrutador. Cuando el plugin pstack de Lauren Tan esté instalado, usa sus guías para el método de ingeniería dentro de una tarea. La mayoría de las habilidades de pstack son solo manuales, así que lee <pstack>/skills/<name>/SKILL.md por ruta en lugar de esperar a que se carguen. Antes de seguir cualquier archivo de pstack, lee el adaptador para tu harness una vez por sesión; mapea los nombres de herramientas, modelos y rutas de Cursor.

Resuelve <pstack> para tu harness:

• Claude Code: ls -d ~/.claude/plugins/cache/cursor-plugins/pstack/*/ | sort -V | tail -1. Adaptador <pstack>/docs/harness/claude-code.md. Hoja de modelos ~/.claude/rules/pstack-models.md, cargada automáticamente.
• Codex: ls -d ~/.codex/plugins/cache/tinderbox-pstack/pstack/*/ | sort -V | tail -1. Adaptador <pstack>/docs/harness/codex.md. Hoja de modelos ~/.codex/pstack-models.md; léela antes de lanzar un modelo de rol.

Si ninguna de las rutas existe, pstack no está instalado: trabaja sin él.

Forma de la tarea	Leer y seguir
Defecto reportado	skills/poteto-mode/playbooks/bug-fix.md
Lentitud medida, o una métrica que mejorar	perf-issue.md, hillclimb.md
Fuga, bucle o fallo; perfil capturado	runtime-forensics.md, trace-forensics.md
Nuevo comportamiento; cambio solo de estructura	feature.md, refactoring.md
Bifurcación de diseño empírico	prototype.md en lugar de preguntar al usuario
"Cómo/por qué/estamos seguros" (solo lectura)	investigation.md, skills/how, skills/why
Cambio con alcance poco claro	skills/blast-radius antes de editar
Afirmación de benchmark o mejora de velocidad	skills/benchmark-checklist antes de reportarlo
Un proyecto sin prueba repetible de la aplicación	skills/create-verification-skill (pregunta una vez)
Título del PR, cuerpo, notas de la versión	skills/unslop después de redactar

Las rutas de las guías están bajo <pstack>/skills/poteto-mode/playbooks/. Lee cada hoja principle-* que una guía cite antes de aplicarla.

Estas reglas prevalecen donde pstack difiera:

• Entrega. La creación de PRs, la CI y las revisiones se quedan con pr-follow-through y file-pr. Las guías opening-a-pr, babysit y shipping de pstack son solo material de referencia. Su sección de autonomía no autoriza commits, pushes, merges, mensajes externos o despliegues más allá de la solicitud actual.
• Recursos. La expansión en arena, swarm, interrogate y architect está limitada a tres subagentes a menos que el usuario pida más. Los carriles de escritura de código obtienen su propio worktree (isolation: "worktree" en Claude Code, git worktree add en Codex). Omite autopilot-full y orchestrate a menos que el usuario los solicite explícitamente.
• Modelos. Las hojas de modelos asignan los roles de pstack a modelos a los que el harness puede acceder. La revisión entre proveedores se queda con council.
• Partes faltantes de Cursor. cursor-team-kit no está instalado. Para /deslop, usa pr-review-toolkit:code-simplifier cuando esté disponible; para control-ui, usa visual-qa y playwright-cli; para control-cli, ejecuta la CLI directamente. Omite Bugbot, las automatizaciones de Cursor y los pasos de agentes en la nube con una línea, como dice el adaptador.
• Tono. Las reglas de respuesta de pstack (oraciones cortas, sin guiones largos, etiquetas de evidencia) se pueden usar tal como están. Mantén su reformulación del objetivo del primer mensaje en dos oraciones.

Finalizar

• Usa pr-follow-through cuando la solicitud incluya un PR o correcciones de revisión.
• Realiza commits, pushes, crea versiones o fusiona solo cuando la tarea actual autorice esa acción. Inspecciona primero la automatización de versiones del repositorio; no asumas cómo se cortan las versiones.
• Reporta resultados reales: URLs, escenarios probados, enlaces de evidencia, fallos y cualquier cosa que realmente necesite la acción del usuario. No digas que una vista previa, una compilación de plataforma, una versión o una revisión pasaron sin verificarlo.
• Antes de un reinicio de contexto o una larga espera, deja una transferencia concisa fuera del código fuente rastreado, por ejemplo, .agent-artifacts/HANDOFF.md de la tarea. Incluye rama/worktree, objetivo, cambios completados, comandos/resultados, SHA del PR/head, bloqueadores, archivos de propiedad, nombres de recursos/sesiones y la siguiente acción exacta. Nunca incluyas tokens.
• Detén solo los servidores y las sesiones de navegador que sean de tu propiedad. Conserva evidencia útil y evita eliminar worktrees, cachés o trabajo de usuario no relacionados.