council

¿Qué hace council?

Reúne cuatro asesores para decisiones ambiguas:

• la voz de Claude en contexto
• un subagente Escéptico
• un subagente Pragmatista
• un subagente Crítico

Esto es para toma de decisiones bajo ambigüedad, no para revisión de código, planificación de implementación o diseño de arquitectura.

Cuándo usarlo

Usa council cuando:

• una decisión tiene múltiples caminos creíbles y ningún ganador obvio
• necesitas hacer explícitas las compensaciones
• el usuario pide segundas opiniones, disenso o perspectivas múltiples
• el anclaje conversacional es un riesgo real
• una llamada de sí/no se beneficiaría de un desafío adversarial

Ejemplos:

• monorepo vs polirepo
• enviar ahora vs esperar para pulir
• feature flag vs despliegue completo
• simplificar alcance vs mantener amplitud estratégica

Cuándo NO usarlo

En lugar de council	Usa
Verificar si la salida es correcta	santa-method
Dividir una funcionalidad en pasos de implementación	planner
Diseñar arquitectura de sistema	architect
Revisar código en busca de errores o seguridad	code-reviewer o santa-method
Preguntas factuales directas	simplemente responde directamente
Tareas de ejecución obvias	simplemente haz la tarea

Roles

Voz	Enfoque
Arquitecto	corrección, mantenibilidad, implicaciones a largo plazo
Escéptico	desafío de premisas, simplificación, ruptura de supuestos
Pragmatista	velocidad de entrega, impacto en el usuario, realidad operativa
Crítico	casos límite, riesgo de desventajas, modos de fallo

Las tres voces externas deben lanzarse como subagentes nuevos con solo la pregunta y el contexto relevante, no la conversación completa en curso. Ese es el mecanismo antianclaje.

Flujo de trabajo

1. Extraer la pregunta real

Reduce la decisión a una instrucción explícita:

• ¿qué estamos decidiendo?
• ¿qué restricciones importan?
• ¿qué cuenta como éxito?

Si la pregunta es vaga, haz una pregunta aclaratoria antes de convocar al consejo.

2. Recopilar solo el contexto necesario

Si la decisión es específica del repositorio:

• recopila los archivos, fragmentos, texto del issue o métricas relevantes
• mantenlo compacto
• incluye solo el contexto necesario para tomar la decisión

Si la decisión es estratégica/general:

• omite fragmentos del repositorio a menos que cambien materialmente la respuesta

3. Formar primero la posición del Arquitecto

Antes de leer otras voces, escribe:

• tu posición inicial
• las tres razones más fuertes para ella
• el riesgo principal en tu camino preferido

Haz esto primero para que la síntesis no simplemente refleje las voces externas.

4. Lanzar tres voces independientes en paralelo

Cada subagente recibe:

• la pregunta de decisión
• contexto compacto si es necesario
• un rol estricto
• sin historial de conversación innecesario

Forma de la instrucción:

Eres el [ROL] en un consejo de decisión de cuatro voces.

Pregunta:
[pregunta de decisión]

Contexto:
[solo los fragmentos o restricciones relevantes]

Responde con:
1. Posición — 1-2 oraciones
2. Razonamiento — 3 viñetas concisas
3. Riesgo — mayor riesgo en tu recomendación
4. Sorpresa — algo que las otras voces podrían pasar por alto

Sé directo. Sin rodeos. Mantenlo por debajo de 300 palabras.

Énfasis del rol:

• Escéptico: desafía el encuadre, cuestiona supuestos, propón la alternativa creíble más simple
• Pragmatista: optimiza por velocidad, simplicidad y ejecución en el mundo real
• Crítico: saca a la luz el riesgo de desventajas, casos límite y razones por las que el plan podría fallar

5. Sintetizar con barreras contra sesgos

Eres tanto participante como sintetizador, así que usa estas reglas:

• no descartes una visión externa sin explicar por qué
• si una voz externa cambió tu recomendación, dilo explícitamente
• incluye siempre el disenso más fuerte, incluso si lo rechazas
• si dos voces se alinean contra tu posición inicial, trátalo como una señal real
• mantén las posiciones originales visibles antes del veredicto

6. Presentar un veredicto compacto

Usa esta forma de salida:

## Council: [título corto de la decisión]

**Arquitecto:** [posición de 1-2 oraciones]
[1 línea sobre por qué]

**Escéptico:** [posición de 1-2 oraciones]
[1 línea sobre por qué]

**Pragmatista:** [posición de 1-2 oraciones]
[1 línea sobre por qué]

**Crítico:** [posición de 1-2 oraciones]
[1 línea sobre por qué]

### Veredicto
- **Consenso:** [dónde coinciden]
- **Disenso más fuerte:** [desacuerdo más importante]
- **Verificación de premisa:** [¿el Escéptico desafió la pregunta en sí?]
- **Recomendación:** [el camino sintetizado]

Mantenlo escaneable en una pantalla de teléfono.

Regla de persistencia

No escribas notas ad hoc en ~/.claude/notes u otras rutas sombra desde esta skill.

Si el consejo cambia materialmente la recomendación:

• usa knowledge-ops para almacenar la lección en la ubicación duradera correcta
• o usa /save-session si el resultado pertenece a la memoria de sesión
• o actualiza el issue de GitHub / Linear directamente si la decisión cambia la verdad de ejecución activa

Solo persiste una decisión cuando cambia algo real.

Seguimiento de múltiples rondas

Por defecto es una ronda.

Si el usuario quiere otra ronda:

• mantén la nueva pregunta enfocada
• incluye el veredicto anterior solo si es necesario
• mantén al Escéptico lo más limpio posible para preservar el valor antianclaje

Antipatrones

• usar council para revisión de código
• usar council cuando la tarea es solo trabajo de implementación
• alimentar a los subagentes con la transcripción completa de la conversación
• ocultar el desacuerdo en el veredicto final
• persistir cada decisión como una nota independientemente de su importancia

Skills relacionadas

• santa-method — verificación adversarial
• knowledge-ops — persistir correctamente los deltas de decisión duraderos
• search-first — recopilar material de referencia externo antes del consejo si es necesario
• architecture-decision-records — formalizar el resultado cuando la decisión se convierte en política de sistema de larga duración

Ejemplo

Pregunta:

¿Deberíamos enviar ECC 2.0 como alpha ahora, o esperar hasta que la UI del plano de control esté más completa?

Forma probable del consejo:

• Arquitecto presiona por integridad estructural y evitar una superficie confusa
• Escéptico cuestiona si la UI es realmente el factor limitante
• Pragmatista pregunta qué se puede enviar ahora sin dañar la confianza
• Crítico se enfoca en la carga de soporte, deuda de expectativas y confusión del despliegue

El valor no es la unanimidad. El valor es hacer legible el desacuerdo antes de elegir.