Option
HeimHeim Skill Entwicklertools wiki-agents-md

wiki-agents-md

microsoft/skills microsoft/skills

Erstellt AGENTS.md-Dateien für Repository-Ordner, um Programmieragenten projektspezifische Informationen bereitzustellen, darunter Build-Befehle, Testanweisungen, Codestil, Projektstruktur und operative Grenzen – jedoch nur dort, wo eine AGENTS.md-Datei fehlt.

...Alle erweitern
6
Zeit aktualisiert 11. September 2026

AGENTS.md-Generator

Erstellen Sie hochwertige AGENTS.md Dateien für Repository-Ordner. Jede Datei liefert den Programmierern projektspezifische Informationen – Build-Befehle, Testanweisungen, Codestil, Struktur und operative Grenzen.

Was ist AGENTS.md

AGENTS.md ergänzt README.md. README ist für Menschen gedacht; AGENTS.md ist für Programmieragenten gedacht.

  • Vorhersehbarer Speicherort – Agenten suchen nach AGENTS.md im aktuellen Verzeichnis und durchlaufen dann die Verzeichnisstruktur nach oben
  • Verschachtelte Dateien – Unterordner können ihre eigene AGENTS.md , die Vorrang vor der Datei im Stammverzeichnis hat
  • Getrennt von README – So bleiben READMEs übersichtlich; agentenspezifische Details (genaue Befehle, Grenzen, Konventionen) gehören hierhin
  • NICHT dasselbe wie „.github/agents/*.agent.md — Dabei handelt es sich um Agenten-Persona-Definitionen (wer der Agent ist). AGENTS.md ist der Projektkontext (was der Agent über diesen Code wissen sollte)

Kritische Schutzmaßnahme: Nur generieren, wenn nicht vorhanden

Dies ist die wichtigste Regel überhaupt.

Überschreiben Sie NIEMALS eine vorhandene AGENTS.md-Datei.

Vor der Generierung für JEDEN Ordner:

# Check if AGENTS.md already exists
ls AGENTS.md 2>/dev/null
  • Wenn sie vorhanden ist → überspringen und melden: "AGENTS.md already exists at — skipping"
  • Falls nicht vorhanden → mit der Erstellung fortfahren
  • Diese Überprüfung gilt für jeden Ordner einzeln

Erkennung relevanter Ordner

Ermitteln, welche Ordner einen AGENTS.md:

Immer generieren für:

  • Repository-Stammverzeichnis (/)
  • Wiki-Ordner (wiki/) – falls von deep-wiki generiert (verfügt package.json mit VitePress)

Generieren, falls vorhanden:

  • tests/, src/, lib/, app/, api/
  • Monorepo-Pakete: packages/*/, apps/*/, services/*/
  • Jeder Ordner mit eigenem Build-Manifest:
    • package.json
    • pyproject.toml
    • Cargo.toml
    • *.csproj / *.fsproj
    • go.mod
    • pom.xml / build.gradle
  • .github/ — nur, wenn er Workflows oder Aktionen enthält

Immer überspringen:

  • node_modules/, .git/, dist/, build/, out/, target/
  • vendor/, .venv/, venv/, __pycache__/
  • Jedes Verzeichnis, das generierte Ausgabe oder Abhängigkeiten von Drittanbietern enthält

Die sechs Kernbereiche

Jede gute AGENTS.md-Datei deckt diese Bereiche ab, zugeschnitten auf das, was tatsächlich im Ordner vorhanden ist. Erfinden Sie keine Abschnitte für Dinge, die das Projekt nicht enthält.

a) Befehle zum Erstellen und Ausführen — AN ERSTER STELLE

Agenten greifen ständig darauf zurück. Verwende genaue Befehle mit Flags, nicht nur die Namen der Tools.

## Build & Run

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

Lies diese Quellen, um die tatsächlichen Befehle zu finden:

  • package.jsonscripts Abschnitt
  • Makefile → Ziele
  • pyproject.toml[tool.poetry.scripts] oder [project.scripts]
  • Cargo.toml → Standard-Cargo-Befehle
  • CI-Konfigurationen → .github/workflows/*.yml, Jenkinsfile, .gitlab-ci.yml

b) Testanweisungen

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

Enthalten:

  • Test-Framework und dessen Konfiguration
  • So führen Sie alle Tests, eine einzelne Datei oder einen einzelnen Test aus
  • Erwartetes Verhalten vor dem Commit (z. B. „Alle Tests müssen bestanden werden“)

c) Projektstruktur

## Project Structure

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

tests/            # Mirrors src/ structure

Enthalten:

  • Wichtige Verzeichnisse und deren Inhalt
  • Einstiegspunkte (z. B. src/main.py, src/index.ts)
  • Wo neue Funktionen hinzugefügt werden sollen

d) Codestil und Konventionen

Ein echtes Code-Beispiel sagt mehr als drei Absätze Beschreibung.

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

Nur aufnehmen, wenn das Repo Hinweise auf Konventionen enthält (z. B. „commitlint“-Konfiguration, PR-Vorlagen, Leitfäden für Mitwirkende).

f) Abgrenzungen

Verwenden Sie ein dreistufiges System:

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

Passen Sie die Abgrenzungen an das Projekt an:

  • Backend-Projekte: Schemaänderungen, API-Verträge
  • Frontend-Projekte: Kompatibilitätsbrechende Komponenten-APIs, Änderungen am Designsystem
  • Infrastruktur: Produktionskonfigurationen, IAM-Berechtigungen

Generierungsprozess

Bei der Generierung einer AGENTS.md für einen bestimmten Ordner:

Schritt 1: Vorhandensein prüfen

ls /AGENTS.md 2>/dev/null

Falls vorhanden, abbrechen. Melden und zum nächsten Ordner übergehen.

Schritt 2: Ordner scannen

Identifizieren:

  • Primäre Sprache (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)

Schritt 3: Konfigurationsdateien lesen

Extrahieren Sie tatsächliche Befehle und Einstellungen aus:

  • package.json Skripten
  • Makefile / Justfile Ziele
  • pyproject.toml Skripten und Tool-Konfigurationen
  • Cargo.toml Metadaten
  • .github/workflows/*.yml Build-/Testschritten
  • docker-compose.yml Dienstdefinitionen
  • Linter-Konfigurationen (.eslintrc, ruff.toml, rustfmt.toml)

Schritt 4: Konventionen erkennen

3–5 Quelldateien lesen, um Folgendes zu identifizieren:

  • Namenskonventionen
  • Importstruktur
  • Stil der Fehlerbehandlung
  • Kommentarstil
  • Modulstruktur

Schritt 5: Erstellen Sie die Datei „AGENTS.md“

Verwenden Sie nur die Abschnitte, die zutreffen. Wenn der Ordner keine Tests enthält, lassen Sie den Abschnitt „Testing“ weg. Wenn keine CI-Konfiguration vorhanden ist, lassen Sie den Abschnitt „Git-Workflow“ weg.

Schritt 6: Überprüfen

Bevor Sie die Datei erstellen:

  • Jeder Befehl verweist auf ein echtes Skript, ein Ziel oder ein Tool
  • Jeder Dateipfad verweist auf eine tatsächliche Datei oder ein Verzeichnis
  • Es darf kein Platzhaltertext wie oder TODO
  • Keine erfundenen Abschnitte für Dinge, die nicht existieren

Vorlagenstruktur

# [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

Lassen Sie alle Abschnitte weg, die nicht zutreffen. Eine 20-zeilige AGENTS.md-Datei mit echten Befehlen ist besser als eine 200-zeilige mit allgemeinem Fülltext.

Stammdatei vs. verschachtelte AGENTS.md-Dateien

Stamm-AGENTS.md (/AGENTS.md)

Deckt das gesamte Projekt ab:

  • Gesamter Tech-Stack und Architektur
  • Globale Konventionen und Codierungsstandards
  • Einrichtung der Entwicklungsumgebung
  • Repository-weite Grenzen
  • CI/CD-Übersicht

Verschachtelte AGENTS.md-Dateien (z. B. tests/AGENTS.md)

Bezieht sich auf diesen spezifischen Unterordner:

  • Was dieser Ordner bewirkt und warum er existiert
  • Ordnerspezifische Befehle (z. B. cd tests && pnpm test)
  • Ordnerspezifische Konventionen
  • Der Inhalt der obersten Ebene sollte NICHT wiederholt werden

Wiki AGENTS.md (wiki/AGENTS.md)

IMMER prüfen, ob wiki/AGENTS.md vor der Generierung vorhanden ist – dieselbe „Nur-wenn-fehlend“-Prüfung wie bei allen anderen Ordnern. Falls vorhanden, überspringen.

Verwende diese Vorlage (an das jeweilige Projekt anpassen):

# 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

Trage die tatsächlichen Abschnittsnamen, Technologien und projektspezifischen Konventionen ein.

Agenten lesen die nächstgelegene AGENTS.md-Datei in der Verzeichnisstruktur. Verschachtelte Dateien haben Vorrang, daher sollten sie ordnerspezifische Details enthalten, keine globalen.

CLAUDE.md-Begleitdatei

Wann immer du eine AGENTS.md in einem Ordner generieren, generieren Sie auch eine CLAUDE.md im selben Ordner – allerdings nur, wenn „CLAUDE.md“ noch nicht existiert.

Der CLAUDE.md Inhalt lautet immer genau:

# CLAUDE.md



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

Dadurch wird sichergestellt, dass Claude Code (und ähnliche Tools, die nach CLAUDE.md) auf die maßgeblichen AGENTS.md Anweisungen weitergeleitet werden.

Es gilt dieselbe Sicherheitsmaßnahme: Überprüfen Sie vor dem Schreiben, ob CLAUDE.md vor dem Schreiben vorhanden ist. Falls vorhanden, überspringen.

Qualitätsgrundsätze

Grundsatz Gut Schlecht
Spezifisch „React 18 mit TypeScript, Vite, Tailwind CSS“ „React-Projekt“
Ausführbar pytest tests/ -v --tb=short „Tests ausführen“
Fundiert Zeige einen echten Codeausschnitt aus dem Projekt Beschreibe den Stil in abstrakten Begriffen
Echte Pfade src/api/routes/ path/to/your/code/
Ehrlich Den Abschnitt „Tests“ weglassen, wenn keine Tests vorhanden sind Einen Testabschnitt erfinden
Prägnant 30–80 Zeilen für die meisten Ordner Über 300 Zeilen Text

Zu vermeidende Anti-Muster

  • „Du bist ein hilfsbereiter Programmierassistent“ – zu vage, beschreibt Gefühle statt Handlungen
  • Generische Standardformulierungen – Inhalte, die auf jedes Projekt zutreffen könnten, bieten keinen Mehrwert
  • Erfundene Befehle/Pfade – jeder Befehl und jeder Pfad muss sich auf etwas Reales beziehen
  • Duplizieren von README.md – AGENTS.md ergänzt README, kopiert es nicht
  • Geheimnisse einfügen – füge niemals Anmeldedaten, API-Schlüssel oder Tokens in AGENTS.md ein
  • Vorhandene Dateien überschreiben – wenn AGENTS.md bereits vorhanden ist, lass es unberührt
  • Leere Abschnitte auffüllen – wenn es keine Tests gibt, schreibe keinen Abschnitt „Tests“
  • Beschreiben, was Agenten „denken“ oder „fühlen“ sollen – beschreibe, was sie TUN sollen
Auf GitHub ansehen
---
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

Alle Dateien

0 Dateien

wiki-agents-md installieren

Laden Sie die Skill-Dateien herunter und entpacken Sie sie in Ihr Verzeichnis „.claude/skills/“.

ZIP herunterladen

Klonen Sie das Repository und kopieren Sie die Skill-Dateien in Ihr Projekt.

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

Kopieren Kopieren
Schnelle Einrichtung: Kopiere den Skill-Ordner nach .claude/skills/ Claude erkennt den Skill automatisch und nutzt ihn.
Repository microsoft/skills

Ähnliche Skills

algorithmic-art
Zeit aktualisiert 27. August 2026
receiving-code-review
Zeit aktualisiert 3. September 2026
tech-debt-tracker
Zeit aktualisiert 29. August 2026
deprecation-and-migration
Zeit aktualisiert 3. September 2026
OR