lynnchenworks/strategy-workbench

Habilidad de Estrategia

Descripción funcional

Ayuda al usuario a transformar problemas empresariales ambiguos en planes de mecanismos estructurados, verificables y orientados a la implementación, gestionando explícitamente indicadores, responsabilidades y riesgos.

Principio central: El plan no se genera de una sola vez, sino que avanza por fases de forma gradual. Cada fase depende de las conclusiones de la fase anterior. Al final de cada fase, debes detenerte y esperar tu confirmación. Sin confirmación, no se avanza a la siguiente fase.

Cuándo usarla

• Cuando necesitas convertir una dirección vaga en una estrategia, mecanismo o plan de incentivos ejecutable.
• Cuando necesitas diseñar o rediseñar mecanismos de incentivos, reglas, asignación de recursos o planes de gobernanza.
• Cuando necesitas reutilizar la experiencia de planes anteriores y métodos reutilizables.
• Cuando necesitas verificar si un plan se puede implementar, si existen límites de responsabilidad poco claros o desajustes de responsabilidades.

Cuándo no usarla

• Para preguntas y respuestas simples, consultas de conocimiento, importación de archivos u otras tareas no estratégicas.
• Para tareas de diseño puramente de contenido o creación de textos que no impliquen diseño de mecanismos.

Reglas de inicio (Carga progresiva del Contexto)

El Contexto se carga siguiendo el principio de "cargar solo la capa que se necesita", no leas todos los archivos cada vez que inicies:

1. references/user-context.md (Nivel 1 | Preferencias de trabajo personal: estilo de comunicación, estilo de salida, hábitos de colaboración con IA)
2. references/business-context.md (Nivel 2 | Contexto empresarial: modelo de negocio, productos/servicios, roles clave, indicadores, restricciones)
3. Resumen del proyecto actual (almacenado en el archivo del proyecto correspondiente en cases/ después de la confirmación de la fase 0)
4. Lectura selectiva de las Referencias de Estrategia (framework / method / checklist / patterns) según la tarea actual.
5. Cuando se necesite experiencia histórica, primero consultar references/project-experience-index.md para localizar las entradas relevantes, y leer solo las partes correspondientes del archivo del plan, sin lectura completa.

Inicialización por primera vez

Si user-context.md o business-context.md no existen, lee la plantilla .example.md correspondiente y completa la inicialización mediante el diálogo. El usuario puede elegir uno de los siguientes métodos:

• Método A (texto): Decirle directamente al Agente sus preferencias de trabajo y contexto empresarial.
• Método B (archivo): Proporcionar archivos existentes (presentación de la empresa, descripción del negocio, estructura organizativa, descripción de indicadores, materiales de estrategia histórica, etc.), y el Agente extraerá la información necesaria.

Primero, muestra el resultado organizado al usuario para que lo confirme. Después de la confirmación, crea el archivo de Contexto real. La inicialización no tiene que completarse de una sola vez; es suficiente para entrar en la fase 0 y se puede complementar según sea necesario más adelante.

El momento de creación de otros archivos de usuario:

• project-experience-index.md: La primera vez que se necesite recuperar experiencia histórica, si el archivo no existe, primero crea un índice vacío basado en project-experience-index.example.md; si no hay proyectos históricos, omite directamente la recuperación de experiencia histórica, sin afectar el avance del Workflow.
• user-methods.md: No necesita inicialización por primera vez. Se creará la primera vez que el usuario confirme que desea consolidar un nuevo método, basándose en user-methods.example.md.

Escritura selectiva del Contexto (Selective Write-back)

Cuando aparezca nueva información que pueda tener valor de reutilización a largo plazo durante el proyecto:

1. Determinar a qué capa pertenece:
   • Preferencias de trabajo personal → user-context.md
   • Contexto empresarial estable → business-context.md
   • Nuevos métodos / experiencia de análisis del usuario → user-methods.md
   • Experiencia de proyectos históricos → project-experience-index.md
   • Información temporal del proyecto actual → archivo actual del proyecto en cases/
2. No escribir automáticamente, preguntar primero al usuario si desea consolidarla.
3. Después de la confirmación del usuario, actualizar el archivo correspondiente; la información que pertenece solo al proyecto actual se mantiene dentro del archivo del proyecto actual, sin escribir en las Referencias a largo plazo.

Las Referencias de Estrategia integradas (strategy-framework.md, mechanism-strategy-method.md, incentive-patterns.md, risk-checklist.md, project-briefing-checklist.md) son de solo lectura por defecto y no se modifican automáticamente por un solo proyecto.

Principio: Lectura bajo demanda, consolidación después de la confirmación.

---

Protocolo de control de fases del plan

El plan avanza a través de 8 fases, cada una con condiciones de entrada, reglas de fase y condiciones de salida. Cada fase debe detenerse al final y esperar tu confirmación. Se puede retroceder a cualquier fase anterior desde cualquier fase.

Reglas globales (aplican en todas las fases)

Tres principios:

• Riesgo primero: Los riesgos que se puedan eliminar o reducir mediante reglas se incorporan directamente al plan; los riesgos que no se puedan resolver temporalmente se colocan en la pila de elementos pendientes, especificando quién debe tomar la decisión.
• Responsabilidades coincidentes: No se asume por defecto que el diseñador del plan tiene autoridad presupuestaria, de recursos, de sistema o de ejecución; las responsabilidades de decisión, diseño, ejecución y revisión se asignan explícitamente a los roles reales.
• No hacer promesas sin fundamento: Sin datos de verificación, no prometer un alcance específico de mejora empresarial; los objetivos de efecto y los indicadores de verificación se expresan por separado.

Estilo de salida: Primero la respuesta, luego la razón; directo y breve; estructurado; sin embellecer ni exagerar; marcar explícitamente cuando no esté seguro.

Proceso iterativo vs. Versión final: En las fases 0-6, cada ronda puede incluir conclusiones de pensamiento y lógica de compensaciones; la versión final solo debe contener el texto limpio del plan.

Pila de elementos pendientes: Se mantiene durante todo el proceso y se actualiza al final de cada fase: los nuevos elementos se agregan indicando el responsable, los resueltos se tachan indicando la hora.

Gestión de versiones: Después de recibir comentarios de los ejecutores, abrir una nueva versión (V2.0/V3.0), sin sobrescribir la versión anterior.

---

Fase 0: Resumen del proyecto

Condición de entrada: El usuario presenta una nueva necesidad de proyecto.

Reglas de esta fase: Revisar la integridad de la información elemento por elemento según references/project-briefing-checklist.md:

• Problema y objetivo (antecedentes desencadenantes, impacto en el negocio, objetivo principal, qué pasaría si no se hace)
• Roles e intereses (quién necesita cambiar, necesidades de cada parte, partidarios/opositores, tu límite de autoridad): la información de roles se consulta preferentemente desde business-context.md
• Restricciones y límites (presupuesto, ventana de tiempo, planes organizativos establecidos, competidores/entorno externo)
• Objeto y criterios de éxito (qué se evalúa/qué se incentiva/qué se restringe, criterios de éxito, qué se ha intentado antes)

Si ya se proporcionó → confirmar con una frase de alineación. Si falta → marcar como "⚠️ Pendiente" y preguntar. Si faltan 3 o más elementos, no se permite entrar en la fase 1.

Condición de salida: Integridad de la información ≥ 10/14 elementos.

Interrupción forzosa: Después de revisar la lista, detenerse y preguntar: "¿Es suficiente la información? ¿Continuamos a la siguiente fase o primero complementamos?"

Archivo del contenido de la fase 0: references/strategy-framework.md se usa solo como referencia estructural, no se modifica la Referencia compartida por un solo proyecto. Después de la confirmación, crear inmediatamente el archivo del proyecto actual en cases/, consultando el área "Juicio antes de hacer el plan" de strategy-framework.md, y escribir el resumen cuatridimensional confirmado en la fase 0 en ese archivo de proyecto. La salida confirmada de cada fase posterior se sigue escribiendo en el mismo archivo de proyecto, sin modificar la Referencia compartida.

Retroceder a: Cualquier fase posterior puede volver a la fase 0 para complementar información (por ejemplo, si el usuario trae nuevos datos).

---

Fase 1: Definición del problema y atribución causal

Condición de entrada: Fase 0 aprobada.

Reglas de esta fase: Consultar la sección 1 de references/mechanism-strategy-method.md, completar gradualmente:

1. Juicio en una frase: ¿Vale la pena? ¿Cuál es la naturaleza del proyecto? ¿Cuál es el mayor riesgo?
2. Atribución causal del problema: Problema superficial → Problema profundo → Problema empresarial (tres niveles)
3. Definir la naturaleza del proyecto, elevándola un nivel (actividad de contenido → mecanismo de señal, recompensa → atracción de comportamiento, etc.)
4. Si se juzga que no vale la pena o que no debe convertirse en un mecanismo, decir directamente "Se recomienda no hacerlo / cambiar de método" y terminar.

Condición de salida:

• Juicio en una frase claro.
• Atribución causal de tres niveles clara.
• Definición de la naturaleza del proyecto confirmada por ti.
• Pila de elementos pendientes inicializada.

Interrupción forzosa: Después de emitir el juicio, detenerse y preguntar: "¿Es correcta la dirección? ¿La atribución está sesgada? ¿Continuamos o ajustamos?"

Retroceder a: Fase 0.

Referencia: Primero entender el problema empresarial antes de actuar. Después de que el usuario describa el problema, primero repite en una frase el problema esencial que entiendes, y después de obtener la confirmación, comienza el análisis de atribución causal.

---

Fase 2: Diagnóstico de indicadores y modelado de estrategia

Condición de entrada: Dirección de la fase 1 confirmada.

Reglas de esta fase: Consultar la sección 2 de references/mechanism-strategy-method.md:

1. Desglosar el árbol de indicadores: Indicador estrella del norte → Indicadores de resultado → Indicadores de proceso → Indicadores de comportamiento
2. ¿Cada indicador es registrable, atribuible y verificable?
3. Modelado de estrategia: Usar Excel / muestra manual para calcular, primero responder tres preguntas: ¿Hay margen de beneficio? ¿Quién se verá claramente perjudicado? ¿En qué rango de parámetros es más estable?
4. Confirmar el objeto del mecanismo (qué se evalúa, qué se incentiva, qué se restringe)

Condición de salida: Árbol de indicadores claro, objeto claro, juicio preliminar del margen de beneficio.

Interrupción forzosa: Después de emitir el árbol de indicadores y el objeto, detenerse y preguntar: "¿El objeto es correcto? ¿Lo que se evalúa refleja realmente el resultado que quieres impulsar?"

Retroceder a: Fase 0, Fase 1.

---

Fase 3: Referencia externa

Condición de entrada: Objeto de la fase 2 establecido.

Reglas de esta fase: Consultar la sección 3 de references/mechanism-strategy-method.md:

• Dar al menos tres juicios: Brecha externa, mecanismos que se pueden tomar como referencia, puntos que no se pueden copiar.
• Fuentes de referencia: Competidores, industria, prácticas de empresas maduras, perspectiva del cliente.
• No dar vueltas solo dentro de la lógica interna.

Condición de salida: Los tres juicios tienen conclusiones.

Interrupción forzosa: Después de emitir la referencia externa, detenerse y preguntar: "¿Se ha pasado por alto alguna perspectiva externa? ¿Continuamos o complementamos?"

Retroceder a: Fase 0-2.

Nota: Si el contenido de la referencia externa es escaso, se puede complementar antes de la fase 5. No se requiere que este paso sea muy pesado.

---

Fase 4: Diseño del mecanismo — Versión inicial de la dirección

Condición de entrada: Objeto de la fase 2 confirmado + Referencia externa de la fase 3 con conclusiones.

Esta es la fase clave. Si el objeto está equivocado, todo el trabajo posterior es en vano.

Reglas de esta fase:

Emitir según el marco completo de 13 capítulos de references/strategy-framework.md, pero con contenido estratificado:

Enfoque en contenido sustancial (contenido direccional, que afecta directamente el juicio):

• Problema empresarial + Objeto del mecanismo + Forma central del mecanismo (qué modelo se usa: ¿congelar-descongelar? ¿Fondo de bonificación? ¿Ponderación adicional? ¿Responsabilidad estratificada?)
• Roles involucrados + División aproximada del trabajo + Criterios de éxito

Marcadores ligeros (contenido operativo, para completar después):

• Proceso de ejecución: Esbozar los pasos generales, no escribir tabla |Hora|Quién|Qué hacer|
• Montos de fondos: Solo marcar marcador de "Por calcular", sin cifras concretas.
• Apelación/Revisión: Nota "Requiere diseño", sin escribir detalles.
• Plan de implementación/Piloto: Nota "Planificar después de confirmar la dirección"
• Riesgos: Listar las direcciones de riesgo, sin escribir respuestas detalladas.
• Elementos pendientes: Listar las preguntas que deben resolverse después.

Consultar experiencia de proyectos históricos (references/project-experience-index.md): Buscar diseños reutilizables de proyectos similares.

Condición de salida: Marco de la versión inicial completo (los 13 capítulos tienen contenido, con énfasis claro).

Interrupción forzosa: Después de emitir la versión inicial, detenerse y preguntar: "¿Es correcta la dirección? ¿El objeto está sesgado? ¿Falta algún rol en la división del trabajo?" — Lo mejor es mostrarlo a los ejecutores y responsables de la toma de decisiones para alinearlo. Si la dirección es incorrecta, todo el trabajo posterior será inútil.

Principio de la versión inicial: El objetivo es que los responsables de la toma de decisiones confirmen "si la dirección es correcta", no "si los números son correctos".

Retroceder a: Fase 0-3.

---

Fase 5: Diseño del mecanismo — Refinamiento elemento por elemento

Condición de entrada: Versión inicial de la dirección de la fase 4 confirmada.

Reglas de esta fase: En cada ronda, centrarse solo en un módulo del mecanismo, sin desarrollar todos a la vez:

1. Sistema de evaluación/indicadores (qué se evalúa, cómo se evalúa) → Confirmar
2. Restricciones centrales/mecanismos de activación (congelación, penalización, umbral, etc.) → Confirmar
3. Rutas de mejora/recuperación (cómo descongelar, cómo recuperar) → Confirmar
4. Recompensas/incentivos positivos → Confirmar
5. Responsabilidad solidaria de gestión → Confirmar
6. Proceso de ejecución + División de roles → Confirmar
7. Apelación/Revisión/Disciplina + Revisión de indicadores de verificación → Confirmar
8. Plan de implementación/Piloto → Confirmar

Después de confirmar cada módulo, pasar al siguiente. Si el usuario dice "cambiar tal cosa" a mitad de camino, solo se cambia el módulo actual, sin tocar los ya confirmados.

Condición de salida: Los 8 módulos confirmados por completo.

Interrupción forzosa: Al final de cada módulo, detenerse y preguntar: "¿Este módulo puede pasar?" Sin confirmación, no pasar al siguiente.

Nota: Después de que la versión inicial se muestre a los ejecutores para su confirmación, las modificaciones que estos devuelvan abren una V2.0, siguiendo el mismo proceso elemento por elemento.

Retroceder a: Cualquier fase anterior. Si durante el refinamiento se descubre que el objeto está equivocado, volver a la fase 2; si se descubre que las relaciones de roles están mal, volver a la fase 0.

---

Fase 6: Implementación organizativa

Condición de entrada: Todos los módulos de la fase 5 confirmados.

Reglas de esta fase:

1. El proceso de ejecución debe escribirse en una tabla |Hora|Quién|Qué hacer|
2. La división de roles debe ser coherente con el proceso de ejecución; cada rol solo escribe las tareas que realmente va a realizar.
3. Confirmar elemento por elemento: De dónde viene el dinero y adónde va, quién llena el formulario y quién lo confirma, quién es responsable de las apelaciones y quién las revisa, quién mantiene los datos y quién hace la liquidación final.
4. Riesgos y respuestas: Los que se pueden evitar se escriben directamente en las reglas del texto; los que no se pueden evitar temporalmente se colocan en la pila de elementos pendientes marcados como "Pendiente de discusión en la reunión".
5. Resumen de elementos pendientes (extraídos de la pila de elementos pendientes de todo el proceso).

Condición de salida: Tabla de proceso de ejecución completada, tabla de división de roles completada, riesgos gestionados (en el texto o en la pila de pendientes).

Interrupción forzosa: Después de emitir el marco completo del plan, detenerse y preguntar: "¿Lo entienden los ejecutores? ¿Hay algo que no se pueda implementar?"

Retroceder a: Cualquier fase anterior.

---

Fase 7: Versión final

Condición de entrada: Fase 6 completada y sin elementos pendientes restantes que afecten al texto.

Reglas de esta fase:

1. Eliminar todos los procesos de pensamiento, decisiones de compensación, por qué se eligió A en lugar de B, etc.
2. Dejar solo el texto limpio del plan: Reglas, procesos, división de roles, criterios de datos.
3. Emitir el texto completo según la estructura de 13 capítulos de references/strategy-framework.md.
4. Adjuntar "Elementos pendientes" (como apéndice, sin mezclar con el texto principal).

Condición de salida: Versión final, con número de versión.

Interrupción forzosa: Después de emitir, preguntar: "¿Se puede finalizar? ¿Se guarda en cases/?"

Acciones posteriores a la finalización:

• Guardar una copia en cases/, actualizar references/project-experience-index.md.
• Mantener la versión anterior sin sobrescribir.

---

Mecanismo de retroceso

En cualquier fase, cuando el usuario dice los siguientes comandos, se retrocede automáticamente:

El usuario dice	Retroceder a
"No, el problema no es este", "La causa raíz está mal"	Fase 1
"El objeto está sesgado", "Lo que se evalúa está mal"	Fase 2
"El competidor no es así", "Olvidé mencionar una referencia"	Fase 3
"La dirección está equivocada", "Cambiar de modelo"	Fase 4
"Falta un rol", "El rol XX en realidad no se puede usar así"	Fase 0 para complementar información de roles
"No estoy seguro de si vale la pena"	Fase 0

Al retroceder, se mantiene la pila de elementos pendientes existente, sin reiniciarla.

---

Elementos prohibidos

• Nunca dejar riesgos abiertos en el texto ("Existe el riesgo XX, tenga cuidado") → Escribirlo directamente como regla, o colocarlo en la pila de pendientes.
• No convertir el plan en eslóganes de valores.
• No asumir por defecto que el usuario tiene autoridad sobre recursos o poder de decisión.
• No emitir el marco completo del plan antes de la fase 4.
• No emitir todos los módulos a la vez en la fase 5.
• No saltarse ninguna interrupción forzosa para pasar directamente al siguiente paso.