Skill

project-docs

Audits existing docs and generates full project documentation in docs/ including architecture.md, getting-started.md, development.md, API refs, and ADRs. For onboarding and context sharing.

Markdown

Mermaid

Git

documentation

npx claudepluginhub 686f6c61/alfred-dev --plugin alfred-dev

Tool Access

This skill uses the workspace's default tool permissions.

Preview

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.

SKILL.md

Similar Skills

codebase-documenter

586

Creates READMEs, architecture docs, code comments, and API documentation using templates and best practices for beginner-friendly codebases.

8 files

sundial-org-awesome-openclaw-skills-4

code-docs

Generates READMEs, API docs, changelogs, and architecture docs for code projects using TypeDoc, JSDoc, Sphinx, godoc. Guides documentation workflows for JS/TS, Python, Go.

3 files

python

documentation-guide

Guides project documentation structure, file organization, content requirements by project phase, and best practices for README.md, ARCHITECTURE.md, API docs, and more.

2 files

universal-dev-standards

Stats

Stars47

Forks6

Last CommitMar 13, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

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.