opción

wiki-agents-md

microsoft/skills microsoft/skills

Genera archivos AGENTS.md para las carpetas del repositorio con el fin de proporcionar a los agentes de programación información específica del proyecto, como comandos de compilación, instrucciones de pruebas, estilo de código, estructura del proyecto y límites operativos, únicamente en los casos en los que no exista un archivo AGENTS.md.

...Expandir todo
6
Tiempo actualizado 11 de septiembre de 2026

Generador AGENTS.md

Genera archivos de alta calidad AGENTS.md para las carpetas del repositorio. Cada archivo proporciona a los agentes de programación el contexto específico del proyecto: comandos de compilación, instrucciones de pruebas, estilo de código, estructura y límites operativos.

¿Qué es AGENTS.md?

AGENTS.md complementa README.md. README está pensado para personas; AGENTS.md está pensado para agentes de programación.

  • Ubicación predecible: los agentes buscan AGENTS.md en el directorio actual y, a continuación, recorren el árbol hacia arriba
  • Archivos anidados: las subcarpetas pueden tener su propio AGENTS.md que tiene prioridad sobre el de la raíz
  • Separado del README — Mantiene los README concisos; los detalles específicos del agente (comandos exactos, límites, convenciones) van aquí
  • NO es lo mismo que .github/agents/*.agent.md — Esas son definiciones de la identidad del agente (quién es el agente). AGENTS.md Es el contexto del proyecto (lo que el agente debe saber sobre este código)

Protección crítica: generar solo si falta

Esta es la regla más importante de todas.

NUNCA sobrescribas un archivo AGENTS.md ya existente.

Antes de generar para CUALQUIER carpeta:

# Check if AGENTS.md already exists
ls AGENTS.md 2>/dev/null
  • Si existe → omítelo e informa de ello: "AGENTS.md already exists at — skipping"
  • Si no existe → continuar con la generación
  • Esta comprobación se aplica a cada carpeta de forma independiente

Detección de carpetas pertinentes

Identificar qué carpetas deben tener un AGENTS.md:

Generar siempre para:

  • Raíz del repositorio (/)
  • Carpeta Wiki (wiki/) — si la genera deep-wiki (tiene package.json con VitePress)

Generar si existen:

  • tests/, src/, lib/, app/, api/
  • Paquetes de monorepo: packages/*/, apps/*/, services/*/
  • Cualquier carpeta con su propio manifiesto de compilación:
    • package.json
    • pyproject.toml
    • Cargo.toml
    • *.csproj / *.fsproj
    • go.mod
    • pom.xml / build.gradle
  • .github/ — solo si contiene flujos de trabajo o acciones

Omitir siempre:

  • node_modules/, .git/, dist/, build/, out/, target/
  • vendor/, .venv/, venv/, __pycache__/
  • Cualquier directorio que sea salida generada o dependencias de terceros

Las seis áreas fundamentales

Todo buen archivo AGENTS.md cubre estas áreas, adaptadas a lo que realmente hay en la carpeta. No inventes secciones para cosas que el proyecto no tiene.

a) Comandos de compilación y ejecución — PONER EN PRIMER LUGAR

Los agentes hacen referencia a ellos constantemente. Utiliza los comandos exactos con sus opciones, no solo los nombres de las herramientas.

## Build & Run

npm install          # Install dependencies
npm run dev          # Start dev server (port 3000)
npm run build        # Production build
npm run lint         # Run ESLint

Lee estas fuentes para encontrar los comandos reales:

  • package.jsonscripts sección
  • Makefile → objetivos
  • pyproject.toml[tool.poetry.scripts] o [project.scripts]
  • Cargo.toml → comandos estándar de Cargo
  • Configuraciones de CI → .github/workflows/*.yml, Jenkinsfile, .gitlab-ci.yml

b) Instrucciones de prueba

## Testing

pytest tests/ -v                    # Run all tests
pytest tests/test_auth.py -v        # Run single file
pytest -k "test_login" -v           # Run single test by name
pytest --cov=src --cov-report=term  # With coverage

Incluir:

  • El marco de pruebas y cómo está configurado
  • Cómo ejecutar todas las pruebas, un único archivo o una sola prueba
  • Comportamiento esperado antes de las confirmaciones (p. ej., «todas las pruebas deben superarse»)

c) Estructura del proyecto

## Project Structure

src/
├── api/          # FastAPI route handlers
├── models/       # Pydantic data models
├── services/     # Business logic
└── utils/        # Shared utilities

tests/            # Mirrors src/ structure

Incluye:

  • Los directorios principales y su contenido
  • Puntos de entrada (p. ej., src/main.py, src/index.ts)
  • Dónde añadir nuevas funcionalidades

d) Estilo y convenciones de código

Un ejemplo de código real vale más que tres párrafos de descripción.

## Code Style

- snake_case for functions and variables
- PascalCase for classes
- Type hints on all function signatures
- Async/await for I/O operations

### Example

```python
async def get_user_by_id(user_id: str) -> User:
    """Fetch a user by their unique identifier."""
    async with get_db_session() as session:
        return await session.get(User, user_id)

Detect conventions by reading existing code:
- Naming patterns (camelCase, snake_case, PascalCase)
- Import organization (stdlib → third-party → local)
- Module structure patterns

### e) Git Workflow

```markdown
## Git Workflow

- Branch naming: `feature/`, `fix/`, `chore/`
- Commit messages: conventional commits (`feat:`, `fix:`, `docs:`)
- Run `npm test && npm run lint` before committing
- PR titles follow conventional commit format

Inclúyelo solo si el repositorio muestra que se siguen convenciones (p. ej., configuración de commitlint, plantillas de PR, guías de contribución).

f) Límites

Utiliza un sistema de tres niveles:

## Boundaries

- ✅ **Always do:** Run tests before committing. Write tests for new features. Use type hints.
- ⚠️ **Ask first:** Adding new dependencies. Changing database schemas. Modifying CI/CD configs. Changing public API signatures.
- 🚫 **Never do:** Commit secrets or credentials. Modify `vendor/` or `node_modules/`. Push directly to `main`. Delete migration files.

Adapta los límites al proyecto:

  • Proyectos de backend: cambios en el esquema, contratos de API
  • Proyectos de frontend: API de componentes que rompen la compatibilidad, cambios en el sistema de diseño
  • Infraestructura: configuraciones de producción, permisos de IAM

Proceso de generación

Al generar un archivo AGENTS.md para una carpeta específica:

Paso 1: Comprobar si existe

ls /AGENTS.md 2>/dev/null

Si existe, detente. Informa de ello y pasa a la siguiente carpeta.

Paso 2: Analizar la carpeta

Identificar:

  • El lenguaje principal (Python, TypeScript, Rust, Go, Java, C#)
  • Framework (FastAPI, Next.js, Actix, Spring Boot)
  • Herramienta de compilación (npm, cargo, poetry, maven, gradle)
  • Ejecutor de pruebas (pytest, vitest, cargo test, JUnit)

Paso 3: Leer los archivos de configuración

Extraer comandos y ajustes reales de:

  • package.json scripts
  • Makefile / Justfile objetivos
  • pyproject.toml scripts y configuraciones de herramientas
  • Cargo.toml metadatos
  • .github/workflows/*.yml pasos de compilación/prueba
  • docker-compose.yml definiciones de servicios
  • Configuraciones de Linter (.eslintrc, ruff.toml, rustfmt.toml)

Paso 4: Detectar convenciones

Lee entre 3 y 5 archivos fuente para identificar:

  • Patrones de nomenclatura
  • Organización de las importaciones
  • Estilo de gestión de errores
  • Estilo de los comentarios
  • Estructura de los módulos

Paso 5: Redacta el archivo AGENTS.md

Utiliza solo las secciones que correspondan. Si la carpeta no contiene pruebas, omite la sección de pruebas. Si no hay configuración de CI, omite el flujo de trabajo de Git.

Paso 6: Valida

Antes de escribir el archivo:

  • Cada comando hace referencia a un script, un objetivo o una herramienta reales
  • Cada ruta de archivo hace referencia a un archivo o directorio real
  • No debe haber texto de marcador de posición como o TODO
  • No se incluyen secciones inventadas para elementos que no existen

Estructura de la plantilla

# [Folder Name] — Agent Instructions

## Overview
[1-2 sentences: what this folder/project does, its role in the larger system]

## Build & Run
[Exact commands — install, dev, build, clean]

## Testing
[Framework, run commands, single-test commands]

## Project Structure
[Key directories, entry points, where to add new things]

## Code Style
[Naming conventions + one real code example from this project]

## Boundaries
- ✅ **Always do:** [safe operations]
- ⚠️ **Ask first:** [risky operations]
- 🚫 **Never do:** [dangerous operations]

## Documentation
[Only include if wiki/, llms.txt, or docs/ exist in the repo]
- Wiki: `wiki/` — architecture, API, onboarding guides
- LLM Context: `llms.txt` — project summary for coding agents (full version: `wiki/llms-full.txt`)
- Onboarding: `wiki/onboarding/` — guides for contributors, staff engineers, executives, PMs

Omite cualquier sección que no sea aplicable. Un archivo AGENTS.md de 20 líneas con comandos reales es mejor que uno de 200 líneas con contenido genérico de relleno.

AGENTS.md raíz frente a AGENTS.md anidados

AGENTS.md raíz (/AGENTS.md)

Abarca todo el proyecto:

  • Pila tecnológica y arquitectura generales
  • Convenciones globales y normas de codificación
  • Configuración del entorno de desarrollo
  • Límites en todo el repositorio
  • Descripción general de CI/CD

Archivos AGENTS.md anidados (p. ej., tests/AGENTS.md)

Abarca esa subcarpeta específica:

  • Qué hace esta carpeta y por qué existe
  • Comandos específicos de la carpeta (p. ej., cd tests && pnpm test)
  • Convenciones específicas de la carpeta
  • NO debe repetir el contenido del nivel raíz

Wiki AGENTS.md (wiki/AGENTS.md)

COMPRUEBA SIEMPRE si wiki/AGENTS.md existe antes de generar — la misma condición «solo si falta» que en el resto de carpetas. Si existe, omítela.

Utiliza esta plantilla (adáptala al proyecto concreto):

# Wiki — Agent Instructions

## Overview
Generated VitePress documentation site. Contains architecture docs, onboarding guides, and API references with source-linked citations and dark-mode Mermaid diagrams.

## Build & Run
- Install: `npm install`
- Dev server: `npm run dev`
- Build: `npm run build`
- Preview: `npm run preview`

## Wiki Structure
- `index.md` — Landing page with project overview and navigation
- `onboarding/` — Audience-tailored guides (contributor, staff engineer, executive, product manager)
- `{NN}-{section}/` — Numbered documentation sections
- `llms.txt` — LLM-friendly project summary (links + descriptions)
- `llms-full.txt` — LLM-friendly full content (inlined pages)
- `.vitepress/config.mts` — VitePress config with sidebar and Mermaid setup
- `.vitepress/theme/` — Dark theme (custom.css) and zoom handlers (index.ts)

## Content Conventions
- All Mermaid diagrams use dark-mode colors (fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`)
- Every page has VitePress frontmatter (`title`, `description`)
- Citations link to source repository with line numbers
- Tables include a "Source" column with linked citations
- Mermaid diagrams followed by `` comment blocks

## Boundaries
- ✅ **Always do:** Add new pages following existing section numbering, use dark-mode Mermaid colors
- ⚠️ **Ask first:** Change theme CSS, modify VitePress config, restructure sections
- 🚫 **Never do:** Delete generated pages without understanding dependencies, use light-mode colors, remove citation links

## Documentation
- Wiki: `./` — This folder is the wiki
- LLM Context: `llms.txt` — Quick summary; `llms-full.txt` — Full content
- Onboarding: `onboarding/` — Four audience-tailored guides

Rellena los nombres reales de las secciones, las tecnologías y las convenciones específicas del proyecto.

Los agentes leen el archivo AGENTS.md más cercano en el árbol de directorios. Los archivos anidados tienen prioridad, por lo que deben contener detalles específicos de la carpeta, no globales.

Archivo complementario CLAUDE.md

Cada vez que generes un AGENTS.md en una carpeta, genera también un CLAUDE.md en la misma carpeta, solo si aún no existe CLAUDE.md.

El CLAUDE.md contenido es siempre exactamente el siguiente:

# CLAUDE.md



Before beginning work in this repository, read `AGENTS.md` and follow all scoped AGENTS guidance.

Esto garantiza que Claude Code (y otras herramientas similares que buscan CLAUDE.md) sean redirigidas a las AGENTS.md .

Se aplica la misma condición de seguridad: comprueba si CLAUDE.md existe antes de escribir. Si existe, omítelo.

Principios de calidad

Principio Bueno Mal
Específico «React 18 con TypeScript, Vite y Tailwind CSS» «Proyecto React»
Ejecutable pytest tests/ -v --tb=short «ejecutar las pruebas»
Práctico Mostrar un fragmento de código real del proyecto Describir el estilo en términos generales
Rutas reales src/api/routes/ path/to/your/code/
Honesto Omite la sección de pruebas si no hay pruebas Inventar una sección de pruebas
Conciso Entre 30 y 80 líneas para la mayoría de las carpetas Más de 300 líneas de texto

Antipatrones que hay que evitar

  • «Eres un asistente de programación de gran ayuda»: demasiado vago, describe sentimientos, no acciones
  • Plantillas genéricas: el contenido que podría aplicarse a cualquier proyecto no aporta ningún valor
  • Comandos o rutas inventados: cada comando y cada ruta deben hacer referencia a algo real
  • Duplicar el README.md: el AGENTS.md complementa al README, no lo copia
  • Incluir información confidencial: nunca incluyas credenciales, claves API ni tokens en AGENTS.md
  • Sobrescribir archivos existentes: si ya existe AGENTS.md, no lo modifiques
  • Rellenar secciones vacías: si no hay pruebas, no escribas una sección de pruebas
  • Describir lo que los agentes deberían «pensar» o «sentir»: describe lo que deberían HACER
Ver en GitHub
---
name: wiki-agents-md
description: Generates AGENTS.md files for repository folders to provide coding agents with project-specific context including build commands, testing instructions, code style, project structure, and operational boundaries, only where AGENTS.md is missing.
license: MIT
---

# AGENTS.md Generator

Generate high-quality `AGENTS.md` files for repository folders. Each file provides coding agents with project-specific context — build commands, testing instructions, code style, structure, and operational boundaries.

## What is AGENTS.md

`AGENTS.md` complements `README.md`. README is for humans; AGENTS.md is for coding agents.

- **Predictable location** — Agents look for `AGENTS.md` in the current directory, then walk up the tree
- **Nested files** — Subfolders can have their own `AGENTS.md` that takes precedence over the root one
- **Separate from README** — Keeps READMEs concise; agent-specific details (exact commands, boundaries, conventions) go here
- **NOT the same as `.github/agents/*.agent.md`** — Those are agent persona definitions (who the agent is). `AGENTS.md` is project context (what the agent should know about this code)

## Critical Guard: Only Generate If Missing

> **This is the single most important rule.**

**NEVER overwrite an existing AGENTS.md.**

Before generating for ANY folder:

```bash
# Check if AGENTS.md already exists
ls AGENTS.md 2>/dev/null
```

- If it exists → **skip** and report: `"AGENTS.md already exists at <path> — skipping"`
- If it does not exist → proceed with generation
- This check applies to **every folder independently**

## Pertinent Folder Detection

Identify which folders should have an `AGENTS.md`:

### Always generate for:

- **Repository root** (`/`)
- **Wiki folder** (`wiki/`) — if generated by deep-wiki (has `package.json` with VitePress)

### Generate if they exist:

- `tests/`, `src/`, `lib/`, `app/`, `api/`
- Monorepo packages: `packages/*/`, `apps/*/`, `services/*/`
- Any folder with its own build manifest:
  - `package.json`
  - `pyproject.toml`
  - `Cargo.toml`
  - `*.csproj` / `*.fsproj`
  - `go.mod`
  - `pom.xml` / `build.gradle`
- `.github/` — only if it contains workflows or actions

### Always skip:

- `node_modules/`, `.git/`, `dist/`, `build/`, `out/`, `target/`
- `vendor/`, `.venv/`, `venv/`, `__pycache__/`
- Any directory that is generated output or third-party dependencies

## The Six Core Areas

Every good AGENTS.md covers these areas, tailored to what actually exists in the folder. Do not invent sections for things the project doesn't have.

### a) Build & Run Commands — PUT FIRST

Agents reference these constantly. Use exact commands with flags, not just tool names.

```markdown
## Build & Run

npm install          # Install dependencies
npm run dev          # Start dev server (port 3000)
npm run build        # Production build
npm run lint         # Run ESLint
```

Read these sources to find real commands:
- `package.json` → `scripts` section
- `Makefile` → targets
- `pyproject.toml` → `[tool.poetry.scripts]` or `[project.scripts]`
- `Cargo.toml` → standard cargo commands
- CI configs → `.github/workflows/*.yml`, `Jenkinsfile`, `.gitlab-ci.yml`

### b) Testing Instructions

```markdown
## Testing

pytest tests/ -v                    # Run all tests
pytest tests/test_auth.py -v        # Run single file
pytest -k "test_login" -v           # Run single test by name
pytest --cov=src --cov-report=term  # With coverage
```

Include:
- Test framework and how it's configured
- How to run all tests, a single file, a single test
- Expected behavior before commits (e.g., "all tests must pass")

### c) Project Structure

```markdown
## Project Structure

src/
├── api/          # FastAPI route handlers
├── models/       # Pydantic data models
├── services/     # Business logic
└── utils/        # Shared utilities

tests/            # Mirrors src/ structure
```

Include:
- Key directories and what they contain
- Entry points (e.g., `src/main.py`, `src/index.ts`)
- Where to add new features

### d) Code Style & Conventions

One real code example beats three paragraphs of description.

```markdown
## Code Style

- snake_case for functions and variables
- PascalCase for classes
- Type hints on all function signatures
- Async/await for I/O operations

### Example

```python
async def get_user_by_id(user_id: str) -> User:
    """Fetch a user by their unique identifier."""
    async with get_db_session() as session:
        return await session.get(User, user_id)
```
```

Detect conventions by reading existing code:
- Naming patterns (camelCase, snake_case, PascalCase)
- Import organization (stdlib → third-party → local)
- Module structure patterns

### e) Git Workflow

```markdown
## Git Workflow

- Branch naming: `feature/`, `fix/`, `chore/`
- Commit messages: conventional commits (`feat:`, `fix:`, `docs:`)
- Run `npm test && npm run lint` before committing
- PR titles follow conventional commit format
```

Only include if the repo has evidence of conventions (e.g., commitlint config, PR templates, contributing guides).

### f) Boundaries

Use a three-tier system:

```markdown
## Boundaries

- ✅ **Always do:** Run tests before committing. Write tests for new features. Use type hints.
- ⚠️ **Ask first:** Adding new dependencies. Changing database schemas. Modifying CI/CD configs. Changing public API signatures.
- 🚫 **Never do:** Commit secrets or credentials. Modify `vendor/` or `node_modules/`. Push directly to `main`. Delete migration files.
```

Tailor boundaries to the project:
- Backend projects: schema changes, API contracts
- Frontend projects: breaking component APIs, design system changes
- Infrastructure: production configs, IAM permissions

## Generation Process

When generating an AGENTS.md for a specific folder:

### Step 1: Check existence

```bash
ls <folder>/AGENTS.md 2>/dev/null
```

If it exists, **stop**. Report and move to the next folder.

### Step 2: Scan the folder

Identify:
- Primary language (Python, TypeScript, Rust, Go, Java, C#)
- Framework (FastAPI, Next.js, Actix, Spring Boot)
- Build tool (npm, cargo, poetry, maven, gradle)
- Test runner (pytest, vitest, cargo test, JUnit)

### Step 3: Read config files

Extract real commands and settings from:
- `package.json` scripts
- `Makefile` / `Justfile` targets
- `pyproject.toml` scripts and tool configs
- `Cargo.toml` metadata
- `.github/workflows/*.yml` build/test steps
- `docker-compose.yml` service definitions
- Linter configs (`.eslintrc`, `ruff.toml`, `rustfmt.toml`)

### Step 4: Detect conventions

Read 3-5 source files to identify:
- Naming patterns
- Import organization
- Error handling style
- Comment style
- Module structure

### Step 5: Compose the AGENTS.md

Use only the sections that apply. If the folder has no tests, omit the testing section. If there's no CI config, omit git workflow.

### Step 6: Validate

Before writing the file:
- Every command references a real script, target, or tool
- Every file path references an actual file or directory
- No placeholder text like `<your-project>` or `TODO`
- No invented sections for things that don't exist

## Template Structure

```markdown
# [Folder Name] — Agent Instructions

## Overview
[1-2 sentences: what this folder/project does, its role in the larger system]

## Build & Run
[Exact commands — install, dev, build, clean]

## Testing
[Framework, run commands, single-test commands]

## Project Structure
[Key directories, entry points, where to add new things]

## Code Style
[Naming conventions + one real code example from this project]

## Boundaries
- ✅ **Always do:** [safe operations]
- ⚠️ **Ask first:** [risky operations]
- 🚫 **Never do:** [dangerous operations]

## Documentation
[Only include if wiki/, llms.txt, or docs/ exist in the repo]
- Wiki: `wiki/` — architecture, API, onboarding guides
- LLM Context: `llms.txt` — project summary for coding agents (full version: `wiki/llms-full.txt`)
- Onboarding: `wiki/onboarding/` — guides for contributors, staff engineers, executives, PMs
```

Omit any section that doesn't apply. A 20-line AGENTS.md with real commands beats a 200-line one with generic filler.

## Root vs Nested AGENTS.md

### Root AGENTS.md (`/AGENTS.md`)

Covers the entire project:
- Overall tech stack and architecture
- Global conventions and coding standards
- Dev environment setup
- Repository-wide boundaries
- CI/CD overview

### Nested AGENTS.md (e.g., `tests/AGENTS.md`)

Covers that specific subfolder:
- What this folder does and why it exists
- Folder-specific commands (e.g., `cd tests && pnpm test`)
- Folder-specific conventions
- Should NOT repeat root-level content

### Wiki AGENTS.md (`wiki/AGENTS.md`)

**ALWAYS check** if `wiki/AGENTS.md` exists before generating — same only-if-missing guard as all other folders. If it exists, skip it.

Use this template (adapt to the actual project):

```markdown
# Wiki — Agent Instructions

## Overview
Generated VitePress documentation site. Contains architecture docs, onboarding guides, and API references with source-linked citations and dark-mode Mermaid diagrams.

## Build & Run
- Install: `npm install`
- Dev server: `npm run dev`
- Build: `npm run build`
- Preview: `npm run preview`

## Wiki Structure
- `index.md` — Landing page with project overview and navigation
- `onboarding/` — Audience-tailored guides (contributor, staff engineer, executive, product manager)
- `{NN}-{section}/` — Numbered documentation sections
- `llms.txt` — LLM-friendly project summary (links + descriptions)
- `llms-full.txt` — LLM-friendly full content (inlined pages)
- `.vitepress/config.mts` — VitePress config with sidebar and Mermaid setup
- `.vitepress/theme/` — Dark theme (custom.css) and zoom handlers (index.ts)

## Content Conventions
- All Mermaid diagrams use dark-mode colors (fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`)
- Every page has VitePress frontmatter (`title`, `description`)
- Citations link to source repository with line numbers
- Tables include a "Source" column with linked citations
- Mermaid diagrams followed by `<!-- Sources: ... -->` comment blocks

## Boundaries
- ✅ **Always do:** Add new pages following existing section numbering, use dark-mode Mermaid colors
- ⚠️ **Ask first:** Change theme CSS, modify VitePress config, restructure sections
- 🚫 **Never do:** Delete generated pages without understanding dependencies, use light-mode colors, remove citation links

## Documentation
- Wiki: `./` — This folder is the wiki
- LLM Context: `llms.txt` — Quick summary; `llms-full.txt` — Full content
- Onboarding: `onboarding/` — Four audience-tailored guides
```

Fill in the real section names, technologies, and project-specific conventions.

Agents read the nearest AGENTS.md in the directory tree. Nested files take precedence, so they should contain folder-specific details, not global ones.

## CLAUDE.md Companion File

Whenever you generate an `AGENTS.md` in a folder, also generate a `CLAUDE.md` in the same folder — **only if `CLAUDE.md` does not already exist**.

The `CLAUDE.md` content is always exactly:

```markdown
# CLAUDE.md

<!-- Generated for repository development workflows. Do not edit directly. -->

Before beginning work in this repository, read `AGENTS.md` and follow all scoped AGENTS guidance.
```

This ensures Claude Code (and similar tools that look for `CLAUDE.md`) are redirected to the authoritative `AGENTS.md` instructions.

**Same guard applies:** check if `CLAUDE.md` exists before writing. If it exists, skip it.

## Quality Principles

| Principle | Good | Bad |
|-----------|------|-----|
| **Specific** | "React 18 with TypeScript, Vite, Tailwind CSS" | "React project" |
| **Executable** | `pytest tests/ -v --tb=short` | "run the tests" |
| **Grounded** | Show a real code snippet from the project | Describe the style in abstract terms |
| **Real paths** | `src/api/routes/` | `path/to/your/code/` |
| **Honest** | Omit testing section if no tests exist | Invent a testing section |
| **Concise** | 30-80 lines for most folders | 300+ lines of prose |

## Anti-Patterns to Avoid

- ❌ **"You are a helpful coding assistant"** — too vague, describes feelings not actions
- ❌ **Generic boilerplate** — content that could apply to any project provides no value
- ❌ **Invented commands/paths** — every command and path must reference something real
- ❌ **Duplicating README.md** — AGENTS.md complements README, doesn't copy it
- ❌ **Including secrets** — never put credentials, API keys, or tokens in AGENTS.md
- ❌ **Overwriting existing files** — if AGENTS.md exists, do not touch it
- ❌ **Padding empty sections** — if there are no tests, don't write a testing section
- ❌ **Describing what agents should "think" or "feel"** — describe what they should DO

Todos los archivos

0 archivos

Instalar wiki-agents-md

Descarga y descomprime los archivos de habilidades en tu directorio .claude/skills/.

Descargar ZIP

Clona el repositorio y copia los archivos de la habilidad a tu proyecto.

git clone https://github.com/microsoft/skills/tree/main/.github/plugins/deep-wiki/skills/wiki-agents-md # Copy SKILL.md to your .claude/skills/ directory

Copiar Copiar
Configuración rápida: Copia la carpeta de la habilidad en .claude/skills/ Claude detectará y utilizará automáticamente la habilidad
Repositorio microsoft/skills

Habilidades relacionadas

algorithmic-art
Tiempo actualizado 27 de agosto de 2026
receiving-code-review
Tiempo actualizado 3 de septiembre de 2026
tech-debt-tracker
Tiempo actualizado 29 de agosto de 2026
deprecation-and-migration
Tiempo actualizado 3 de septiembre de 2026
OR