g-ki/agent-skills

Pensamiento Productivo

Facilita una sesión de diseño estructurada utilizando el Modelo de Pensamiento Productivo de Tim Hurson y, opcionalmente, redáctala como un RFC.

Entrada

$ARGUMENTS

• Si la entrada comienza con rfc, ejecuta el modo RFC. Todo lo que sigue después es un título o ruta de salida opcional.
• De lo contrario, ejecuta el modo interactivo, tratando la entrada como el enunciado del problema. Si está vacío, pide al usuario que describa el problema en una o dos oraciones antes de hacer cualquier otra cosa.

Cómo facilitar

• Fundamenta todo en el código. Antes de cada paso, busca y lee los archivos, esquemas, configuraciones y documentación relevantes, y cita las rutas cuando te bases en ellos. El valor de esta sesión sobre una charla en la pizarra es que las conclusiones se apoyan en lo que el sistema realmente hace; por lo tanto, verifica en lugar de asumir. Para barridos amplios a través de muchos archivos, delega a un subagente Explore para que el contexto de la sesión se mantenga enfocado en la discusión.
• Mantén la carga del usuario ligera. Haz como máximo 5 preguntas por turno, y acompáñalas con tus propias respuestas sugeridas basadas en lo que encontraste, para que el usuario pueda responder "sí, casi, pero…" en lugar de empezar desde una página en blanco.
• Un paso por turno. Abre cada paso con un encabezado como Paso 2 de 6 — ¿Qué es el éxito?, realiza el paso, luego detente y espera. Avanza solo cuando el usuario esté listo; permítele saltar, revisitar o moverse entre pasos.
• Mantén un archivo de notas en ejecución. Después de cada paso, agrega el resultado acordado a <directorio-rfc>/<slug>.notes.md (elige <directorio-rfc> como se describe en el modo RFC, paso 3). Las sesiones largas se compactan o se reanudan más tarde; el archivo de notas es lo que permite que el modo RFC, o una nueva sesión, retome sin perder decisiones. Indica al usuario dónde está la primera vez que lo crees.

Los seis pasos

1. ¿Qué está pasando?

Objetivo: comprensión compartida de la realidad actual y el futuro deseado. Explora las implementaciones existentes, los puntos de llamada, los modelos de datos y el historial reciente de git de las áreas afectadas. Cubre: el punto de dolor o cuello de botella (con evidencia como errores, métricas o código), los módulos y servicios impactados, quiénes se ven afectados y cómo se ve la "solución".

2. ¿Qué es el éxito? (DRIVE)

Objetivo: criterios contra los cuales se evaluará cada opción. Propón un borrador a partir del Paso 1 y permite que el usuario lo corrija.

• Do (Hacer): lo que la solución debe hacer
• Restrictions (Restricciones): limitaciones duras (retrocompatibilidad, presupuestos de rendimiento, stack, cumplimiento normativo)
• Investment (Inversión): tiempo, personas y complejidad que el equipo está dispuesto a dedicar
• Values (Valores): principios de ingeniería que rompen empates (simplicidad, testabilidad, …)
• Essential outcomes (Resultados esenciales): resultados no negociables, medibles cuando sea posible

También captura explícitamente los no-objetivos.

3. ¿Cuál es la pregunta?

Propón 2–3 preguntas "¿Cómo podríamos…?" que enmarquen el desafío de manera diferente, por ejemplo, una estrecha y otra que cuestione una suposición del Paso 1. El usuario elige o reescribe una; se convierte en el enunciado del problema para el resto de la sesión.

4. Generar respuestas

Propón 2–3 enfoques genuinamente distintos, fundamentados en el código base, no variaciones de una misma idea. Para cada uno: un breve esbozo, los archivos o módulos que toca, y su principal riesgo. Retén el juicio en este paso e invita las propias ideas del usuario.

5. Forjar la solución

Puntúa cada enfoque contra DRIVE (una tabla pequeña funciona bien), recomienda uno y nombra la compensación que estás aceptando. Luego, refuérzalo: modos de fallo, casos extremos, preocupaciones de migración, preguntas abiertas. Registra por qué se descartaron las otras opciones; eso se convierte en "Alternativas consideradas".

6. Alinear recursos

Acuerda la forma de entrega, no tickets individuales: fases o hitos y qué hace demostrable cada uno, la parte más riesgosa que probar primero, estrategia de feature-flag y migración, estrategia de pruebas, despliegue y reversión, y qué monitorear. El desglose detallado de tickets viene después de /task-breakdown, que trabaja a partir del RFC. Finaliza ofreciendo generar el RFC.

Modo RFC

1. Encuentra la sesión: usa la conversación hasta el momento más el archivo de notas, si existe. Si no hay ninguna sesión, indícalo y ofrece iniciar una: pide el enunciado del problema y comienza el Paso 1.
2. Si faltan pasos, enumera cuáles y pregunta si se deben completar ahora o redactar el RFC con esas secciones marcadas como PENDIENTE (TBD). No inventes decisiones que el usuario no haya tomado.
3. Elige la ubicación de salida. Los archivos de RFC, notas y tareas son documentos de trabajo local del desarrollador: no rastreados por defecto, no comprometidos con el código. Busca una carpeta local existente e ignorada por git para ellos (revisa .gitignore y .git/info/exclude) y sigue su convención de nombres. Si no hay una, propón .rfcs/AAAA-MM-DD-<slug>.md y agrega .rfcs/ a .git/info/exclude, lo que lo ignora localmente sin modificar el .gitignore del repositorio. Usa una carpeta rastreada como docs/rfcs/ solo si el usuario dice que el equipo compromete los RFC.
4. Escribe el RFC usando templates/rfc.md, llenando cada sección a partir de la sesión y vinculando las afirmaciones sobre el código base con rutas de archivo.
5. Informa al usuario la ruta, y enumera cualquier sección TBD y preguntas abiertas.
6. Ofrece el siguiente paso: /task-breakdown <ruta-del-rfc> para convertir el RFC en tickets de 1 punto de historia que el equipo pueda tomar.