De la necesidad a la entrega
Primero, aclara qué quiere cambiar el usuario y qué significa "completado", luego ejecuta. Continúa el trabajo autorizado de forma sostenida; cuando se necesite una decisión, completa primero las partes que no dependen de ella. No consideres "he escrito un plan", "el código compila" o "he iniciado un merge automático" como entregas finales.
Convenciones de trabajo
- Elige el método de desarrollo según el objetivo, el riesgo y el coste de la retroalimentación. Puedes escribir primero una especificación, seguir un enfoque de test primero en interfaces públicas claras, o implementar directamente y luego verificar; los métodos se pueden combinar. Define siempre condiciones de finalización observables y obtén evidencia del comportamiento real. No impongas un único flujo de trabajo a todas las tareas.
- Describe "qué es ahora" con el código actual, los resultados de ejecución y los artefactos de publicación reales; describe "qué debe ser" con los objetivos confirmados por el usuario. Si encuentras diferencias, corrige la implementación o la documentación desactualizada. No sobrescribas los objetivos del usuario con documentación antigua.
- Elige el proceso según la escala. Para cambios pequeños, la especificación puede ser unas pocas frases; solo para requisitos que crucen múltiples módulos, divide en fragmentos, diseña y documenta. No cargues todo el conocimiento para cada edición, establezcas cadenas de aprobación fijas ni rellenes plantillas vacías.
- El alcance ya autorizado por el usuario permanece vigente. La investigación, implementación y verificación reversible no requieren confirmación repetida; los lanzamientos externos se ejecutan según los objetivos explícitos del usuario. Si aún faltan objetivos de producción o autorización, prepara primero los artefactos, las diferencias, la reversión y la verificación, y luego explica qué falta.
- Este skill se puede usar de forma independiente. Cuando los siguientes skills estén instalados, invócalos según sea necesario; si no están instalados, completa directamente el resultado de esa fase sin exigir al usuario que instale todo el conjunto.
- Una tarea es impulsada de forma continua por el responsable actual. Los métodos especializados complementan la evidencia y los artefactos de la fase actual, utilizando decisiones confirmadas y el mismo registro, sin iniciar otro flujo competitivo.
Elegir el siguiente paso
| Situación actual | Modo de avance | Skill invocable |
|---|---|---|
| No sabe qué capacidad usar, o solo quiere conocer el modo de uso | Selecciona la entrada mínima según la tarea; primero explica el modo de uso, no confundas consulta con autorización de implementación | dev-help |
| Configuración inicial del entorno, modelo de roles o presupuesto de inferencia | Verifica las herramientas y modelos realmente disponibles, guarda preferencias breves; no asumas un proveedor fijo o capacidades del backend | dev-setup |
| Quiere que el trabajo repetitivo se adapte gradualmente a sus hábitos | Extrae patrones estables del historial de lectura permitido, formando habilidades de proyecto breves y mantenibles | dev-personalize |
| El usuario pregunta sobre el progreso durante la tarea, o necesita un informe de traspaso | Resume lo completado, la evidencia actual y los asuntos pendientes; responde y continúa la tarea original, a menos que se solicite explícitamente una pausa | dev-status |
| La entrada proviene de chat, Issue, captura de pantalla, registros o comentarios de múltiples fuentes | Encuentra la evidencia original, el comportamiento real, los objetivos y el alcance, fusiona solicitudes duplicadas | dev-intake |
| Necesita configurar informes o monitorear requisitos por fuente | Selecciona por separado la fuente, el rastreador, la ruta del repositorio, el método de control y el activador real, completa la inicialización dentro de la autorización | dev-issue-retroalimentación |
| Los informes de fuentes ya configuradas necesitan clasificación, deduplicación o derivación | Procesa la evidencia según el informe nativo, la identidad y el contrato del rastreador; las fuentes pueden ser chat, tickets, correo, alertas o entrada manual; en esta fase no se reproduce ni corrige | dev-issue-triage |
| El pipeline de informes está configurado, el triaje de confianza y las condiciones de control de UI real están listas | Verifica la asignación, reproduce o verifica parches existentes según el protocolo completo; cuando sea necesario y esté autorizado, corrige y entrega un PR borrador | dev-issue-fix |
| Las reglas del producto tienen ambigüedad crítica | Primero responde hechos a partir del código, clarifica ronda por ronda en torno a las preguntas que cambiarán el plan | dev-grill |
| El requisito está claro pero aún no se puede verificar directamente | Escribe comportamiento del usuario, límites, no-objetivos y condiciones de éxito | dev-spec |
| El usuario quiere profundizar o reescribir una solicitud pendiente | Usa cuatro preguntas para verificar omisiones profesionales, material original, método específico y evidencia independiente, entrega un prompt utilizable | dev-sharpen |
| Se hace cargo de un módulo desconocido | Recorre un caso de uso real: entrada, negocio, almacenamiento, retroalimentación y ruta de fallo | dev-learn |
| No entiende por qué existe un diseño histórico | Diferencia comportamiento actual, razones en ese momento y conjeturas, rastrea el código y la evidencia de decisiones disponible | dev-why |
| Hay compensaciones sustanciales en límites o interfaces | Compara diferentes estructuras; juzga desde la experiencia del llamante, la propiedad del estado y la terminología del dominio | dev-architecture |
| Ya existe o se va a crear un modelo TLA+, necesita un diagrama de estado con resultados de verificación | Ejecuta TLC, genera marcas de reglas y el contraejemplo más corto, verifica gradualmente contra el código real | dev-statechart |
| Necesita verificar propiedades clave, elegir herramientas formales o mantener el modelo | Define propiedades, suposiciones y límites, ejecuta la verificación e identifica la deriva del modelo; los diagramas explicativos normales no entran automáticamente en este flujo | dev-formal-verify |
| Involucra páginas, interacciones, sistemas de diseño o verificación visual | Utiliza componentes y tokens del código real; lee las guías de diseño según el contexto de producto o marketing, no requiere cuenta de herramienta de diseño | dev-ui-design |
| El requisito no se puede entregar de forma fiable en una sola vez | Divide en fragmentos funcionales verticales verificables, dependencias explícitas, primero ejecuta la ruta completa mínima | dev-plan |
| Hay trabajos que no entran en conflicto o diferentes planes que vale la pena comparar | Asigna el alcance de escritura y las reglas de aceptación, luego integra y valida el resultado final | dev-parallel |
| La especificación o los fragmentos están listos para implementar | Implementa según las normas de ingeniería existentes, conecta el comportamiento real, verifica los artefactos actuales | dev-build |
| Issue normal, error de funcionalidad CLI/API/UI o fallo de verificación | Reproduce desde la entrada real y localiza la causa raíz; solo cuando el objetivo es una métrica de rendimiento, entra en flujo de medición | dev-debug |
| El usuario ha especificado test primero, o la implementación actual ha elegido TDD | Completa casos de prueba fallidos y la implementación mínima uno por uno en la interfaz pública; las pruebas complementarias para comportamiento correcto no entran automáticamente en rojo-verde | dev-tdd |
| Errores similares se repiten o las restricciones clave son fáciles de eludir | Prioriza mejorar tipos, interfaces y propiedad del estado; cuando tenga valor real, añade reglas ejecutables | dev-guardrails |
| Implementación completada | Verifica por separado la conformidad con la especificación y la calidad de ingeniería; corrige problemas reales | dev-review |
| Necesita demostrar que la ruta de usuario real funciona | Conduce la aplicación real, verifica resultados y efectos secundarios, mantiene un método de verificación reproducible | dev-verify |
| El objetivo es mejorar latencia, rendimiento, recursos u otras métricas medibles | Fija la carga de trabajo y la métrica, completa la recopilación de evidencia, optimización o comparación justa, reutilizando la misma línea base | dev-benchmark |
| El objetivo incluye el lanzamiento | Confirma el entorno y la versión, ejecuta el despliegue autorizado, verifica el servicio real y registra | dev-deploy |
| Necesita documentación clara, notas de commit o resumen de PR | Organiza la información según las preguntas del lector, proporciona comportamiento específico, evidencia y compensaciones necesarias | dev-writing |
| Un requisito ya ha sido entregado o detenido explícitamente | Organiza nuevo conocimiento, corrige conflictos, conserva razones valiosas y archiva el proceso | dev-archive |
Si hay especificación, impleméntala directamente; si solo se pide diseño, entrega el diseño; si solo se pide explicación, quédate en la explicación. Lee Avance y recuperación para manejo de paralelismo e interrupciones. Si necesitas refinar los requisitos, lee Transición de fases de requisito a implementación; al ejecutar la tarea seleccionada, lee Método de operación de ingeniería; complementan la fase actual, no reseleccionan una fase ya completada.
Cuando no exista un flujo predefinido adecuado para una tarea compleja, utiliza Método de ejecución personalizado para formar unidades verificables y continuar con el trabajo autorizado. Para el registro y la revisión posterior de tareas largas, utiliza Método de evidencia de decisión para verificar si las decisiones, alternativas y evidencia real se corresponden; cuando solo se solicite revisión, entrega el resultado de la auditoría, no continúes automáticamente con la migración o implementación. Rastrear por qué se adoptó un diseño en ese momento es responsabilidad de dev-why. Cuando el usuario solicite explícitamente construir un panel de estado operativo, trátalo como una tarea de implementación; para solo consultar el progreso, usa dev-status.
Hacer que el trabajo pueda continuar
Los materiales nuevos del proyecto añadidos por este conjunto de skills se unifican bajo .agents/wtadev/ como raíz, utilizando las siguientes particiones según sea necesario. Los materiales existentes se consultan en su ubicación real y se conservan las referencias necesarias; solo se trasladan cuando se solicita explícitamente, conservando contenido, identificadores y enlaces válidos. Cuando el usuario especifique explícitamente otra ubicación para esta sesión, sigue sus instrucciones:
.agents/wtadev/changes/<fecha-tema>/: brief, spec, plan, progress, evidence del requisito actual, se crean según sea necesario..agents/wtadev/notes/: terminología verificada, contexto, decisiones, errores experimentados y comprensión de módulos; elindex.mdsolo apunta..agents/wtadev/deploy/<entorno>/: manuales de despliegue y registros de lanzamiento históricos enreleases/..agents/wtadev/archive/changes/,.agents/wtadev/archive/notes/: trabajo finalizado y conocimiento histórico, claramente no representan el comportamiento actual.
Estos son materiales del proyecto objetivo, no deben escribirse dentro del paquete de instalación .agents/skills/. Cuando se necesite recuperar, utiliza la Plantilla de traspaso, dejando solo el resultado actual, la evidencia, los problemas pendientes y el siguiente paso.
Cierre
Compara con los objetivos de entrega iniciales, proporciona los cambios reales, la evidencia de verificación de la versión actual, la dirección de entrega o commit, y las partes que no se completaron. Si el lanzamiento es necesario pero no se ha desplegado, escribe claramente "Implementación completada, despliegue pendiente"; después de un despliegue exitoso, integra el conocimiento reutilizable y las referencias del código más reciente en el proyecto, en lugar de volcar todo el historial de chat en AGENTS.md.
Material local completo
Consulta el Índice de métodos para elegir los flujos completos, reglas de verificación, ejemplos y plantillas dentro de este skill. Todos los recursos necesarios para la ejecución están contenidos en este paquete, sin depender de la instalación de otros skills; solo lee el contenido necesario para la rama de la tarea actual.