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フォルダ (
wiki/) — deep-wikiによって生成される場合(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→scriptsセクションMakefile→ targetspyproject.toml→[tool.poetry.scripts]または[project.scripts]Cargo.toml→ 標準的なCargoコマンド- 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) コードスタイルと規約
実際のコード例1つが、3段落分の説明に勝る。
## 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)
プロジェクト全体を網羅:
- 全体的な技術スタックとアーキテクチャ
- グローバルな規約とコーディング標準
- 開発環境のセットアップ
- リポジトリ全体の境界
- 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を補完するものであり、コピーするものではない
- ❌ 機密情報の記載 — 認証情報、APIキー、トークンをAGENTS.mdに記載してはならない
- ❌ 既存のファイルの上書き — 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
コピー





家
