# Kit Propuestas

> Estándar Kit Chema para redactar o evaluar propuestas y decisiones — propuestas de desarrollo, de inversión, de arquitectura, cotizaciones, o cualquier "¿hacemos X o Y?" con consecuencias reales (caro o difícil de revertir); una elección ligera o "ayúdame a elegir" sin consecuencia mayor la resuelve el núcleo con opciones, no esta skill. También todo mensaje o correo que pide aprobar, autorizar o decidir algo (aunque vaya a dirección). Úsala al escribir una propuesta, al evaluar una idea del usuario con consecuencias reales, al pedir aprobación de algo, y siempre que se pida "council". Frases gatillo "hazme la propuesta", "¿te parece bien esta idea?", "evalúa esta decisión", "que aprueben/autoricen X", "council". También el acercamiento a un contacto concreto de otra empresa ("escríbele a fulano de X"): confirma quién es antes de personalizar. Incluye el protocolo Council: panel de evaluadores independientes con veredicto aprobada / con cambios / rechazada.

- Skill: `chemaw8/kit-propuestas` (Agent Skill)
- Install (CLI): `npx skillmds@latest add chemaw8/kit-propuestas`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chemaw8/kit-propuestas/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- License: MIT
- Author: chemaw8 (https://skillmd.com/u/chemaw8)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chemaw8/kit-propuestas

---


# Propuestas y decisiones — estándar Kit Chema

Playbook para redactar una propuesta y para juzgar una decisión con
consecuencias. El corazón es el Council: un panel de evaluadores independientes
que revisa lo que importa sin inventar problemas para parecer riguroso.

## Estructura de toda propuesta

Una propuesta útil se lee en este orden y no le falta ninguna pieza:

1. Problema. Qué duele y a quién. Concreto: quién sufre el problema hoy y qué
   le cuesta. Sin esto, todo lo demás es una solución en busca de un problema.
2. Opciones. Dos o tres alternativas reales, no espantapájaros. Cada una tiene
   que ser algo que alguien defendería en serio; poner una opción de paja al
   lado de la que quieres no es comparar, es hacer trampa.
3. Costos por opción. Dinero, tiempo y riesgo de cada una. Números cuando los
   haya; si no, rangos honestos. Una opción sin sus costos no está evaluada.
4. Recomendación con razones. Cuál eliges y por qué, atada a los costos de
   arriba. La recomendación se sigue de la comparación, no la precede.
5. Cómo revertirla. Qué haría falta para dar marcha atrás si sale mal. Esto
   distingue una apuesta barata de una jugada irreversible y fija cuánto rigor
   merece la decisión.

## Cuándo corre un Council

No toda decisión necesita panel. Corre un Council cuando:

- el usuario dice "council" (lo fuerza siempre);
- la decisión es cara o difícil de revertir;
- el material sale de la empresa (cliente, proveedor, público).

Si no aplica ninguno, basta la evaluación crítica del núcleo (qué está bien,
qué me preocupa, qué haría yo). No montes un panel para elegir el nombre de una
variable.

## Protocolo Council

El panel son de 3 a 5 evaluadores independientes, cada uno con contexto fresco
—sin ver las conclusiones de los demás— y un lente asignado:

- viabilidad técnica: ¿se puede hacer de verdad, con lo que hay?
- costo/beneficio: ¿los números cierran?, ¿el retorno justifica el gasto?
- riesgos: ¿qué puede salir mal y qué tan grave sería?
- abogado del diablo: el mejor argumento en contra de la recomendación, o, si
  no hay uno sólido, decirlo.
- dominio relevante (opcional): un experto del área concreta cuando la haya
  (legal, fiscal, seguridad, el negocio del cliente).

A cada evaluador se le entrega la propuesta y el mandato acotado de la sección
siguiente. Antes de lanzar a los evaluadores, el hilo principal fija en una
frase su postura inicial sobre la propuesta, sin haber leído ningún reporte; esa
postura viaja a quien sintetice, y el veredicto dice explícitamente si los
evaluadores le hicieron cambiar de opinión y en qué (que lo diga confirma que el
council aportó y no fue teatral). Quién sintetiza y la mecánica cambian según
dónde corras:

- En Claude Code: lanza los evaluadores como subagentes en paralelo, con modelo
  Opus 5 cada uno. La síntesis en un solo veredicto la hace el agente
  `sintetizador` (Fable 5.1), que verifica cada hallazgo antes de heredarlo; pásale
  tu postura inicial, porque el veredicto debe decir si los evaluadores te hicieron
  cambiar de opinión. Si el agente no está disponible, sintetiza el hilo principal.
- En claude.ai (web): no hay subagentes, así que evalúa secuencialmente en la
  misma conversación, tomando un lente a la vez y marcando cada sección con su
  nombre ("Viabilidad técnica:", "Riesgos:", ...). Trata cada lente como una
  pasada independiente: no dejes que la anterior contamine la siguiente. Al
  final, sintetiza el veredicto.

## Mandato acotado del evaluador

Este texto se pasa literal a cada evaluador, sin cambiarlo:

"Reporta solo hallazgos que cambien la corrección o la decisión, cada uno con
evidencia concreta. Pondera cada hallazgo contra el tamaño, costo y
reversibilidad de la propuesta: una mejora deseable no es una condición, y
exigir controles de nivel corporativo a una solución pequeña es
sobre-ingeniería, no rigor. 'Sin hallazgos relevantes' es una respuesta válida
y esperada. No rellenes por cumplir."

La razón es concreta: a un revisor al que se le pide "encuentra fallos" los
inventa para justificar su presencia. "Sin hallazgos relevantes" es un
resultado plenamente válido y esperado, no un fracaso del evaluador. A cada
evaluador se le entrega solo la propuesta y su mandato, nunca el hilo completo
de la conversación: pasar el historial contamina el juicio independiente y anula
el anti-anclaje. Un panel que siempre encuentra algo no es riguroso, es
teatral. La proporcionalidad es la misma disciplina aplicada a la escala: un
hallazgo real sobre una propuesta pequeña no justifica exigirle el estándar de
una infraestructura crítica.

## Veredicto

Antes de opinar, consulta el `DECISIONES.md` del proyecto: si algo ya se
decidió y anotó ahí con sus razones, no lo reabras salvo que haya evidencia
nueva. Reabrir lo cerrado hace perder tiempo a todos.

El Council cierra con uno de tres veredictos exactos:

- `aprobada`: la propuesta procede tal cual.
- `aprobada con cambios`: procede, pero con una lista concreta de ajustes
  —cada uno accionable, no un "podría mejorarse".
- `rechazada`: no procede, con las razones que lo sustentan.

Si el panel no puede decidir, no inventes un veredicto: di qué evidencia
concreta falta para poder decidir.

Al sintetizar, verifica los hallazgos antes de heredarlos al veredicto: un
hallazgo que no resista una verificación rápida (dato erróneo, fuera de alcance,
ya resuelto) se descarta explicando por qué. Que venga de un evaluador no lo
hace verdad por sí solo.

## Acercamiento personalizado a un contacto

Aplica cuando el usuario quiere llegar a una persona concreta de otra empresa
—vender, proponer, presentar— personalizando el mensaje o el material. El orden
importa:

1. Confirma quién es el contacto antes de personalizar nada. Busca en fuentes
   públicas con nombre, empresa y puesto; si hay más de una persona plausible,
   presenta las opciones y que el usuario confirme; si no aparece o no hay cómo
   buscar, dilo y pide los datos. Sin identidad confirmada, escribe sin
   personalizar: personalizar sobre la persona equivocada es peor que no hacerlo.
2. Redacta el entregable con su estándar de siempre (un mensaje, con kit-redaccion;
   una propuesta, con esta skill; láminas, con kit-presentaciones) y añade encima
   la capa de personalización: solo información profesional y pública,
   verificable, ligada al problema u opción del entregable; nada de halagos que
   servirían para cualquiera. Esta sección aporta la identidad y la capa, no
   sustituye al kit del formato.
3. Antes de enviar o publicar a nombre del usuario, confirma con él el texto
   final. Un mensaje de acercamiento no dispara Council por sí solo: basta esa
   confirmación; una propuesta formal o material que se presenta sigue los
   disparadores de arriba.

## Errores típicos

- Council teatral: inventar fallos para parecer riguroso. Si no hay hallazgos,
  el veredicto es "sin hallazgos relevantes" y ya.
- Opciones de paja: rodear la opción favorita de alternativas que nadie
  defendería, para simular que hubo comparación.
- Recomendar sin costos: dar la conclusión sin poner dinero, tiempo y riesgo
  de cada opción encima de la mesa.
- Reabrir decisiones cerradas: discutir de nuevo lo que ya está en
  `DECISIONES.md` sin evidencia nueva que lo justifique.
- Añadir rondas de deliberación entre los evaluadores. El panel vale por la
  independencia: si se leen entre sí se contagian, el costo se multiplica y el
  acierto no mejora. Cada uno opina por separado y la síntesis agrega al final.
- Acercamiento a ciegas: personalizar sin haber confirmado la identidad del
  contacto, o rellenar con datos no verificados y halagos genéricos.

