| name | agent-workflow |
| description | Usa este skill como protocolo maestro del agente en cualquier proyecto. Aplica siempre que el agente reciba una tarea (feature, bug fix, brainstorming) o llegue a un proyecto sin contexto. Orquesta los sub-skills: docs-structure, requirements-format, iteration-rules, project-resumption y project-documentation. Si algo de negocio no está claro, el agente pregunta — nunca infiere.
|
Agent Workflow — Protocolo de Trabajo
El agente es un ejecutor disciplinado: trabaja con lo que está documentado, pregunta lo que no entiende, reporta lo que implementó, y nunca se desvía del scope sin avisar.
Flujo general
Entrada al proyecto
Si es la primera vez o el agente no tiene contexto fresco, ejecutar project-resumption antes de cualquier otra cosa.
Por tipo de tarea
Implementar feature:
- Leer el feature completo (
requirements-format)
- Agrupar todas las dudas y presentarlas juntas (ver Protocolo de clarificación)
- Descomponer en tareas (
iteration-rules) y confirmar plan con el dev
- Implementar tarea por tarea con checkpoints por bloque significativo
- Actualizar
context/ al avanzar, memory/ al completar
Brainstorming:
- Leer el doc de brainstorming del desarrollador
- Responder preguntas, proponer ideas
- Cuando haya consenso, redactar feature draft en
.docs/features/
Corrección / Bug fix:
- Leer
context/ y memory/ para entender historial
- Diagnosticar, proponer fix, pedir confirmación
- Implementar y registrar en
memory/
Reglas universales
No inferir contexto de negocio
El agente no asume reglas de negocio, validaciones ni flujos que no estén documentados. Si el A/C no especifica qué pasa en un caso, preguntar con opciones concretas: "El A/C no especifica X. ¿Debería [opción A] o [opción B]?"
Protocolo de clarificación
Antes de implementar, agrupar todas las dudas en categorías (negocio, técnica, scope) y presentarlas juntas en un solo mensaje. No preguntar una por una. No empezar a implementar hasta resolver las dudas críticas; las menores pueden resolverse durante la implementación.
Checkpoints de validación
Antes de cada bloque significativo, presentar qué se va a implementar, qué archivos se tocan y qué A/C cubre. Pedir confirmación.
Hacer checkpoint antes de: crear estructura de archivos nueva, modificar lógica de negocio existente, cambiar schema de DB, configurar infraestructura, o cuando hay más de una forma válida de resolver algo. No hacer checkpoint para cambios triviales ni pasos obvios dentro de un bloque ya confirmado.
Regla de No-Drift
Si durante la implementación el agente detecta scope creep, dependencias no contempladas, inconsistencias entre A/C y código existente, o decisiones de diseño no cubiertas: pausar, reportar al desarrollador con contexto (qué detectó, impacto, opciones, recomendación). No resolver creativamente en silencio ni asumir que "seguro está bien".
Conexión con skills de implementación
Al pasar de planificación a ejecución, el agente debe consultar software para activar las skills correctas según el tipo de tarea (frontend, backend, architecture). software es el orquestador que enruta a las sub-skills técnicas y activa automáticamente las transversales obligatorias (clean-code-principles, typescript-patterns, git-usage).
Flujo completo: agent-workflow (protocolo) → software (enrutamiento técnico) → sub-skills específicas (implementación).
Si el feature involucra datos personales, tokens, cookies o normativas → consultar también governance-risk-and-compliance.
Sub-skills
