decision-logger
por alirezarezvanidecision-logger es una skill de Decision Support para decisiones de junta aprobadas. Separa las transcripciones en bruto de un índice de decisiones Layer 2, hace seguimiento de responsables, plazos, opciones rechazadas y seguimientos, e incluye un tracker en Python para resúmenes, elementos vencidos, conflictos, filtros por responsable y búsqueda.
Esta skill obtiene 80/100, por lo que es una candidata sólida para usuarios del directorio que necesitan memoria estructurada de decisiones de junta y revisión de acciones pendientes. Ofrece más capacidad de apoyo al agente que un prompt genérico gracias a activadores definidos, un formato persistente para decisiones aprobadas y un script de informes, aunque su adopción resulta más sencilla dentro del flujo de trabajo más amplio de C-Level Advisor.
- La descripción define con claridad cuándo usarla: después de reuniones de junta, al revisar decisiones aprobadas o al comprobar acciones pendientes vencidas.
- Tiene contenido operativo sólido: SKILL.md define un modelo de memoria de decisiones en dos capas, con datos brutos y decisiones aprobadas, además de comandos, palabras clave y casos de uso.
- Incluye soporte ejecutable mediante scripts/decision_tracker.py, junto con una plantilla de entrada de decisiones y reglas de campos para mantener entradas coherentes en Layer 2.
- No se incluye ningún comando de instalación ni README en la ruta de la skill, por lo que los usuarios deben deducir la instalación a partir de la estructura general del repositorio.
- El flujo de trabajo parece diseñado para el ecosistema de C-Level Advisor y reuniones de junta, así como para comandos slash como /cs:decisions y /cs:review, lo que puede limitar su utilidad como herramienta independiente.
Descripción general de decision-logger skill
Qué hace decision-logger
decision-logger es una skill de Decision Support pensada para convertir los resultados de reuniones de directorio en una memoria de decisiones duradera de dos capas. La Capa 1 conserva el contexto bruto de la reunión; la Capa 2 almacena únicamente decisiones aprobadas, responsables, fechas límite, opciones rechazadas y elementos de seguimiento. El objetivo es práctico: las futuras reuniones asistidas por IA deben apoyarse en decisiones confirmadas, no en debates sin resolver ni en consensos alucinados.
Mejor encaje para flujos de directorio y alta dirección
La decision-logger skill encaja mejor con fundadores, chiefs of staff, operadores de directorio y agentes de IA que dan soporte a reuniones ejecutivas recurrentes. Funciona bien en flujos donde las decisiones deben mantenerse entre reuniones, poder buscarse más adelante y permanecer separadas de las notas de discusión. Es especialmente útil cuando un proceso de estilo board-meeting termina con la aprobación del fundador y luego necesita un registro limpio y auditable.
Diferenciador clave: solo memoria aprobada
La decisión de diseño más fuerte es la separación entre las transcripciones brutas y el índice aprobado de Capa 2. Las revisiones futuras leen la capa aprobada, no todos los argumentos de la reunión. Esto ayuda a evitar que ideas antiguas ya rechazadas vuelvan a aparecer como si aún fueran viables. La plantilla también incluye DO_NOT_RESURFACE, campos de sustitución, fechas de revisión y seguimiento de responsables, lo que la hace más operativa que un prompt genérico para “resumir notas de reunión”.
Qué revisar antes de instalar
Antes de adoptar decision-logger, confirma que tu equipo se siente cómodo manteniendo un índice local de decisiones en ~/.claude/decisions/approved/decisions.md. El helper en Python incluido lee ese archivo y puede informar elementos vencidos, conflictos, acciones por responsable y búsquedas por palabra clave. Si tu proceso no distingue entre decisiones aprobadas y notas de discusión, quizá debas ajustar primero tu flujo de reuniones.
Cómo usar decision-logger skill
Instalación de decision-logger y archivos que conviene revisar primero
Instala la skill desde la ruta del repositorio:
npx skills add alirezarezvani/claude-skills --skill decision-logger
Después de instalarla, lee estos archivos en este orden:
SKILL.md— explica el modelo de memoria de dos capas, la intención del slash-command y las ubicaciones de almacenamiento esperadas.templates/decision-entry.md— muestra el formato exacto de una entrada de Capa 2.scripts/decision_tracker.py— proporciona comandos de reporte para resumen, elementos vencidos, conflictos, filtros por responsable y búsqueda.
El script usa solo la biblioteca estándar de Python, así que no requiere configurar dependencias aparte de tener Python disponible.
Entradas que la skill necesita para funcionar bien
Para sacar buen partido de decision-logger, dale al agente algo más que un resumen superficial de la reunión. Proporciona el punto de agenda, la decisión final aprobada, el responsable asignado, la fecha límite, la fecha de revisión, la justificación, las alternativas rechazadas y cualquier override del fundador. La plantilla espera una decisión por entrada, así que divide los resultados agrupados en registros separados.
Entrada débil: “Registra que hablamos de precios y decidimos probar algo.”
Entrada mejor: “Registra la decisión aprobada de la reunión de directorio del 2026-03-05: pasar de precios planos a un piloto de tres niveles para nuevos clientes. Responsable: CRO. Fecha límite: 2026-04-15. Revisión: 2026-05-01. Justificación: mejora la ruta de expansión y limita el riesgo de migración. Rechazado: migración inmediata de todos los clientes existentes porque la carga de soporte es demasiado alta. Ruta de la transcripción bruta: ~/.claude/decisions/raw/2026-03-05-pricing.md.”
Flujo práctico después de una reunión
Usa decision-logger después de la aprobación, no durante un debate abierto. Un flujo fiable es:
- Guarda o referencia la transcripción bruta en la Capa 1.
- Pide al agente que extraiga únicamente los resultados aprobados por el fundador.
- Crea una entrada de Capa 2 usando
templates/decision-entry.md. - Marca las opciones rechazadas con sus razones y
DO_NOT_RESURFACE. - Ejecuta el script de seguimiento para revisar resúmenes, acciones vencidas o conflictos.
Comandos útiles del repositorio:
python scripts/decision_tracker.py --demopython scripts/decision_tracker.py --summarypython scripts/decision_tracker.py --overduepython scripts/decision_tracker.py --conflictspython scripts/decision_tracker.py --owner "CTO"python scripts/decision_tracker.py --search "pricing"python scripts/decision_tracker.py --due-within 7
Patrón de prompt para mejores entradas
Una buena invocación debe pedir una entrada de decisión, no un resumen narrativo. Por ejemplo:
“Usa la decision-logger skill para crear una entrada de decisión aprobada de Capa 2. Incluye una declaración clara de la decisión, un responsable único, fecha límite, fecha de revisión, justificación, propuestas rechazadas con DO_NOT_RESURFACE, elementos de acción, campos de supersedes si aplica y la ruta de la transcripción bruta. No incluyas puntos de discusión no aprobados.”
Este encuadre reduce la ambigüedad y mantiene la Capa 2 lo bastante limpia para Decision Support posterior.
Preguntas frecuentes sobre decision-logger skill
¿decision-logger es solo para reuniones de directorio?
Está diseñada alrededor de la memoria de decisiones de directorio y C-level, pero también puede funcionar para comités de inversión, reuniones de liderazgo, consejos de producto o revisiones de gobernanza. El requisito clave es que las decisiones estén formalmente aprobadas y necesiten seguimiento. Es menos útil para sesiones de brainstorming en las que no se toma una decisión final.
¿En qué supera a pedirle a la IA que resuma actas?
Un resumen normal suele mezclar discusión, recomendaciones, objeciones y decisiones. decision-logger impone estructura: decisión aprobada, responsable, fecha límite, justificación, opciones rechazadas, elementos de acción, sustitución y enlace a la transcripción bruta. Esa estructura es lo que permite revisión posterior, comprobaciones de vencimientos y detección de conflictos.
¿La decision-logger skill requiere una base de datos?
No. La evidencia del repositorio apunta a almacenamiento basado en markdown y a un script de Python con biblioteca estándar. El índice principal de Capa 2 se espera en ~/.claude/decisions/approved/decisions.md, con soporte heredado para otra ruta de archivo mediante --file. Esto la hace ligera, pero los equipos que necesiten permisos multiusuario, dashboards o logs de auditoría pueden requerir herramientas adicionales.
¿Cuándo no debería usar decision-logger?
No la uses como depósito para todas las notas de reunión. También encaja mal si las decisiones cambian constantemente sin responsables ni fechas, o si tu organización no puede identificar qué fue realmente aprobado. En esos casos, una skill de notas de reunión o una integración con gestión de proyectos puede ser más adecuada antes de añadir memoria de decisiones.
Cómo mejorar decision-logger skill
Mejora los resultados de decision-logger con aprobaciones más claras
El factor de calidad más importante es la claridad de la aprobación. Antes de registrar, verifica: ¿qué se decidió exactamente? ¿Quién es responsable? ¿Para cuándo? ¿Qué se rechazó explícitamente? ¿Qué deberían evitar volver a proponer los futuros agentes? Si falta cualquiera de esos datos, haz una pregunta de seguimiento en lugar de crear una entrada vaga.
Modos de fallo comunes que conviene prevenir
Vigila las entradas que contienen varias decisiones en un solo párrafo, propiedad compartida sin una persona responsable, fechas límite como “pronto”, justificaciones que solo repiten la decisión o ideas rechazadas sin motivos. Todo eso debilita la búsqueda y la revisión posteriores. Conviene tratar las reglas de campos de la plantilla como restricciones, no como sugerencias.
Itera después de la primera entrada generada
Después de que el agente redacte una entrada, revísala como si fuera un registro operativo. Ajusta la decisión a una sola frase, convierte nombres o roles en un único responsable, sustituye fechas relativas por YYYY-MM-DD y asegúrate de que los elementos de acción se puedan verificar. Luego ejecuta --summary, --overdue o --conflicts para comprobar que la entrada se comporta bien en el tracker.
Extiende la skill para tu modelo operativo
Los equipos pueden mejorar decision-logger añadiendo etiquetas de agenda consistentes, nombres de comités de directorio, nivel de riesgo, tipo de decisión o enlaces a tickets de proyecto. Mantén las extensiones compatibles con el índice markdown y evita agregar campos que nadie vaya a mantener. El objetivo no es documentar más por documentar; es lograr un Decision Support más limpio para la próxima reunión.