project-docs

Name: project-docs
Author: 686f6c61/alfred-dev

$npx mdskill add 686f6c61/alfred-dev/project-docs

Generate comprehensive project documentation in docs/ directory.

Reduces onboarding time by providing absolute project context.
Depends on existing codebase files and architecture decisions.
Audits current docs and generates missing standard documentation.
Outputs a structured markdown reference in the docs/ folder.

SKILL.md

.github/skills/project-docsView on GitHub ↗

---
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.

More from 686f6c61/alfred-dev

Skill	Description
acceptance-criteria	Generar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
architecture-docs	Usar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
bundle-size	Analizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
choose-stack	Usar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
ci-cd-pipeline	Configurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.
code-review-response	Usar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
compliance-check	Usar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
copy-review	Revisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
dependency-strategy	Estrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
dependency-update	Revisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.