選項
首頁首頁 Skill 開發者工具 wiki-agents-md

wiki-agents-md

microsoft/skills microsoft/skills

針對儲存庫資料夾產生 AGENTS.md 檔案,以向編碼代理提供專屬該專案的背景資訊,包括建置指令、測試說明、程式碼風格、專案結構及運作範圍;但僅在缺少 AGENTS.md 檔案時才會進行此操作。

...展開全部
8
更新時間 2026-09-11

AGENTS.md 產生器

為儲存庫資料夾產生高品質 AGENTS.md 檔案。每個檔案皆為程式碼代理提供專屬該專案的背景資訊——包含建置指令、測試指引、程式碼風格、結構以及運作邊界。

什麼是 AGENTS.md

AGENTS.mdREADME.md。README 是為人類而設;AGENTS.md 則是為程式編寫代理而設。

  • 可預測的位置 — 程式代理會搜尋 AGENTS.md 當前目錄,然後沿目錄樹向上搜尋
  • 嵌套檔案 — 子資料夾可以擁有自己的 AGENTS.md ,且優先於根目錄中的 README
  • 與 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.json 搭配 VitePress 使用)

若存在則進行生成:

  • tests/, src/, lib/, app/, api/
  • 單一儲存庫套件: packages/*/, apps/*/, services/*/
  • 任何擁有獨立建置清單的資料夾:
    • package.json
    • pyproject.toml
    • Cargo.toml
    • *.csproj / *.fsproj
    • go.mod
    • pom.xml / build.gradle
  • .github/ — 僅限於包含工作流程或動作的情況

始終跳過:

  • node_modules/, .git/, dist/, build/, out/, target/
  • vendor/, .venv/, venv/, __pycache__/
  • 任何為生成輸出或第三方依賴項的目錄

六大核心領域

每份完善的 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.jsonscripts section
  • Makefile → 目標
  • pyproject.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) 程式碼風格與規範

一個真實的程式碼範例勝過三段文字說明。

## 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) 範疇界定

採用三層級系統:

## 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,請勿進行修改
  • 填充空置章節 — 若無測試,請勿撰寫測試章節
  • 描述代理程式應該「怎麼想」或「有什麼感受」——應描述它們應該「做什麼」
在 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

所有檔案

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

複製 複製
快速設定: 將技能資料夾複製到 .claude/skills/ Claude 會自動偵測並使用該技能
儲存庫 microsoft/skills

相關技能

algorithmic-art
更新時間 2026-08-27
receiving-code-review
更新時間 2026-09-03
tech-debt-tracker
更新時間 2026-08-29
systematic-debugging
更新時間 2026-09-03
OR