Imported from Quinoto-Tech/QuinotoSpec (agent-dist/skills/quinotospec-create-rfc/SKILL.md). Install upstream with npx skills add Quinoto-Tech/QuinotoSpec --skill quinotospec-create-rfc. Copyright stays with the author.

Workflow: Create Rfc

Objetivo: crear un RFC nuevo usando el template oficial, guiando al usuario con preguntas iterativas y dejandolo listo para derivar una propuesta QuinotoSpec.

Flags:

• --party [agents]: Ejecuta Party Mode con los agentes especificados durante la fase de Contexto y Propuesta. El debate multi-agente enriquece el RFC con perspectivas cruzadas.
• --party-rounds <N>: Numero de rondas del party (default: 2)

Regla principal:

• El flujo es interactivo: pregunta una cosa por vez, espera respuesta y confirma antes de avanzar.
• Si el usuario ya dio un dato, no lo vuelvas a pedir.
• Si falta informacion, no generes el archivo hasta tener confirmacion final.

Preguntas obligatorias (en este orden):

1. TITLE: "Cual es el titulo del RFC?"
2. SLUG: proponer kebab-case en base al titulo y preguntar: "Uso este slug: ?"
3. AUTHOR: "Quien es el autor responsable?"
4. REVIEWERS: "Quienes son los revisores? (separados por coma)"
5. REFERENCE: "Que issue/ticket/documento lo referencia?"
6. PRIORITY: "Prioridad sugerida? (P1/P2/P3)"
7. COMPLEXITY: "Complejidad estimada? (Baja/Media/Alta)"
8. AFFECTED_SERVICES: "Que servicios impacta? (separados por coma)"
9. PREFIX (para tareas): "Cual es el prefijo QuinotoSpec para IDs de historias/tareas (formato MNEM-xxxx, ej. AUTH-a1b2)? Debe figurar en .quinoto-spec/prefix-registry.md o acordarse antes de registrarlo."

Confirmacion final obligatoria:

• Antes de escribir archivos, mostrar resumen:
  • Titulo
  • Slug
  • Autor
  • Revisores
  • Referencia
  • Prioridad
  • Complejidad
  • Servicios afectados
  • Prefijo QuinotoSpec (US/TSK)
• Preguntar: "Confirmas que genero el RFC con estos datos? (si/no)"
• Si responde "no", corregir solo los campos indicados y volver a confirmar.

Party Mode (opcional, solo si --party):

Si el usuario paso --party, ejecutar Party Mode despues de la confirmacion y antes de generar el RFC:

1. Resolver agentes:

   • Si --party incluye lista, usar esos.
   • Si --party sin agentes, auto-seleccionar basado en la propuesta del RFC:
     • RFCs de arquitectura → architect, devops-engineer, performance-optimizer
     • RFCs de seguridad → security-auditor, architect, devops-engineer
     • RFCs de features → architect, test-writer, security-auditor
     • Default → architect, security-auditor, test-writer

2. Ejecutar Party Mode: @quinotospec.party-mode "RFC: {{TITLE}}" --agents {{AGENT_LIST}} --rounds {{PARTY_ROUNDS}} --output .quinoto-spec/rfc/{{RFC_ID}}-{{SLUG}}-party.md

3. Incorporar conclusiones al RFC:

   • Consenso del party → enriquece 1. Contexto y 4. Propuesta
   • Riesgos identificados → alimenta 8. Riesgos y mitigaciones
   • Disenso → documentado en una sub-seccion Party Mode Insights dentro de 4. Propuesta
   • Recomendaciones → 9. Plan de pruebas

Generacion del RFC:

1. Usa el template base .cursor/templates/rfc-template.md.

2. Genera RFC_ID con formato RFC-YYYYMMDD-{{SLUG_UPPER}} (ejemplo: RFC-20260427-FEATURE-FLAGS).

3. Si .quinoto-spec/rfc/ no existe, crealo.

4. Crea .quinoto-spec/rfc/{{RFC_ID}}-{{SLUG}}.md.

5. Reemplaza placeholders del template:

   • {{RFC_ID}}
   • {{TITLE}}
   • {{SLUG}}
   • {{AUTHOR}}
   • {{DATE}} (YYYY-MM-DD)
   • {{REVIEWERS}}
   • {{REFERENCE}}
   • {{PRIORITY}}
   • {{COMPLEXITY}}
   • {{AFFECTED_SERVICES}}
   • {{PREFIX}} (si el template lo declara; si no, el prefijo solo va en la seccion de User Stories del paso 9).

6. Leer discovery consolidado como base minima de contexto:

   • .quinoto-spec/discovery/02-overview.md
   • .quinoto-spec/discovery/03-architecture.md
   • .quinoto-spec/discovery/04-endpoints-and-openapi.md
   • .quinoto-spec/discovery/07-findings-and-recommendations.md
   • .quinoto-spec/discovery/08-product-and-agreements.md

7. Completar el RFC con la data relevada interactivamente + discovery (no dejarlo en placeholders):

   • 1. Contexto: problema actual concreto del stack/servicio.
   • 2. Objetivo: resultado medible esperado.
   • 4. Propuesta: solucion tecnica inicial coherente con arquitectura vigente.
   • 6. Impacto tecnico: servicios, contratos y dependencias impactadas.
   • 7. Plan de implementacion: fases iniciales y orden sugerido.
   • 8. Riesgos y mitigaciones: al menos 3 riesgos reales con mitigacion.
   • 9. Plan de pruebas: unit/integration/e2e y criterio de exito.

8. Mantener estructura de secciones intacta y completar la seccion "Proposal Seed" para que quinotospec.create-proposal pueda usar este RFC como input directo.

9. Obligatorio para quinotospec.create-tasks: Incluir al final del RFC (antes de anexos si los hay) la seccion con heading exacto:

   ## User Stories (entrada para create-tasks)

   Contenido minimo:

   • Una linea: **Prefijo (QuinotoSpec):** {{PREFIX}} (el valor de PREFIX de la pregunta 9).
   • Una tabla con el mismo formato que quinotospec.create-user-stories (columnas: ID, User Story, Criterios de Aceptacion, Prioridad, Estimacion, Servicio). Los IDs deben seguir US-{{PREFIX}}-001, US-{{PREFIX}}-002, etc. (igual que en create-user-stories: si el prefijo es AUTH-a1b2, el primer ID es US-AUTH-a1b2-001).

10. Enviar al usuario la ruta final del RFC generado, un resumen de 3 bullets con decisiones clave, y la linea de comando sugerida para generar tareas:

@quinotospec.create-tasks --from-rfc .quinoto-spec/rfc/{{RFC_ID}}-{{SLUG}}.md

(ajustar la ruta al archivo real creado en el paso 4).

Resultado esperado:

• El usuario es guiado paso a paso y valida los datos antes de crear el archivo.
• RFC creado en .quinoto-spec/rfc/ con estructura uniforme, contenido inicial no vacio y compatible con derivacion a propuesta.
• La seccion ## User Stories (entrada para create-tasks) permite ejecutar quinotospec.create-tasks --from-rfc <ruta-al-rfc.md> sin pasar antes por proposal.md / user-stories.md en carpeta de propuesta.