/project-docs
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
$ npx -y skills add 686f6c61/alfred-dev --skill project-docs --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/project-docs
Context preview
The summary Claude sees to decide when to auto-load this skill.
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
SKILL.md
project-docs.SKILL.mdname: 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.
Read more
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.
Plugin de Claude Code: 18 agentes especializados, 60 skills, 25 comandos, 13 hooks, memoria persistente, Memory UI local, quality gates, evidence guard, continuidad operativa y modo autopilot.
Repo: 686f6c61/alfred-dev
Other skills on alfred-dev.
- /alfred
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Open skill - /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
Open skill - /design-system
Usar para diseñar la arquitectura de un sistema con diagramas y contratos. Activar cuando el usuario quiera diseñar arquitectura, definir componentes del sistema, crear un diagrama de flujo, establecer contratos entre módulos, planificar la estructura del proyecto o decidir cómo
Open skill - /evaluate-dependencies
Usar para evaluar si una dependencia merece la pena antes de añadirla. Activar cuando el usuario quiera añadir una librería, saber si merece la pena esta dependencia, evaluar un paquete antes de instalarlo, hacer npm install o pip install de algo nuevo, buscar alternativas a una
Open skill - /write-adr
Usar para documentar decisiones arquitectónicas como ADR. Activar cuando el usuario quiera documentar por qué se tomó una decisión, registrar alternativas descartadas, crear un ADR, un decision record, dejar constancia de una elección técnica o justificar una decisión de diseño
Open skill - /code-review
Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review.
Open skill

