Create tech docs

Al crear un documento técnico:

Paso 1: Analizar el código

1. Ejecutar git branch --show-current para obtener el branch actual
2. Ejecutar git log --oneline develop..HEAD para ver los commits del desarrollo
3. Ejecutar git diff develop...HEAD --stat para ver los archivos afectados
4. Ejecutar git diff develop...HEAD para analizar todos los cambios en detalle
5. Leer los archivos nuevos y modificados relevantes para entender la lógica implementada

Paso 2: Preguntar al usuario

Antes de generar el documento, SIEMPRE hacer estas preguntas al usuario en un solo mensaje. Inferir lo que se pueda del código/branch y presentarlo como sugerencia:

Antes de generar el documento, necesito confirmar algunos datos que no puedo inferir del código:

1. **Equipo:** ¿Cuál es el nombre del equipo? (ej: "Libro", "Custom", etc.)
2. **Desarrolladores:** ¿Quiénes participaron en el desarrollo?
3. **PRs del desarrollo:** [Si se detectan merge commits internos, listarlos]. ¿El PR principal ya tiene número, o aún no se ha creado?
4. **PBI/Ticket:** [Si se detecta un número de PBI/ticket en el nombre del branch, mencionarlo]. ¿Hay más contexto sobre este PBI o es suficiente?
5. **Formato de salida:** ¿En qué formato quieres el documento?
   - `.md` (Markdown)
   - `.docx` (Word)

• Si del branch se puede inferir un número de PBI (ej: feature/383213-nombre), mencionarlo en la pregunta 4
• Si en el git log se ven merge commits de PRs internos (ej: Merge pull request #67506), listarlos en la pregunta 3
• Esperar la respuesta del usuario antes de continuar
• NO generar ningún contenido del documento hasta que el usuario responda todas las preguntas y confirme que se puede proceder

Paso 3: Generar el documento

Generar el documento en español siguiendo este template:

# Documento Técnico [Título descriptivo de la funcionalidad]

[Párrafo introductorio de 1-3 oraciones describiendo qué se implementó, en qué módulo/plataforma, y qué contempla el desarrollo a alto nivel.]

## Desarrollo

- Equipo: [Nombre del equipo]
- Desarrolladores:
  - [Nombre del desarrollador 1]
- Resumen del Desarrollo:
  - [Punto principal de lo implementado]
  - [Detalles de cada sub-funcionalidad con viñetas anidadas para especificaciones]
  - [Lógica relevante, algoritmos, fixes incluidos]
- Pull requests del desarrollo:
  - ([número]) [Descripción del PR]

## Columnas / Estructura de datos

[Si aplica: tabla describiendo columnas, campos o estructura de datos del componente principal]

| # | Campo | Descripción |
|---|-------|-------------|
| 1 | Campo1 | Descripción del campo |

[Explicación adicional sobre filas especiales, consolidados, cálculos, etc.]

## Flujos y cascadas

[Si aplica: diagramas de flujo en texto mostrando cadenas de dependencia, cascadas de filtros, pipelines de datos, etc.]

### Comportamiento

- [Reglas de comportamiento del flujo]
- [Cómo interactúan los componentes entre sí]

## Reglas de negocio

### [Nombre de la regla]

[Explicación de la regla con contexto de por qué existe]

[Si aplica: tabla con ejemplos de entrada/salida]

| Entrada | Resultado |
|---------|-----------|
| valor1 | resultado1 |

[Detalles de implementación relevantes]

## Deuda técnica conocida

| Item | Estado | Notas |
|------|--------|-------|
| [Descripción] | [PENDIENTE/BLOQUEADO/EN PROGRESO] | [Contexto] |

Paso 4: Entregar en el formato elegido

Ubicación del archivo

El documento se guarda en la carpeta docs/ dentro del directorio raíz del proyecto actual:

1. Verificar si existe la carpeta docs/ en la raíz del proyecto
2. Si no existe, crearla con mkdir -p docs/
3. Guardar el archivo dentro de docs/

El nombre del archivo debe ser descriptivo basado en el título del documento, en kebab-case. Ejemplo: docs/documento-tecnico-filtros-dinamicos-ventas.md

Si el usuario eligió .md

Guardar el documento como archivo .md en docs/.

Si el usuario eligió .docx

1. Primero guardar el contenido como archivo .md en docs/
2. Luego generar el .docx en la misma carpeta docs/ ejecutando el script de conversión:

node ~/.claude/skills/create-tech-docs/generate-docx.js docs/<archivo>.md docs/<archivo>.docx

El script generate-docx.js está dentro de esta misma skill y usa el paquete docx (instalado en ~/.claude/node_modules/docx) para:

• Mapear # → Heading 1, ## → Heading 2, ### → Heading 3
• Convertir listas - a bullet points (con soporte de anidación)
• Convertir tablas | a tablas Word con bordes
• Convertir negritas a texto bold
• Párrafos normales con formato profesional

3. Informar al usuario la ruta del archivo generado

Reglas

• El documento debe estar en español (con tildes y acentos correctos)
• Analizar el código para extraer la mayor cantidad de detalles técnicos posible
• Incluir ejemplos concretos con datos reales cuando se encuentren en el código (formatos, cálculos, transformaciones)
• Las secciones "Columnas / Estructura de datos", "Flujos y cascadas" y "Deuda técnica conocida" son opcionales: omitirlas si no aplican al desarrollo
• La sección "Reglas de negocio" debe documentar toda lógica no trivial encontrada en el código: validaciones, transformaciones de datos, casos borde, algoritmos de emparejamiento, etc.
• Usar tablas para mostrar mapeos entrada/salida, transformaciones de datos, o ejemplos de comportamiento
• Usar diagramas de texto (con → y indentación) para mostrar flujos y dependencias
• NUNCA inventar información que no se pueda inferir del código: siempre preguntar al usuario
• NUNCA generar el documento hasta que el usuario haya respondido las preguntas del Paso 2 y confirmado que puede proceder
• Los PRs del desarrollo se incluyen solo si el usuario los proporciona o se detectan en el git log