# Create Tech Docs

> Genera documentos técnicos detallados de funcionalidades implementadas. Usar cuando el usuario pida crear documentación técnica, documentar una feature, o generar un documento técnico de un desarrollo.

- Skill: `phoebe-wd/create-tech-docs` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add phoebe-wd/create-tech-docs`
- Raw SKILL.md: https://api.skillmd.com/api/skills/phoebe-wd/create-tech-docs/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Phoebe-WD (https://skillmd.com/u/phoebe-wd)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/phoebe-wd/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:

```markdown
# 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:

```bash
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