wiki-agents-md
microsoft/skills
저장소 폴더에 대해 AGENTS.md 파일을 생성하여, 코딩 에이전트에게 빌드 명령어, 테스트 지침, 코드 스타일, 프로젝트 구조 및 운영 범위 등 프로젝트별 컨텍스트를 제공합니다. 단, AGENTS.md 파일이 없는 폴더에 한해 생성됩니다.
...모든 것을 확장하십시오AGENTS.md 생성기
저장소 폴더용 고품질 AGENTS.md 파일을 생성합니다. 각 파일은 코딩 담당자에게 빌드 명령어, 테스트 지침, 코드 스타일, 구조 및 운영 범위 등 프로젝트별 맥락을 제공합니다.
AGENTS.md란?
AGENTS.md 는 README.md. README는 사람을 위한 것이고, AGENTS.md는 코딩 에이전트를 위한 것입니다.
- 예측 가능한 위치 — 에이전트는
AGENTS.md현재 디렉터리에서 해당 파일을 찾은 후, 디렉터리 트리를 거슬러 올라갑니다 - 중첩된 파일 — 하위 폴더에는 자체
AGENTS.md이 루트 디렉터리의 파일보다 우선 적용됩니다 - README와 분리 — README를 간결하게 유지하며, 에이전트별 세부 사항(정확한 명령어, 제한 사항, 규칙)은 여기에 기재합니다
.github/agents/*.agent.md와는 다릅니다 — 해당 파일은 에이전트 페르소나 정의(에이전트가 누구인지)입니다.AGENTS.md이는 프로젝트 컨텍스트(에이전트가 이 코드에 대해 알아야 할 사항)입니다
중요 조건: 누락된 경우에만 생성
이것이 가장 중요한 규칙입니다.
절대 기존 AGENTS.md 파일을 덮어쓰지 마십시오.
어떤 폴더에 대해서도 생성하기 전에:
# Check if AGENTS.md already exists
ls AGENTS.md 2>/dev/null
- 파일이 존재하면 → 건너뛰고 다음을 보고합니다:
"AGENTS.md already exists at— skipping" - 존재하지 않을 경우 → 생성 진행
- 이 확인 절차는 모든 폴더에 대해 개별적으로 적용됩니다.
관련 폴더 감지
다음과 같은 폴더를 식별합니다. AGENTS.md:
항상 생성 대상:
- 리포지토리 루트 (
/) - 위키 폴더 (
wiki/) — deep-wiki에 의해 생성된 경우 (VitePress와package.jsonVitePress와 함께)
다음이 존재할 경우 생성:
tests/,src/,lib/,app/,api/- 모노레포 패키지:
packages/*/,apps/*/,services/*/ - 자체 빌드 매니페스트가 있는 모든 폴더:
package.jsonpyproject.tomlCargo.toml*.csproj/*.fsprojgo.modpom.xml/build.gradle
.github/— 워크플로우나 액션이 포함된 경우에만
항상 건너뛰기:
node_modules/,.git/,dist/,build/,out/,target/vendor/,.venv/,venv/,__pycache__/- 생성된 출력물이나 타사 종속성이 포함된 모든 디렉터리
6가지 핵심 영역
모든 훌륭한 AGENTS.md 파일은 폴더 내에 실제로 존재하는 항목에 맞춰 이러한 영역을 다루어야 합니다. 프로젝트에 없는 항목을 위해 섹션을 임의로 만들지 마십시오.
a) 빌드 및 실행 명령어 — 맨 앞에 배치
에이전트는 이를 끊임없이 참조합니다. 도구 이름만 적지 말고, 플래그가 포함된 정확한 명령어를 사용하십시오.
## Build & Run
npm install # Install dependencies
npm run dev # Start dev server (port 3000)
npm run build # Production build
npm run lint # Run ESLint
실제 명령어를 확인하려면 다음 자료를 참고하세요:
package.json→scriptssectionMakefile→ targetspyproject.toml→[tool.poetry.scripts]또는[project.scripts]Cargo.toml→ 표준 카고 명령어- CI 구성 →
.github/workflows/*.yml,Jenkinsfile,.gitlab-ci.yml
b) 테스트 지침
## 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
다음 내용을 포함하십시오:
- 테스트 프레임워크 및 구성 방법
- 모든 테스트, 단일 파일, 단일 테스트를 실행하는 방법
- 커밋 전 예상 동작 (예: “모든 테스트가 통과되어야 함”)
c) 프로젝트 구조
## Project Structure
src/
├── api/ # FastAPI route handlers
├── models/ # Pydantic data models
├── services/ # Business logic
└── utils/ # Shared utilities
tests/ # Mirrors src/ structure
포함 사항:
- 주요 디렉터리와 그 내용
- 시작점 (예:
src/main.py,src/index.ts) - 새로운 기능을 추가할 위치
d) 코드 스타일 및 규칙
실제 코드 예제 하나면 설명 세 문단보다 낫습니다.
## 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
리포지토리에 규칙을 따르고 있다는 증거(예: commitlint 구성, PR 템플릿, 기여 가이드)가 있는 경우에만 포함하십시오.
f) 경계
3단계 체계를 사용하세요:
## 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.
프로젝트에 맞게 경계를 조정하십시오:
- 백엔드 프로젝트: 스키마 변경, API 계약
- 프론트엔드 프로젝트: 호환성을 깨는 컴포넌트 API, 디자인 시스템 변경
- 인프라: 프로덕션 구성, IAM 권한
생성 프로세스
특정 폴더에 대한 AGENTS.md를 생성할 때:
1단계: 존재 여부 확인
ls /AGENTS.md 2>/dev/null
파일이 존재하면 중단합니다. 오류를 보고하고 다음 폴더로 이동합니다.
2단계: 폴더 스캔
다음 항목을 식별합니다:
- 주 언어 (Python, TypeScript, Rust, Go, Java, C#)
- 프레임워크 (FastAPI, Next.js, Actix, Spring Boot)
- 빌드 도구 (npm, cargo, poetry, maven, gradle)
- 테스트 실행 도구 (pytest, vitest, cargo test, JUnit)
3단계: 구성 파일 읽기
다음에서 실제 명령어와 설정을 추출합니다:
package.json스크립트Makefile/Justfile타깃pyproject.toml스크립트 및 도구 구성 파일Cargo.toml메타데이터.github/workflows/*.yml빌드/테스트 단계docker-compose.yml서비스 정의- 린터 설정 (
.eslintrc,ruff.toml,rustfmt.toml)
4단계: 코딩 규칙 감지
3~5개의 소스 파일을 읽어 다음을 식별합니다:
- 명명 규칙
- 임포트 구성
- 오류 처리 방식
- 주석 작성 방식
- 모듈 구조
5단계: AGENTS.md 작성
해당되는 섹션만 사용하십시오. 폴더에 테스트가 없는 경우, 테스트 섹션을 생략하십시오. CI 구성이 없는 경우, git 워크플로를 생략하십시오.
6단계: 검증
파일을 작성하기 전에:
- 모든 명령어는 실제 스크립트, 대상 또는 도구를 참조해야 합니다
- 모든 파일 경로는 실제 파일이나 디렉터리를 가리켜야 합니다
- 다음과 같은 자리 표시자 텍스트가 없어야 합니다.
또는TODO - 존재하지 않는 항목에 대한 임의의 섹션을 추가해서는 안 됩니다
템플릿 구조
# [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
해당되지 않는 섹션은 생략하십시오. 실제 명령어가 포함된 20줄짜리 AGENTS.md 파일이, 일반적인 채우기 내용으로 채워진 200줄짜리 파일보다 낫습니다.
루트 AGENTS.md 대 중첩된 AGENTS.md
루트 AGENTS.md (/AGENTS.md)
전체 프로젝트를 다룹니다:
- 전체 기술 스택 및 아키텍처
- 전역 규칙 및 코딩 표준
- 개발 환경 설정
- 리포지토리 전체에 적용되는 범위
- CI/CD 개요
중첩된 AGENTS.md (예: tests/AGENTS.md)
해당 특정 하위 폴더를 다룹니다:
- 이 폴더의 역할과 존재 이유
- 폴더별 명령어 (예:
cd tests && pnpm test) - 폴더별 규칙
- 루트 레벨의 내용을 반복해서는 안 됨
Wiki AGENTS.md (wiki/AGENTS.md)
생성 전에 wiki/AGENTS.md 생성 전에 존재 여부를 항상 확인하십시오 — 다른 모든 폴더와 마찬가지로 ‘없을 때만’ 처리하는 조건이 적용됩니다. 파일이 존재하면 건너뜁니다.
이 템플릿을 사용하십시오(실제 프로젝트에 맞게 수정):
# 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
실제 섹션 이름, 기술, 프로젝트별 규칙을 입력하십시오.
에이전트는 디렉터리 트리에서 가장 가까운 AGENTS.md 파일을 읽습니다. 중첩된 파일이 우선하므로, 여기에는 전역적인 내용이 아닌 폴더별 세부 사항이 포함되어야 합니다.
CLAUDE.md 보조 파일
폴더 내에서 파일을 생성할 때마다 AGENTS.md 파일을 생성할 때마다, CLAUDE.md 파일을 생성해야 합니다. 단, 해당 폴더에 `CLAUDE.md` 파일이 이미 존재하는 경우는 예외입니다.
이 CLAUDE.md 내용은 항상 정확히 다음과 같습니다:
# CLAUDE.md
Before beginning work in this repository, read `AGENTS.md` and follow all scoped AGENTS guidance.
이를 통해 Claude Code(및 CLAUDE.md)가 표준 AGENTS.md 지침으로 리디렉션되도록 보장합니다.
다음과 같은 조건도 적용됩니다: 작성하기 전에 CLAUDE.md 가 있는지 확인한 후 작성하십시오. 존재한다면 건너뛰십시오.
품질 원칙
| 원칙 | 양호 | 나쁨 |
|---|---|---|
| 구체적 | "TypeScript, Vite, Tailwind CSS를 사용한 React 18" | "React 프로젝트" |
| 실행 가능 | pytest tests/ -v --tb=short |
"테스트 실행" |
| 실용적인 | 프로젝트의 실제 코드 스니펫 보여주기 | 스타일을 추상적인 용어로 설명하기 |
| 실제 경로 | src/api/routes/ |
path/to/your/code/ |
| 솔직함 | 테스트가 없는 경우 테스트 섹션을 생략하십시오 | 테스트 섹션을 임의로 작성 |
| 간결하게 | 대부분의 폴더는 30~80줄 | 300줄 이상의 설명문 |
피해야 할 안티패턴
- ❌ "당신은 도움이 되는 코딩 조수입니다" — 너무 모호하며, 행동이 아닌 감정을 묘사합니다
- ❌ 일반적인 상투적 문구 — 어떤 프로젝트에도 적용될 수 있는 내용은 아무런 가치를 제공하지 않습니다
- ❌ 임의로 만든 명령어/경로 — 모든 명령어와 경로는 실제 존재하는 것을 참조해야 함
- ❌ README.md 중복 — AGENTS.md는 README를 보완하는 것이지, 복사하는 것이 아닙니다
- ❌ 기밀 정보 포함 — AGENTS.md에 자격 증명, API 키 또는 토큰을 절대 포함하지 마십시오
- ❌ 기존 파일 덮어쓰기 — AGENTS.md 파일이 이미 존재하면 수정하지 마세요
- ❌ 불필요한 섹션 채우기 — 테스트가 없다면 테스트 섹션을 작성하지 마십시오
- ❌ 에이전트가 “생각”하거나 “느끼는” 바를 기술하는 것 — 에이전트가 “무엇을 해야 하는지”를 기술하십시오
---
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
모든 파일
0개 파일wiki-agents-md 설치
스킬 파일을 다운로드하여 .claude/skills/ 디렉터리에 압축을 풀어주세요.
ZIP 다운로드저장소를 클론하고 스킬 파일을 프로젝트에 복사하세요.
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
복사





집
