TheStreamCode/agentic-rd-skill

Flujo de Trabajo de I+D Agentic

Usa este paquete de habilidad autocontenido para automatizar un flujo de trabajo de laboratorio multi-agente, basado en Markdown, dentro del espacio de trabajo actual.

Esta es una adaptación de propósito general del patrón Agent Laboratory: revisión de evidencia independiente, formulación colaborativa de planes, ejecución o investigación de tareas, análisis de resultados, revisión de calidad y redacción del informe final. No se limita a la investigación científica; aplica el mismo flujo de trabajo de laboratorio a casos de uso de producto, negocio, técnicos, estratégicos, legales, de cumplimiento, seguridad, experiencia de usuario, mercado y operaciones.

Diseñado para agentes de codificación compatibles con habilidades y con acceso al sistema de archivos. Prefiere subagentes paralelos reales siempre que el entorno lo admita; utiliza pases simulados aislados solo cuando los subagentes reales no están disponibles.

Contenido del Paquete

• SKILL.md: reglas de activación e instrucciones operativas principales.
• references/generalized-lab-model.md: modelo universal de Agent Laboratory y mapeo de casos de uso.
• references/workflow.md: secuencia completa de fases y puerta de aprobación.
• references/agent-roles.md: guía para la selección de roles especialistas.
• references/quality-rules.md: estándares de evidencia, incertidumbre, revisión y seguridad.
• references/implementation-notes.md: notas sobre instalación, andamiaje, subagentes y manejo de archivos.
• references/example-run.md: un ejemplo completo y compacto que muestra el rastro de archivos esperado y la calidad de salida.
• assets/templates/: plantillas Markdown para todos los archivos del flujo de trabajo.
• scripts/init-rd-workflow.mjs: script de andamiaje opcional.
• scripts/validate-skill.mjs: validación del repositorio para el paquete de habilidad público.

Primera Acción

1. Busca project-brief.md en el espacio de trabajo actual.
2. Si existe, léelo completamente antes de cualquier otro paso del flujo de trabajo.
3. Si no existe y el usuario proporcionó suficiente contexto, créalo con assets/templates/project-brief.md.
4. Si falta contexto esencial, pregunta solo las preguntas bloqueantes mínimas.
5. Una vez que exista el resumen, continúa sin pedir permiso entre las fases normales del flujo de trabajo.

Ejecuta scripts/init-rd-workflow.mjs para andamiar project-brief.md y los archivos work/ necesarios. El script no debe crear work/06-final-output.md.

Salidas Requeridas

Crea y utiliza esta estructura en el espacio de trabajo activo:

work/
├── 00-lab-notes.md
├── 01-orchestration-plan.md
├── 02-specialist-outputs/
├── 03-team-collaboration.md
├── 04-cross-review-notes.md
├── 05-stage-gate-review.md
└── 06-final-output.md

Cada fase del flujo de trabajo se asigna a una ruta de salida específica. Las fases numeradas de laboratorio (revisión de evidencia, formulación de planes, ejecución, análisis de resultados) no son archivos separados: se materializan como un archivo por especialista dentro de work/02-specialist-outputs/.

Fase	Ruta de salida
Configuración del laboratorio	work/00-lab-notes.md
Orquestación	work/01-orchestration-plan.md
Revisión de evidencia, plan, ejecución, resultados (un archivo por especialista)	work/02-specialist-outputs/NN-<rol>.md
Colaboración del equipo (consolidada por el orquestador)	work/03-team-collaboration.md
Revisión cruzada	work/04-cross-review-notes.md
Revisión de puerta de etapa	work/05-stage-gate-review.md
Síntesis final	work/06-final-output.md

No crees ni escribas work/06-final-output.md hasta que work/05-stage-gate-review.md diga Aprobado.

Flujo de Trabajo

1. Lee references/workflow.md para la secuencia canónica de fases.
2. Lee references/generalized-lab-model.md para mapear el caso de uso del usuario en las fases del laboratorio.
3. Lee references/agent-roles.md antes de seleccionar especialistas.
4. Lee references/quality-rules.md antes de la revisión cruzada, la revisión de puerta de etapa y la síntesis final.
5. Usa references/implementation-notes.md para el uso de scripts, el comportamiento de subagentes y los detalles de manejo de archivos.
6. Usa las plantillas de assets/templates/ para los archivos de flujo de trabajo generados.
7. Consulta references/example-run.md para un ejemplo completo y resuelto cuando no estés seguro sobre la calidad de salida esperada.

Escala Según el Resumen

Ajusta el peso del flujo de trabajo al resumen. No ejecutes un laboratorio completo de múltiples oleadas para una pregunta pequeña.

• Resumen trivial: el orquestador puede hacer un solo pase en línea sin subagentes. Registra la evidencia, las suposiciones y los riesgos en work/00-lab-notes.md, escribe una autoverificación corta en work/05-stage-gate-review.md y luego work/06-final-output.md. Los archivos intermedios de especialistas, colaboración y revisión cruzada son opcionales en este nivel. La regla de la puerta de etapa sigue vigente: no escribas 06-final-output.md hasta que 05-stage-gate-review.md diga Aprobado.
• Resumen pequeño o limitado: usa uno o dos especialistas, ejecuta una sola oleada y fusiona la colaboración en las notas del orquestador en lugar de un intercambio separado. Mantén la revisión cruzada, la revisión de puerta de etapa y la síntesis final como un solo pase rápido cada una.
• Resumen mediano: usa algunos especialistas en una o dos oleadas con un paso ligero de colaboración en equipo.
• Resumen grande o regulado: usa la secuencia completa de fases, múltiples oleadas, colaboración explícita del equipo y los roles de revisión relevantes.

Mantén siempre el mínimo obligatorio independientemente del tamaño: revisión de evidencia/contexto, formulación del plan, ejecución o investigación, análisis de resultados, cobertura de riesgos/suposiciones y la puerta de calidad de la etapa antes de la síntesis final. Todo lo demás es opcional y se añade solo cuando cambia materialmente el entregable. Consulta references/generalized-lab-model.md para los detalles de escalado.

Reglas de Ejecución

• Selecciona la menor cantidad de roles especialistas que cubran bien el resumen.
• Incluye siempre revisión de evidencia/contexto, formulación del plan, ejecución o investigación, análisis de resultados y cobertura de riesgos/suposiciones.
• Prefiere subagentes paralelos reales. Son el modelo de ejecución principal para esta habilidad, no una mejora opcional.
• En cada fase, genera todos los especialistas independientes antes de esperar los resultados. No ejecutes especialistas independientes uno a uno cuando haya subagentes paralelos disponibles.
• De lo contrario, simula especialistas como pases aislados. Cada pase debe leer solo el resumen, el plan de orquestación y su alcance asignado antes de escribir su propio archivo.
• Nunca combines el análisis del especialista, la revisión cruzada, la revisión de puerta de etapa y la síntesis final en una sola respuesta.
• Paraleliza el trabajo de los especialistas independientes, pero mantén las puertas de dependencia secuenciales: revisión antes del plan, plan antes de la ejecución, ejecución antes del análisis de resultados, revisión antes del informe final.
• Exige citas o notas de origen para afirmaciones fácticas cuando las fuentes estén disponibles.
• Marca las afirmaciones no respaldadas como suposiciones o inferencias.
• Preserva la incertidumbre y los límites de revisión de dominios regulados.

Protocolo de Equipo Colaborativo

• Trata a los subagentes como un equipo colaborador, no como redactores de informes desconectados.
• El Orquestador Maestro define los roles del equipo, la propiedad, las dependencias y las reglas de colaboración en work/01-orchestration-plan.md.
• Cada subagente escribe solo su propio archivo de salida de especialista y devuelve sus preguntas, dependencias, desacuerdos y notas de traspaso al orquestador (en su resultado, no editando un archivo compartido).
• El orquestador consolida esas notas devueltas en work/03-team-collaboration.md. Nunca permitas que varios subagentes escriban el mismo archivo concurrentemente.
• El equipo debe reconciliar las suposiciones compartidas antes de la revisión cruzada.
• La revisión cruzada evalúa tanto las salidas de los especialistas como el registro de colaboración del equipo.
• La síntesis final debe reflejar los acuerdos resueltos, los desacuerdos no resueltos y las opiniones minoritarias importantes.

Condiciones de Parada

Detente y pregunta al usuario solo cuando:

• El tema o el objetivo no sean identificables.
• La salida deseada no pueda inferirse.
• Las restricciones clave entren en conflicto.
• Datos externos requeridos, credenciales, sistemas privados, herramientas de pago o acceso a la red no disponible bloqueen el trabajo.
• No se pueda mantener el asesoramiento legal, médico, financiero, de cumplimiento, de seguridad o crítico para la seguridad dentro de un límite informativo seguro.

Finalización

Cuando el flujo de trabajo se complete, informa al usuario qué archivos se crearon y si la puerta de etapa aprobó la síntesis final. Mantén el mensaje de finalización conciso.