Skill oficial · Operaciones y administración
Registro de decisiones (decision log)
Registra una decisión como una entrada breve: la decisión, el contexto, las opciones consideradas, el porqué, quién decidió, la fecha, el estado y un disparador de revisión.
Funciona en Claude, ChatGPT y agentes de programación. En Team y Business, la skill oficial de tu pod se actualiza sola cuando la mejoramos.
Cuándo usarla
- Un equipo acaba de decidir algo costoso de revertir o que probablemente se cuestionará
- La gente pregunta una y otra vez por qué se eligió algo y la respuesta no está por escrito
Qué le das
- Qué se decidió y quién lo decidió
- Fecha
- Opciones de las que se habló y por qué perdieron
- Hilo, acta o documento (opcional)
Qué obtienes
Una entrada numerada del registro de decisiones en Markdown con estado, quién decidió, contexto, opciones, motivos, consecuencias y un disparador de revisión.
Cómo funciona
- Escribe la decisión en una frase, en voz activa Nygard redacta la sección de la decisión “en frases completas, en voz activa”, que suelen empezar con “Vamos a” (“We will”). Ejemplo: “Vamos a usar Dealbook como CRM a partir del 1 de marzo”.
- Escribe el contexto en 2 a 4 frases Los hechos y las presiones que obligaron a elegir: un plazo, un costo, un cliente, una restricción. Nygard dice que esta sección “es neutral en cuanto a valores. Simplemente describe hechos”. Las opiniones van en los motivos.
- Enumera las opciones consideradas Una línea por opción con su principal ventaja o desventaja. La práctica DACI de Atlassian mantiene una tabla de opciones con pros, contras y costo. Incluye “no hacer nada” si fue una opción real. Enumera solo las opciones de las que se habló de verdad.
- Da los motivos De 2 a 4 viñetas que remitan al contexto: por qué esta opción ganó a las demás. Después, enumera las consecuencias, buenas y malas. Nygard: “Aquí deben enumerarse todas las consecuencias, no solo las «positivas»”.
- Nombra a quien decidió y a quienes se consultó Una sola persona que decide (la práctica DACI de Atlassian la llama Approver, “la única persona (sí, ¡una!) que toma la decisión”) y las personas consultadas. El marco de ADR del Gobierno del Reino Unido también registra a las partes interesadas consultadas.
- Define un disparador de revisión Una condición concreta que la reabriría: una fecha, una cifra o un hecho (“si pasamos de 20 vendedores”, “si el precio supera nuestro presupuesto”, “revisar el 1 de marzo del año que viene”). Por defecto (criterio de esta skill): todo registro tiene uno; “nunca” solo se admite cuando la decisión es de verdad permanente, y entonces se explica por qué.
- Define el estado y el número Propuesta, aceptada o sustituida. Numera las entradas en orden y nunca reutilices un número, como hace el formato de Nygard. Si esta decisión reemplaza a una anterior, marca la antigua “Sustituida por #[n]” y consérvala; Nygard mantiene las decisiones revertidas “a la vista, pero marcadas como sustituidas”.
El SKILL.md
El archivo completo, tal como lo lee tu IA. Descargarlo
---
name: decision-record
description: Registra una decisión ya tomada como una entrada breve del registro de decisiones - la decisión en una frase, el contexto, las opciones consideradas, por qué esta, quién decidió, la fecha, el estado y qué haría que el equipo la revisara. Se basa en la práctica de los registros de decisiones de arquitectura (ADR, architecture decision record) y de los decision logs, adaptada a cualquier decisión de negocio. Úsala cuando un equipo acaba de decidir algo, alguien pide registrar o documentar una decisión, o la gente pregunta una y otra vez “¿por qué hicimos esto?”.
---
# Registro de decisiones
Un registro de decisión permite que alguien, dentro de seis meses, entienda qué se decidió, por qué y cuándo reabrirlo, sin preguntar a quienes estuvieron. Registra una decisión ya tomada; no defiende ninguna. Mantenlo corto: el artículo de Michael Nygard de 2011 que presentó el formato ADR (architecture decision record) dice que el documento completo debe ocupar 1 o 2 páginas, y el valor predeterminado de esta skill es media página.
## Cuándo usarla
- Un equipo acaba de decidir algo costoso de revertir o que la gente cuestionará más adelante: una herramienta, un proveedor, un precio, una política, un plan de contratación, un proceso.
- Alguien dice “dejémoslo por escrito” o pide una entrada para el registro de decisiones.
- En un hilo se pregunta una y otra vez “¿por qué elegimos X?” y la respuesta solo está en la cabeza de alguien.
- No sirve para tomar la decisión. Para exponer opciones y conseguir que se apruebe una recomendación, usa primero un memorando de decisión y luego registra aquí el resultado.
## Qué necesitas
- Qué se decidió y quién lo decidió. Si no está claro quién decidió, pregunta una vez; nunca lo adivines. Si sigue sin saberse, escribe “[quién decide sin confirmar]”.
- La fecha de la decisión. Si falta, usa la fecha del mensaje de origen y márcala “[según la fecha del mensaje]”.
- Las opciones que estaban sobre la mesa y por qué perdieron las demás. Si solo se habló de una opción, dilo; no inventes alternativas.
- Opcional: el hilo, el acta o el documento donde se habló, y el número de la última entrada del registro.
## Pasos
1. **Escribe la decisión en una frase, en voz activa.** Nygard redacta la sección de la decisión “en frases completas, en voz activa”, que suelen empezar con “Vamos a” (“We will”). Ejemplo: “Vamos a usar Dealbook como CRM a partir del 1 de marzo”.
2. **Escribe el contexto en 2 a 4 frases.** Los hechos y las presiones que obligaron a elegir: un plazo, un costo, un cliente, una restricción. Nygard dice que esta sección “es neutral en cuanto a valores. Simplemente describe hechos”. Las opiniones van en los motivos.
3. **Enumera las opciones consideradas.** Una línea por opción con su principal ventaja o desventaja. La práctica DACI de Atlassian mantiene una tabla de opciones con pros, contras y costo. Incluye “no hacer nada” si fue una opción real. Enumera solo las opciones de las que se habló de verdad.
4. **Da los motivos.** De 2 a 4 viñetas que remitan al contexto: por qué esta opción ganó a las demás. Después, enumera las consecuencias, buenas y malas. Nygard: “Aquí deben enumerarse todas las consecuencias, no solo las «positivas»”.
5. **Nombra a quien decidió y a quienes se consultó.** Una sola persona que decide (la práctica DACI de Atlassian la llama Approver, “la única persona (sí, ¡una!) que toma la decisión”) y las personas consultadas. El marco de ADR del Gobierno del Reino Unido también registra a las partes interesadas consultadas.
6. **Define un disparador de revisión.** Una condición concreta que la reabriría: una fecha, una cifra o un hecho (“si pasamos de 20 vendedores”, “si el precio supera nuestro presupuesto”, “revisar el 1 de marzo del año que viene”). Por defecto (criterio de esta skill): todo registro tiene uno; “nunca” solo se admite cuando la decisión es de verdad permanente, y entonces se explica por qué.
7. **Define el estado y el número.** Propuesta, aceptada o sustituida. Numera las entradas en orden y nunca reutilices un número, como hace el formato de Nygard. Si esta decisión reemplaza a una anterior, marca la antigua “Sustituida por #[n]” y consérvala; Nygard mantiene las decisiones revertidas “a la vista, pero marcadas como sustituidas”.
## Formato de salida
```markdown
## #[número] — [título breve, con un sustantivo]
**Estado:** [propuesta / aceptada / sustituida por #n] · **Fecha:** [fecha] · **Decidió:** [un nombre]
**Consultados:** [nombres] · **Fuente:** [enlace al hilo, el acta o el documento]
**Decisión:** Vamos a [una frase].
**Contexto:** [2–4 frases de hechos.]
**Opciones consideradas:**
- **[Opción A, elegida]:** [principal ventaja o desventaja]
- **[Opción B]:** [principal ventaja o desventaja]
- **[No hacer nada]:** [principal ventaja o desventaja, si se consideró]
**Por qué:**
- [motivo ligado al contexto]
**Consecuencias:**
- [efectos buenos y malos, qué cambia y para quién]
**Revisar si:** [fecha, cifra o hecho concreto]
```
## Ejemplo
**Entrada:** Resumen de un hilo de Slack: “Bueno, decisión final de Rosa (COO) el 3 de febrero: vamos con Dealbook, no con FunnelHQ. Nadia y Félix participaron. El plan de ventas de FunnelHQ costaba unas 3 veces más para nuestros 6 vendedores, y todavía no usamos automatización de marketing. Dealbook tiene la sincronización de correo que necesitamos. La desventaja es que tendremos que migrar otra vez si marketing quiere FunnelHQ más adelante. La hoja de cálculo ya no da más, el mes pasado se nos perdieron 2 seguimientos. La última entrada del registro fue la #11.”
**Salida:**
```markdown
## #12 — CRM para el equipo de ventas
**Estado:** aceptada · **Fecha:** 3 de febrero · **Decidió:** Rosa (COO)
**Consultados:** Nadia, Félix · **Fuente:** hilo de Slack, 3 de febrero
**Decisión:** Vamos a pasar al equipo de ventas de la hoja de cálculo compartida a Dealbook.
**Contexto:** El equipo de 6 vendedores sigue sus oportunidades en una hoja de cálculo que ya no da más. El mes pasado se perdieron 2 seguimientos. Necesitamos que el CRM sincronice el correo. Hoy no usamos automatización de marketing.
**Opciones consideradas:**
- **Dealbook, elegida:** tiene la sincronización de correo que necesitamos; sin automatización de marketing.
- **Plan de ventas de FunnelHQ:** incluye automatización de marketing, cuesta unas 3 veces lo que Dealbook para 6 vendedores.
**Por qué:**
- Reemplaza la hoja de cálculo que ya no da más y tiene la sincronización de correo que necesitamos.
- El plan de ventas de FunnelHQ cuesta unas 3 veces más para 6 vendedores, y todavía no usamos automatización de marketing.
**Consecuencias:**
- Los vendedores pasan sus oportunidades abiertas a Dealbook y dejan de usar la hoja de cálculo.
- Si marketing necesita FunnelHQ más adelante, migraremos los datos del CRM por segunda vez.
**Revisar si:** marketing quiere FunnelHQ o empieza a usar automatización de marketing.
```
## Comprobaciones antes de enviar
- [ ] La decisión es una frase en voz activa con la que alguien podría actuar.
- [ ] Se nombra exactamente a una persona que decide, o “[quién decide sin confirmar]”.
- [ ] Cada opción enumerada se habló de verdad; no se agregó nada para parecer exhaustivo.
- [ ] Las consecuencias incluyen al menos un costo o una desventaja.
- [ ] El disparador de revisión es una fecha, una cifra o un hecho concreto.
- [ ] Los hechos, nombres, cifras y fechas salen todos de la fuente.
## Errores comunes
- Registrar una conversación como si fuera una decisión. Si nadie con autoridad dijo que sí, el estado es “propuesta”.
- Editar una entrada antigua cuando la decisión cambia. Escribe una entrada nueva y marca la antigua como sustituida; el historial es lo que importa.
- Un contexto que argumenta. Deja la defensa de la elección para “Por qué”.
Compártela con tu equipo
Agrégala a un AI Skill Pod y todo el equipo, colaboradores externos incluidos, usa la misma versión desde su propia IA. Lee las mejores formas de compartir skills de IA con un equipo
Historial de cambios
- v1.0.0 · · First release.
Fuentes
- Documenting architecture decisions (Michael Nygard, Cognitect) (leída el 2026-11-04)
- Architectural Decision Records (ADRs) (leída el 2026-11-04)
- Architectural Decision Record Framework (GOV.UK) (leída el 2026-11-04)
- DACI: a decision-making framework (Atlassian Team Playbook) (leída el 2026-11-04)