# Documentation And Adrs

> Registra decisiones y documentación. Úsalo al tomar decisiones arquitectónicas, cambiar APIs públicas, lanzar funcionalidades o registrar contexto que futuros ingenieros y agentes necesitarán.

Fuente: https://skillsagentes.com/skills/addyosmani/agent-skills/documentation-and-adrs
Markdown: https://skillsagentes.com/skills/addyosmani/agent-skills/documentation-and-adrs.md

Repositorio: https://github.com/addyosmani/agent-skills
Autor: addyosmani
Licencia: MIT
Actualizado: el mes pasado
Coste de contexto: 56 tok instalada, 2.4k tok al activarse, 2.4k tok con todos los archivos del bundle
Bundle: 1 archivo, 10 KB
Permisos que pide: ninguno declarado

## Instalación

Un skill son archivos markdown: los mismos archivos valen para cualquier agente y lo único que cambia es el directorio de destino, es decir la bandera `--agent`. Añade `-g` para instalarlo en todos los proyectos de la máquina.

```bash
# Claude Code
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent claude-code
# Cursor
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent cursor
# Codex
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent codex
# Gemini CLI
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent gemini
# Windsurf
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent windsurf
# Cline
npx -y skills add addyosmani/agent-skills --skill documentation-and-adrs --agent cline
```

## Qué hace

- Guía la creación de ADRs (Architecture Decision Records) con plantilla, ciclo de vida y convenciones existentes
- Define cuándo y cómo comentar código, priorizando el porqué sobre el qué
- Establece estructura de documentación de APIs (JSDoc, OpenAPI/Swagger)
- Define estructura estándar de README y mantenimiento de Changelog
- Señala documentación específica para agentes (CLAUDE.md, specs, gotchas inline)

## Cuándo usarla

- Se toma una decisión arquitectónica significativa
- Se añade o cambia una API pública
- Se envía una feature que cambia el comportamiento visible al usuario
- Se necesita registrar contexto para que futuros ingenieros o agentes entiendan el código

## Cuándo no

- Para documentar código obvio o autoexplicativo
- Para añadir comentarios que solo repiten lo que ya dice el código
- Para escribir documentación de prototipos desechables

## Qué la activa

- "Escribe un ADR para justificar por qué elegimos PostgreSQL sobre MongoDB"
- "Documenta esta decisión de arquitectura antes de continuar"
- "Actualiza el README con la estructura de comandos del proyecto"
- "Añade documentación a esta API pública con JSDoc"

## Archivos

- SKILL.md — 10 KB

## SKILL.md

Reproducido tal cual desde addyosmani/agent-skills bajo MIT. Esta sección es el documento original y está en inglés.

# Documentation and ADRs

## Overview

Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase.

## When to Use

- Making a significant architectural decision
- Choosing between competing approaches
- Adding or changing a public API
- Shipping a feature that changes user-facing behavior
- Onboarding new team members (or agents) to the project
- When you find yourself explaining the same thing repeatedly

**When NOT to use:** Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes.

## Architecture Decision Records (ADRs)

ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write.

### When to Write an ADR

- Choosing a framework, library, or major dependency
- Designing a data model or database schema
- Selecting an authentication strategy
- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
- Choosing between build tools, hosting platforms, or infrastructure
- Any decision that would be expensive to reverse

### Match the existing convention first

Before creating an ADR, inspect the available repository context for an established convention — existing ADRs, project instructions, and ADR-related configuration or tooling (e.g. an `.adr-dir` file). An established convention overrides the defaults below. Match:

- **Location and format** — e.g. `docs/adr/*.md`, `Documentation/Decisions/*.rst`, a MADR layout, or an `adr-tools` setup. Match the existing directory, file extension, and markup (Markdown vs reStructuredText).
- **Numbering and naming** — continue the existing sequence and filename pattern (`ADR-004-Title.rst`, `0004-title.md`, …); don't restart at 001 or introduce a second scheme.
- **Section headings** — reuse the project's heading set rather than imposing this template's.

If the available evidence conflicts, surface the conflict rather than silently introducing another scheme. Only when no convention can be established do you apply the default below.

### ADR Template

Store ADRs in `docs/decisions/` with sequential numbering (unless the project already uses another location — see above):

```markdown
# ADR-001: Use PostgreSQL for primary database

## Status
Accepted | Superseded by ADR-XXX | Deprecated

## Date
2025-01-15

## Context
We need a primary database for the task management application. Key requirements:
- Relational data model (users, tasks, teams with relationships)
- ACID transactions for task state changes
- Support for full-text search on task content
- Managed hosting available (for small team, limited ops capacity)

## Decision
Use PostgreSQL with Prisma ORM.

## Alternatives Considered

### MongoDB
- Pros: Flexible schema, easy to start with
- Cons: Our data is inherently relational; would need to manage relationships manually
- Rejected: Relational data in a document store leads to complex joins or data duplication

### SQLite
- Pros: Zero configuration, embedded, fast for reads
- Cons: Limited concurrent write support, no managed hosting for production
- Rejected: Not suitable for multi-user web application in production

### MySQL
- Pros: Mature, widely supported
- Cons: PostgreSQL has better JSON support, full-text search, and ecosystem tooling
- Rejected: PostgreSQL is the better fit for our feature requirements

## Consequences
- Prisma provides type-safe database access and migration management
- We can use PostgreSQL's full-text search instead of adding Elasticsearch
- Team needs PostgreSQL knowledge (standard skill, low risk)
- Hosting on managed service (Supabase, Neon, or RDS)
```

### ADR Lifecycle

```
PROPOSED → ACCEPTED → (SUPERSEDED or DEPRECATED)
```

- **Don't delete old ADRs.** They capture historical context.
- When a decision changes, write a new ADR that references and supersedes the old one.

## Inline Documentation

### When to Comment

Comment the *why*, not the *what*:

```typescript
// BAD: Restates the code
// Increment counter by 1
counter += 1;

// GOOD: Explains non-obvious intent
// Rate limit uses a sliding window — reset counter at window boundary,
// not on a fixed schedule, to prevent burst attacks at window edges
if (now - windowStart > WINDOW_SIZE_MS) {
  counter = 0;
  windowStart = now;
}
```

### When NOT to Comment

```typescript
// Don't comment self-explanatory code
function calculateTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
}

// Don't leave TODO comments for things you should just do now
// TODO: add error handling  ← Just add it

// Don't leave commented-out code
// const oldImplementation = () => { ... }  ← Delete it, git has history
```

### Document Known Gotchas

```typescript
/**
 * IMPORTANT: This function must be called before the first render.
 * If called after hydration, it causes a flash of unstyled content
 * because the theme context isn't available during SSR.
 *
 * See ADR-003 for the full design rationale.
 */
export function initializeTheme(theme: Theme): void {
  // ...
}
```

## API Documentation

For public APIs (REST, GraphQL, library interfaces):

### Inline with Types (Preferred for TypeScript)

```typescript
/**
 * Creates a new task.
 *
 * @param input - Task creation data (title required, description optional)
 * @returns The created task with server-generated ID and timestamps
 * @throws {ValidationError} If title is empty or exceeds 200 characters
 * @throws {AuthenticationError} If the user is not authenticated
 *
 * @example
 * const task = await createTask({ title: 'Buy groceries' });
 * console.log(task.id); // "task_abc123"
 */
export async function createTask(input: CreateTaskInput): Promise<Task> {
  // ...
}
```

### OpenAPI / Swagger for REST APIs

```yaml
paths:
  /api/tasks:
    post:
      summary: Create a task
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/CreateTaskInput'
      responses:
        '201':
          description: Task created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Task'
        '422':
          description: Validation error
```

## README Structure

Every project should have a README that covers:

```markdown
# Project Name

One-paragraph description of what this project does.

## Quick Start
1. Clone the repo
2. Install dependencies: `npm install`
3. Set up environment: `cp .env.example .env`
4. Run the dev server: `npm run dev`

## Commands
| Command | Description |
|---------|-------------|
| `npm run dev` | Start development server |
| `npm test` | Run tests |
| `npm run build` | Production build |
| `npm run lint` | Run linter |

## Architecture
Brief overview of the project structure and key design decisions.
Link to ADRs for details.

## Contributing
How to contribute, coding standards, PR process.
```

## Changelog Maintenance

For shipped features:

```markdown
# Changelog

## [1.2.0] - 2025-01-20
### Added
- Task sharing: users can share tasks with team members (#123)
- Email notifications for task assignments (#124)

### Fixed
- Duplicate tasks appearing when rapidly clicking create button (#125)

### Changed
- Task list now loads 50 items per page (was 20) for better UX (#126)
```

## Documentation for Agents

Special consideration for AI agent context:

- **CLAUDE.md / rules files** — Document project conventions so agents follow them
- **Spec files** — Keep specs updated so agents build the right thing
- **ADRs** — Help agents understand why past decisions were made (prevents re-deciding)
- **Inline gotchas** — Prevent agents from falling into known traps

## Common Rationalizations

| Rationalization | Reality |
|---|---|
| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. |
| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. |
| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. |
| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. |
| "Comments get outdated" | Comments on *why* are stable. Comments on *what* get outdated — that's why you only write the former. |

## Red Flags

- Architectural decisions with no written rationale
- Public APIs with no documentation or types
- README that doesn't explain how to run the project
- Commented-out code instead of deletion
- TODO comments that have been there for weeks
- No ADRs in a project with significant architectural choices
- Documentation that restates the code instead of explaining intent

## Verification

After documenting:

- [ ] ADRs exist for all significant architectural decisions
- [ ] README covers quick start, commands, and architecture overview
- [ ] API functions have parameter and return type documentation
- [ ] Known gotchas are documented inline where they matter
- [ ] No commented-out code remains
- [ ] Rules files (CLAUDE.md etc.) are current and accurate

## Dónde encaja

- Categoría: [Documentos](https://skillsagentes.com/categorias/documentos.md) — Lee, escribe y transforma archivos PDF, DOCX, XLSX y PPTX.
- Creador: [addyosmani](https://skillsagentes.com/creators/addyosmani.md) — 5 skills en el directorio
- [Todas las skills](https://skillsagentes.com/skills.md)
- [Ranking de instalaciones](https://skillsagentes.com/ranking.md)

## Otras skills del mismo repositorio

- [Security And Hardening](https://skillsagentes.com/skills/addyosmani/agent-skills/security-and-hardening.md): Endurece el código contra vulnerabilidades. Úsalo al manejar entrada de usuario, autenticación, almacenamiento de datos, integraciones externas o datos personales (GDPR, CCPA).
- [Spec Driven Development](https://skillsagentes.com/skills/addyosmani/agent-skills/spec-driven-development.md): Crea especificaciones antes de programar: úsalo al iniciar un proyecto o cambio sin spec, cuando los requisitos son ambiguos, o cuando un requerimiento debe descomponerse en un mapa de módulos.
- [Code Review And Quality](https://skillsagentes.com/skills/addyosmani/agent-skills/code-review-and-quality.md): Realiza revisión de código en múltiples ejes. Úsalo antes de fusionar cualquier cambio, sea escrito por ti, otro agente o una persona, para evaluar la calidad antes de entrar a la rama principal.
- [Planning And Task Breakdown](https://skillsagentes.com/skills/addyosmani/agent-skills/planning-and-task-breakdown.md): Divide el trabajo en tareas ordenadas. Úsalo cuando tengas un spec o requisitos claros y necesites descomponer el trabajo en tareas implementables, estimar alcance o paralelizar.
- [Observability And Instrumentation](https://skillsagentes.com/skills/addyosmani/agent-skills/observability-and-instrumentation.md): Instrumenta el código para que el comportamiento en producción sea visible y diagnosticable, con logging, métricas, tracing y alertas.

## Skills relacionadas

- [Doubt Driven Development](https://skillsagentes.com/skills/addyosmani/agent-skills/doubt-driven-development.md): Somete cada decisión no trivial a una revisión adversarial con contexto fresco antes de darla por válida, cuando la corrección importa más que la velocidad o hay código desconocido o alto riesgo.
- [Idea Refine](https://skillsagentes.com/skills/addyosmani/agent-skills/idea-refine.md): Refina ideas en bruto en conceptos claros y accionables mediante pensamiento divergente y convergente estructurado.
- [Observability And Instrumentation](https://skillsagentes.com/skills/addyosmani/agent-skills/observability-and-instrumentation.md): Instrumenta el código para que el comportamiento en producción sea visible y diagnosticable, con logging, métricas, tracing y alertas.
- [Performance Optimization](https://skillsagentes.com/skills/addyosmani/agent-skills/performance-optimization.md): Optimiza el rendimiento en frontend, backend, consultas y bases de datos. Úsalo cuando haya requisitos de rendimiento, sospecha de regresión, Core Web Vitals bajos, patrones N+1 o cuellos de botella detectados por profiling.
- [Shipping And Launch](https://skillsagentes.com/skills/addyosmani/agent-skills/shipping-and-launch.md): Prepara lanzamientos a producción: checklist previa, monitoreo, rollout escalonado y estrategia de rollback.

---

Skills Agentes · [Índice de páginas en markdown](https://skillsagentes.com/sitemap.md) · [Inicio](https://skillsagentes.com/index.md)