Project Docs

---
name: project-docs
description: "Documentar el proyecto completo en docs/ para dar contexto absoluto a cualquier desarrollador. Activar ante: documentacion del proyecto, crear docs, organizar documentacion, estructura de docs"
---

# Documentación completa del proyecto

## Resumen

Este skill genera una documentación exhaustiva del proyecto en el directorio `docs/`. El objetivo es que cualquier persona que llegue al proyecto tenga contexto absoluto sin necesidad de preguntar: qué hace el proyecto, cómo funciona, cómo se configura, cómo se contribuye y por qué se tomaron las decisiones que se tomaron.

No se trata de documentar por documentar, sino de crear una referencia viva que reduzca el tiempo de onboarding y evite la pérdida de conocimiento cuando alguien deja el equipo.

## Proceso

### Paso 1: auditar la documentación existente

- Listar los ficheros de documentación actuales (README, docs/, wikis, comentarios de código).
- Identificar qué está documentado, qué falta y qué está desactualizado.
- Comprobar si hay decisiones de arquitectura sin documentar (ADRs pendientes).

### Paso 2: crear la estructura base en docs/

Generar los siguientes documentos si no existen:

```
docs/
  README.md              -- índice de la documentación
  architecture.md        -- visión general de la arquitectura
  getting-started.md     -- guía de inicio rápido
  development.md         -- guía de desarrollo (setup, tests, linting)
  api/                   -- documentación de API (si aplica)
  decisions/             -- ADRs (Architecture Decision Records)
```

### Paso 3: documentar cada sección

Para cada documento:

- **architecture.md**: componentes principales, flujo de datos, dependencias entre módulos, diagramas (Mermaid o texto). No repetir el código, explicar el diseño.
- **getting-started.md**: prerrequisitos, instalación, configuración, primera ejecución. Probarlo desde cero para verificar que funciona.
- **development.md**: cómo ejecutar tests, linting, formateo. Convenciones de código. Flujo de trabajo con Git.
- **API**: endpoints, parámetros, respuestas, códigos de error, ejemplos con curl.
- **decisions/**: un ADR por cada decisión no obvia. Formato: contexto, decisión, consecuencias.

### Paso 4: enlazar desde el README

El README principal debe apuntar a `docs/` para los detalles. El README es la puerta de entrada; la documentación completa está dentro.

## Qué NO hacer

- No duplicar información que ya está en el código (JSDoc, docstrings). Referenciar, no copiar.
- No documentar lo obvio. Documentar lo que no es evidente leyendo el código.
- No crear documentación que nadie va a mantener. Mejor poco y actualizado que mucho y obsoleto.