[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BN07TCZA86RTFC8NAZJM7":3,"skill-same:01M71BN07TCZA86RTFC8NAZJM7":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71BN07TCZA86RTFC8NAZJM7","wiki-agents-md",null,"Generates AGENTS.md files for repository folders — coding agent context files with build commands, testing instructions, code style, project structure, and boundaries. Only generates where AGENTS.md is missing.","strmt7\u002Fai_skills_collection_benchmarked","strmt7","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F28989754?v=4","01M71929P914SWKQ7QJV24NBBY","Stratos","01M71929Q9VGKQ7PWYR95VSQQQ",1,"MIT","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fcloud-azure-microsoft-sdks\u002Fofficial-vendor-reference\u002Fwiki-agents-md\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"wiki agents md","agents md","wiki","style","with","coding agent","missing","for","context","coding","context files","commands","repository","project structure","structure","code","files","only","testing","project","2026-11-10 10:12:30",false,"---\nname: wiki-agents-md\ndescription: Generates AGENTS.md files for repository folders — coding agent context files with build commands, testing instructions, code style, project structure, and boundaries. Only generates where AGENTS.md is missing.\nlicense: MIT\nmetadata:\n  author: Microsoft\n  version: \"1.0.0\"\n---\n\n# AGENTS.md Generator\n\nGenerate 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.\n\n## What is AGENTS.md\n\n`AGENTS.md` complements `README.md`. README is for humans; AGENTS.md is for coding agents.\n\n- **Predictable location** — Agents look for `AGENTS.md` in the current directory, then walk up the tree\n- **Nested files** — Subfolders can have their own `AGENTS.md` that takes precedence over the root one\n- **Separate from README** — Keeps READMEs concise; agent-specific details (exact commands, boundaries, conventions) go here\n- **NOT the same as `.github\u002Fagents\u002F*.agent.md`** — Those are agent persona definitions (who the agent is). `AGENTS.md` is project context (what the agent should know about this code)\n\n## Critical Guard: Only Generate If Missing\n\n> **This is the single most important rule.**\n\n**NEVER overwrite an existing AGENTS.md.**\n\nBefore generating for ANY folder:\n\n```bash\n# Check if AGENTS.md already exists\nls AGENTS.md 2>\u002Fdev\u002Fnull\n```\n\n- If it exists → **skip** and report: `\"AGENTS.md already exists at \u003Cpath> — skipping\"`\n- If it does not exist → proceed with generation\n- This check applies to **every folder independently**\n\n## Pertinent Folder Detection\n\nIdentify which folders should have an `AGENTS.md`:\n\n### Always generate for:\n\n- **Repository root** (`\u002F`)\n- **Wiki folder** (`wiki\u002F`) — if generated by deep-wiki (has `package.json` with VitePress)\n\n### Generate if they exist:\n\n- `tests\u002F`, `src\u002F`, `lib\u002F`, `app\u002F`, `api\u002F`\n- Monorepo packages: `packages\u002F*\u002F`, `apps\u002F*\u002F`, `services\u002F*\u002F`\n- Any folder with its own build manifest:\n  - `package.json`\n  - `pyproject.toml`\n  - `Cargo.toml`\n  - `*.csproj` \u002F `*.fsproj`\n  - `go.mod`\n  - `pom.xml` \u002F `build.gradle`\n- `.github\u002F` — only if it contains workflows or actions\n\n### Always skip:\n\n- `node_modules\u002F`, `.git\u002F`, `dist\u002F`, `build\u002F`, `out\u002F`, `target\u002F`\n- `vendor\u002F`, `.venv\u002F`, `venv\u002F`, `__pycache__\u002F`\n- Any directory that is generated output or third-party dependencies\n\n## The Six Core Areas\n\nEvery 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.\n\n### a) Build & Run Commands — PUT FIRST\n\nAgents reference these constantly. Use exact commands with flags, not just tool names.\n\n```markdown\n## Build & Run\n\nnpm install          # Install dependencies\nnpm run dev          # Start dev server (port 3000)\nnpm run build        # Production build\nnpm run lint         # Run ESLint\n```\n\nRead these sources to find real commands:\n- `package.json` → `scripts` section\n- `Makefile` → targets\n- `pyproject.toml` → `[tool.poetry.scripts]` or `[project.scripts]`\n- `Cargo.toml` → standard cargo commands\n- CI configs → `.github\u002Fworkflows\u002F*.yml`, `Jenkinsfile`, `.gitlab-ci.yml`\n\n### b) Testing Instructions\n\n```markdown\n## Testing\n\npytest tests\u002F -v                    # Run all tests\npytest tests\u002Ftest_auth.py -v        # Run single file\npytest -k \"test_login\" -v           # Run single test by name\npytest --cov=src --cov-report=term  # With coverage\n```\n\nInclude:\n- Test framework and how it's configured\n- How to run all tests, a single file, a single test\n- Expected behavior before commits (e.g., \"all tests must pass\")\n\n### c) Project Structure\n\n```markdown\n## Project Structure\n\nsrc\u002F\n├── api\u002F          # FastAPI route handlers\n├── models\u002F       # Pydantic data models\n├── services\u002F     # Business logic\n└── utils\u002F        # Shared utilities\n\ntests\u002F            # Mirrors src\u002F structure\n```\n\nInclude:\n- Key directories and what they contain\n- Entry points (e.g., `src\u002Fmain.py`, `src\u002Findex.ts`)\n- Where to add new features\n\n### d) Code Style & Conventions\n\nOne real code example beats three paragraphs of description.\n\n```markdown\n## Code Style\n\n- snake_case for functions and variables\n- PascalCase for classes\n- Type hints on all function signatures\n- Async\u002Fawait for I\u002FO operations\n\n### Example\n\n```python\nasync def get_user_by_id(user_id: str) -> User:\n    \"\"\"Fetch a user by their unique identifier.\"\"\"\n    async with get_db_session() as session:\n        return await session.get(User, user_id)\n```\n```\n\nDetect conventions by reading existing code:\n- Naming patterns (camelCase, snake_case, PascalCase)\n- Import organization (stdlib → third-party → local)\n- Module structure patterns\n\n### e) Git Workflow\n\n```markdown\n## Git Workflow\n\n- Branch naming: `feature\u002F`, `fix\u002F`, `chore\u002F`\n- Commit messages: conventional commits (`feat:`, `fix:`, `docs:`)\n- Run `npm test && npm run lint` before committing\n- PR titles follow conventional commit format\n```\n\nOnly include if the repo has evidence of conventions (e.g., commitlint config, PR templates, contributing guides).\n\n### f) Boundaries\n\nUse a three-tier system:\n\n```markdown\n## Boundaries\n\n- ✅ **Always do:** Run tests before committing. Write tests for new features. Use type hints.\n- ⚠️ **Ask first:** Adding new dependencies. Changing database schemas. Modifying CI\u002FCD configs. Changing public API signatures.\n- 🚫 **Never do:** Commit secrets or credentials. Modify `vendor\u002F` or `node_modules\u002F`. Push directly to `main`. Delete migration files.\n```\n\nTailor boundaries to the project:\n- Backend projects: schema changes, API contracts\n- Frontend projects: breaking component APIs, design system changes\n- Infrastructure: production configs, IAM permissions\n\n## Generation Process\n\nWhen generating an AGENTS.md for a specific folder:\n\n### Step 1: Check existence\n\n```bash\nls \u003Cfolder>\u002FAGENTS.md 2>\u002Fdev\u002Fnull\n```\n\nIf it exists, **stop**. Report and move to the next folder.\n\n### Step 2: Scan the folder\n\nIdentify:\n- Primary language (Python, TypeScript, Rust, Go, Java, C#)\n- Framework (FastAPI, Next.js, Actix, Spring Boot)\n- Build tool (npm, cargo, poetry, maven, gradle)\n- Test runner (pytest, vitest, cargo test, JUnit)\n\n### Step 3: Read config files\n\nExtract real commands and settings from:\n- `package.json` scripts\n- `Makefile` \u002F `Justfile` targets\n- `pyproject.toml` scripts and tool configs\n- `Cargo.toml` metadata\n- `.github\u002Fworkflows\u002F*.yml` build\u002Ftest steps\n- `docker-compose.yml` service definitions\n- Linter configs (`.eslintrc`, `ruff.toml`, `rustfmt.toml`)\n\n### Step 4: Detect conventions\n\nRead 3-5 source files to identify:\n- Naming patterns\n- Import organization\n- Error handling style\n- Comment style\n- Module structure\n\n### Step 5: Compose the AGENTS.md\n\nUse only the sections that apply. If the folder has no tests, omit the testing section. If there's no CI config, omit git workflow.\n\n### Step 6: Validate\n\nBefore writing the file:\n- Every command references a real script, target, or tool\n- Every file path references an actual file or directory\n- No placeholder text like `\u003Cyour-project>` or `TODO`\n- No invented sections for things that don't exist\n\n## Template Structure\n\n```markdown\n# [Folder Name] — Agent Instructions\n\n## Overview\n[1-2 sentences: what this folder\u002Fproject does, its role in the larger system]\n\n## Build & Run\n[Exact commands — install, dev, build, clean]\n\n## Testing\n[Framework, run commands, single-test commands]\n\n## Project Structure\n[Key directories, entry points, where to add new things]\n\n## Code Style\n[Naming conventions + one real code example from this project]\n\n## Boundaries\n- ✅ **Always do:** [safe operations]\n- ⚠️ **Ask first:** [risky operations]\n- 🚫 **Never do:** [dangerous operations]\n\n## Documentation\n[Only include if wiki\u002F, llms.txt, or docs\u002F exist in the repo]\n- Wiki: `wiki\u002F` — architecture, API, onboarding guides\n- LLM Context: `llms.txt` — project summary for coding agents (full version: `wiki\u002Fllms-full.txt`)\n- Onboarding: `wiki\u002Fonboarding\u002F` — guides for contributors, staff engineers, executives, PMs\n```\n\nOmit any section that doesn't apply. A 20-line AGENTS.md with real commands beats a 200-line one with generic filler.\n\n## Root vs Nested AGENTS.md\n\n### Root AGENTS.md (`\u002FAGENTS.md`)\n\nCovers the entire project:\n- Overall tech stack and architecture\n- Global conventions and coding standards\n- Dev environment setup\n- Repository-wide boundaries\n- CI\u002FCD overview\n\n### Nested AGENTS.md (e.g., `tests\u002FAGENTS.md`)\n\nCovers that specific subfolder:\n- What this folder does and why it exists\n- Folder-specific commands (e.g., `cd tests && pnpm test`)\n- Folder-specific conventions\n- Should NOT repeat root-level content\n\n### Wiki AGENTS.md (`wiki\u002FAGENTS.md`)\n\n**ALWAYS check** if `wiki\u002FAGENTS.md` exists before generating — same only-if-missing guard as all other folders. If it exists, skip it.\n\nUse this template (adapt to the actual project):\n\n```markdown\n# Wiki — Agent Instructions\n\n## Overview\nGenerated VitePress documentation site. Contains architecture docs, onboarding guides, and API references with source-linked citations and dark-mode Mermaid diagrams.\n\n## Build & Run\n- Install: `npm install`\n- Dev server: `npm run dev`\n- Build: `npm run build`\n- Preview: `npm run preview`\n\n## Wiki Structure\n- `index.md` — Landing page with project overview and navigation\n- `onboarding\u002F` — Audience-tailored guides (contributor, staff engineer, executive, product manager)\n- `{NN}-{section}\u002F` — Numbered documentation sections\n- `llms.txt` — LLM-friendly project summary (links + descriptions)\n- `llms-full.txt` — LLM-friendly full content (inlined pages)\n- `.vitepress\u002Fconfig.mts` — VitePress config with sidebar and Mermaid setup\n- `.vitepress\u002Ftheme\u002F` — Dark theme (custom.css) and zoom handlers (index.ts)\n\n## Content Conventions\n- All Mermaid diagrams use dark-mode colors (fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`)\n- Every page has VitePress frontmatter (`title`, `description`)\n- Citations link to source repository with line numbers\n- Tables include a \"Source\" column with linked citations\n- Mermaid diagrams followed by `\u003C!-- Sources: ... -->` comment blocks\n\n## Boundaries\n- ✅ **Always do:** Add new pages following existing section numbering, use dark-mode Mermaid colors\n- ⚠️ **Ask first:** Change theme CSS, modify VitePress config, restructure sections\n- 🚫 **Never do:** Delete generated pages without understanding dependencies, use light-mode colors, remove citation links\n\n## Documentation\n- Wiki: `.\u002F` — This folder is the wiki\n- LLM Context: `llms.txt` — Quick summary; `llms-full.txt` — Full content\n- Onboarding: `onboarding\u002F` — Four audience-tailored guides\n```\n\nFill in the real section names, technologies, and project-specific conventions.\n\nAgents read the nearest AGENTS.md in the directory tree. Nested files take precedence, so they should contain folder-specific details, not global ones.\n\n## CLAUDE.md Companion File\n\nWhenever 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**.\n\nThe `CLAUDE.md` content is always exactly:\n\n```markdown\n# CLAUDE.md\n\n\u003C!-- Generated for repository development workflows. Do not edit directly. -->\n\nBefore beginning work in this repository, read `AGENTS.md` and follow all scoped AGENTS guidance.\n```\n\nThis ensures Claude Code (and similar tools that look for `CLAUDE.md`) are redirected to the authoritative `AGENTS.md` instructions.\n\n**Same guard applies:** check if `CLAUDE.md` exists before writing. If it exists, skip it.\n\n## Quality Principles\n\n| Principle | Good | Bad |\n|-----------|------|-----|\n| **Specific** | \"React 18 with TypeScript, Vite, Tailwind CSS\" | \"React project\" |\n| **Executable** | `pytest tests\u002F -v --tb=short` | \"run the tests\" |\n| **Grounded** | Show a real code snippet from the project | Describe the style in abstract terms |\n| **Real paths** | `src\u002Fapi\u002Froutes\u002F` | `path\u002Fto\u002Fyour\u002Fcode\u002F` |\n| **Honest** | Omit testing section if no tests exist | Invent a testing section |\n| **Concise** | 30-80 lines for most folders | 300+ lines of prose |\n\n## Anti-Patterns to Avoid\n\n- ❌ **\"You are a helpful coding assistant\"** — too vague, describes feelings not actions\n- ❌ **Generic boilerplate** — content that could apply to any project provides no value\n- ❌ **Invented commands\u002Fpaths** — every command and path must reference something real\n- ❌ **Duplicating README.md** — AGENTS.md complements README, doesn't copy it\n- ❌ **Including secrets** — never put credentials, API keys, or tokens in AGENTS.md\n- ❌ **Overwriting existing files** — if AGENTS.md exists, do not touch it\n- ❌ **Padding empty sections** — if there are no tests, don't write a testing section\n- ❌ **Describing what agents should \"think\" or \"feel\"** — describe what they should DO\n","# AGENTS.md Generator\n\nGenerate 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.\n\n## What is AGENTS.md\n\n`AGENTS.md` complements `README.md`. README is for humans; AGENTS.md is for coding agents.\n\n- **Predictable location** — Agents look for `AGENTS.md` in the current directory, then walk up the tree\n- **Nested files** — Subfolders can have their own `AGENTS.md` that takes precedence over the root one\n- **Separate from README** — Keeps READMEs concise; agent-specific details (exact commands, boundaries, conventions) go here\n- **NOT the same as `.github\u002Fagents\u002F*.agent.md`** — Those are agent persona definitions (who the agent is). `AGENTS.md` is project context (what the agent should know about this code)\n\n## Critical Guard: Only Generate If Missing\n\n> **This is the single most important rule.**\n\n**NEVER overwrite an existing AGENTS.md.**\n\nBefore generating for ANY folder:\n\n```bash\n# Check if AGENTS.md already exists\nls AGENTS.md 2>\u002Fdev\u002Fnull\n```\n\n- If it exists → **skip** and report: `\"AGENTS.md already exists at \u003Cpath> — skipping\"`\n- If it does not exist → proceed with generation\n- This check applies to **every folder independently**\n\n## Pertinent Folder Detection\n\nIdentify which folders should have an `AGENTS.md`:\n\n### Always generate for:\n\n- **Repository root** (`\u002F`)\n- **Wiki folder** (`wiki\u002F`) — if generated by deep-wiki (has `package.json` with VitePress)\n\n### Generate if they exist:\n\n- `tests\u002F`, `src\u002F`, `lib\u002F`, `app\u002F`, `api\u002F`\n- Monorepo packages: `packages\u002F*\u002F`, `apps\u002F*\u002F`, `services\u002F*\u002F`\n- Any folder with its own build manifest:\n  - `package.json`\n  - `pyproject.toml`\n  - `Cargo.toml`\n  - `*.csproj` \u002F `*.fsproj`\n  - `go.mod`\n  - `pom.xml` \u002F `build.gradle`\n- `.github\u002F` — only if it contains workflows or actions\n\n### Always skip:\n\n- `node_modules\u002F`, `.git\u002F`, `dist\u002F`, `build\u002F`, `out\u002F`, `target\u002F`\n- `vendor\u002F`, `.venv\u002F`, `venv\u002F`, `__pycache__\u002F`\n- Any directory that is generated output or third-party dependencies\n\n## The Six Core Areas\n\nEvery 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.\n\n### a) Build & Run Commands — PUT FIRST\n\nAgents reference these constantly. Use exact commands with flags, not just tool names.\n\n```markdown\n## Build & Run\n\nnpm install          # Install dependencies\nnpm run dev          # Start dev server (port 3000)\nnpm run build        # Production build\nnpm run lint         # Run ESLint\n```\n\nRead these sources to find real commands:\n- `package.json` → `scripts` section\n- `Makefile` → targets\n- `pyproject.toml` → `[tool.poetry.scripts]` or `[project.scripts]`\n- `Cargo.toml` → standard cargo commands\n- CI configs → `.github\u002Fworkflows\u002F*.yml`, `Jenkinsfile`, `.gitlab-ci.yml`\n\n### b) Testing Instructions\n\n```markdown\n## Testing\n\npytest tests\u002F -v                    # Run all tests\npytest tests\u002Ftest_auth.py -v        # Run single file\npytest -k \"test_login\" -v           # Run single test by name\npytest --cov=src --cov-report=term  # With coverage\n```\n\nInclude:\n- Test framework and how it's configured\n- How to run all tests, a single file, a single test\n- Expected behavior before commits (e.g., \"all tests must pass\")\n\n### c) Project Structure\n\n```markdown\n## Project Structure\n\nsrc\u002F\n├── api\u002F          # FastAPI route handlers\n├── models\u002F       # Pydantic data models\n├── services\u002F     # Business logic\n└── utils\u002F        # Shared utilities\n\ntests\u002F            # Mirrors src\u002F structure\n```\n\nInclude:\n- Key directories and what they contain\n- Entry points (e.g., `src\u002Fmain.py`, `src\u002Findex.ts`)\n- Where to add new features\n\n### d) Code Style & Conventions\n\nOne real code example beats three paragraphs of description.\n\n```markdown\n## Code Style\n\n- snake_case for functions and variables\n- PascalCase for classes\n- Type hints on all function signatures\n- Async\u002Fawait for I\u002FO operations\n\n### Example\n\n```python\nasync def get_user_by_id(user_id: str) -> User:\n    \"\"\"Fetch a user by their unique identifier.\"\"\"\n    async with get_db_session() as session:\n        return await session.get(User, user_id)\n```\n```\n\nDetect conventions by reading existing code:\n- Naming patterns (camelCase, snake_case, PascalCase)\n- Import organization (stdlib → third-party → local)\n- Module structure patterns\n\n### e) Git Workflow\n\n```markdown\n## Git Workflow\n\n- Branch naming: `feature\u002F`, `fix\u002F`, `chore\u002F`\n- Commit messages: conventional commits (`feat:`, `fix:`, `docs:`)\n- Run `npm test && npm run lint` before committing\n- PR titles follow conventional commit format\n```\n\nOnly include if the repo has evidence of conventions (e.g., commitlint config, PR templates, contributing guides).\n\n### f) Boundaries\n\nUse a three-tier system:\n\n```markdown\n## Boundaries\n\n- ✅ **Always do:** Run tests before committing. Write tests for new features. Use type hints.\n- ⚠️ **Ask first:** Adding new dependencies. Changing database schemas. Modifying CI\u002FCD configs. Changing public API signatures.\n- 🚫 **Never do:** Commit secrets or credentials. Modify `vendor\u002F` or `node_modules\u002F`. Push directly to `main`. Delete migration files.\n```\n\nTailor boundaries to the project:\n- Backend projects: schema changes, API contracts\n- Frontend projects: breaking component APIs, design system changes\n- Infrastructure: production configs, IAM permissions\n\n## Generation Process\n\nWhen generating an AGENTS.md for a specific folder:\n\n### Step 1: Check existence\n\n```bash\nls \u003Cfolder>\u002FAGENTS.md 2>\u002Fdev\u002Fnull\n```\n\nIf it exists, **stop**. Report and move to the next folder.\n\n### Step 2: Scan the folder\n\nIdentify:\n- Primary language (Python, TypeScript, Rust, Go, Java, C#)\n- Framework (FastAPI, Next.js, Actix, Spring Boot)\n- Build tool (npm, cargo, poetry, maven, gradle)\n- Test runner (pytest, vitest, cargo test, JUnit)\n\n### Step 3: Read config files\n\nExtract real commands and settings from:\n- `package.json` scripts\n- `Makefile` \u002F `Justfile` targets\n- `pyproject.toml` scripts and tool configs\n- `Cargo.toml` metadata\n- `.github\u002Fworkflows\u002F*.yml` build\u002Ftest steps\n- `docker-compose.yml` service definitions\n- Linter configs (`.eslintrc`, `ruff.toml`, `rustfmt.toml`)\n\n### Step 4: Detect conventions\n\nRead 3-5 source files to identify:\n- Naming patterns\n- Import organization\n- Error handling style\n- Comment style\n- Module structure\n\n### Step 5: Compose the AGENTS.md\n\nUse only the sections that apply. If the folder has no tests, omit the testing section. If there's no CI config, omit git workflow.\n\n### Step 6: Validate\n\nBefore writing the file:\n- Every command references a real script, target, or tool\n- Every file path references an actual file or directory\n- No placeholder text like `\u003Cyour-project>` or `TODO`\n- No invented sections for things that don't exist\n\n## Template Structure\n\n```markdown\n# [Folder Name] — Agent Instructions\n\n## Overview\n[1-2 sentences: what this folder\u002Fproject does, its role in the larger system]\n\n## Build & Run\n[Exact commands — install, dev, build, clean]\n\n## Testing\n[Framework, run commands, single-test commands]\n\n## Project Structure\n[Key directories, entry points, where to add new things]\n\n## Code Style\n[Naming conventions + one real code example from this project]\n\n## Boundaries\n- ✅ **Always do:** [safe operations]\n- ⚠️ **Ask first:** [risky operations]\n- 🚫 **Never do:** [dangerous operations]\n\n## Documentation\n[Only include if wiki\u002F, llms.txt, or docs\u002F exist in the repo]\n- Wiki: `wiki\u002F` — architecture, API, onboarding guides\n- LLM Context: `llms.txt` — project summary for coding agents (full version: `wiki\u002Fllms-full.txt`)\n- Onboarding: `wiki\u002Fonboarding\u002F` — guides for contributors, staff engineers, executives, PMs\n```\n\nOmit any section that doesn't apply. A 20-line AGENTS.md with real commands beats a 200-line one with generic filler.\n\n## Root vs Nested AGENTS.md\n\n### Root AGENTS.md (`\u002FAGENTS.md`)\n\nCovers the entire project:\n- Overall tech stack and architecture\n- Global conventions and coding standards\n- Dev environment setup\n- Repository-wide boundaries\n- CI\u002FCD overview\n\n### Nested AGENTS.md (e.g., `tests\u002FAGENTS.md`)\n\nCovers that specific subfolder:\n- What this folder does and why it exists\n- Folder-specific commands (e.g., `cd tests && pnpm test`)\n- Folder-specific conventions\n- Should NOT repeat root-level content\n\n### Wiki AGENTS.md (`wiki\u002FAGENTS.md`)\n\n**ALWAYS check** if `wiki\u002FAGENTS.md` exists before generating — same only-if-missing guard as all other folders. If it exists, skip it.\n\nUse this template (adapt to the actual project):\n\n```markdown\n# Wiki — Agent Instructions\n\n## Overview\nGenerated VitePress documentation site. Contains architecture docs, onboarding guides, and API references with source-linked citations and dark-mode Mermaid diagrams.\n\n## Build & Run\n- Install: `npm install`\n- Dev server: `npm run dev`\n- Build: `npm run build`\n- Preview: `npm run preview`\n\n## Wiki Structure\n- `index.md` — Landing page with project overview and navigation\n- `onboarding\u002F` — Audience-tailored guides (contributor, staff engineer, executive, product manager)\n- `{NN}-{section}\u002F` — Numbered documentation sections\n- `llms.txt` — LLM-friendly project summary (links + descriptions)\n- `llms-full.txt` — LLM-friendly full content (inlined pages)\n- `.vitepress\u002Fconfig.mts` — VitePress config with sidebar and Mermaid setup\n- `.vitepress\u002Ftheme\u002F` — Dark theme (custom.css) and zoom handlers (index.ts)\n\n## Content Conventions\n- All Mermaid diagrams use dark-mode colors (fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`)\n- Every page has VitePress frontmatter (`title`, `description`)\n- Citations link to source repository with line numbers\n- Tables include a \"Source\" column with linked citations\n- Mermaid diagrams followed by `\u003C!-- Sources: ... -->` comment blocks\n\n## Boundaries\n- ✅ **Always do:** Add new pages following existing section numbering, use dark-mode Mermaid colors\n- ⚠️ **Ask first:** Change theme CSS, modify VitePress config, restructure sections\n- 🚫 **Never do:** Delete generated pages without understanding dependencies, use light-mode colors, remove citation links\n\n## Documentation\n- Wiki: `.\u002F` — This folder is the wiki\n- LLM Context: `llms.txt` — Quick summary; `llms-full.txt` — Full content\n- Onboarding: `onboarding\u002F` — Four audience-tailored guides\n```\n\nFill in the real section names, technologies, and project-specific conventions.\n\nAgents read the nearest AGENTS.md in the directory tree. Nested files take precedence, so they should contain folder-specific details, not global ones.\n\n## CLAUDE.md Companion File\n\nWhenever 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**.\n\nThe `CLAUDE.md` content is always exactly:\n\n```markdown\n# CLAUDE.md\n\n\u003C!-- Generated for repository development workflows. Do not edit directly. -->\n\nBefore beginning work in this repository, read `AGENTS.md` and follow all scoped AGENTS guidance.\n```\n\nThis ensures Claude Code (and similar tools that look for `CLAUDE.md`) are redirected to the authoritative `AGENTS.md` instructions.\n\n**Same guard applies:** check if `CLAUDE.md` exists before writing. If it exists, skip it.\n\n## Quality Principles\n\n| Principle | Good | Bad |\n|-----------|------|-----|\n| **Specific** | \"React 18 with TypeScript, Vite, Tailwind CSS\" | \"React project\" |\n| **Executable** | `pytest tests\u002F -v --tb=short` | \"run the tests\" |\n| **Grounded** | Show a real code snippet from the project | Describe the style in abstract terms |\n| **Real paths** | `src\u002Fapi\u002Froutes\u002F` | `path\u002Fto\u002Fyour\u002Fcode\u002F` |\n| **Honest** | Omit testing section if no tests exist | Invent a testing section |\n| **Concise** | 30-80 lines for most folders | 300+ lines of prose |\n\n## Anti-Patterns to Avoid\n\n- ❌ **\"You are a helpful coding assistant\"** — too vague, describes feelings not actions\n- ❌ **Generic boilerplate** — content that could apply to any project provides no value\n- ❌ **Invented commands\u002Fpaths** — every command and path must reference something real\n- ❌ **Duplicating README.md** — AGENTS.md complements README, doesn't copy it\n- ❌ **Including secrets** — never put credentials, API keys, or tokens in AGENTS.md\n- ❌ **Overwriting existing files** — if AGENTS.md exists, do not touch it\n- ❌ **Padding empty sections** — if there are no tests, don't write a testing section\n- ❌ **Describing what agents should \"think\" or \"feel\"** — describe what they should DO\n",{"name":5,"license":15,"metadata":49,"description":7},{"author":50,"version":51},"Microsoft","1.0.0","main","5c95bcac4646c5aed06bd9aed5235cfc7985aafc","included\u002Fskills\u002Fby-category\u002Fcloud-azure-microsoft-sdks\u002Fofficial-vendor-reference\u002Fwiki-agents-md",0,"https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked","https:\u002F\u002Fgithub.com\u002Fstrmt7","2026-11-11 04:18:12",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add strmt7\u002Fai_skills_collection_benchmarked --skill wiki-agents-md",{"tool":65,"command":66},"bunx","bunx skills add strmt7\u002Fai_skills_collection_benchmarked --skill wiki-agents-md",{"tool":68,"command":69},"pnpm","pnpm dlx skills add strmt7\u002Fai_skills_collection_benchmarked --skill wiki-agents-md","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fcloud-azure-microsoft-sdks\u002Fofficial-vendor-reference\u002Fwiki-agents-md\u002FSKILL.md",true,[],[74,101,131,156,182,209],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":79,"sourceHtmlUrl":80,"categories":81,"keywords":86,"publishedAt":44},"01M71D4H3T6M57DFKN8HENAWRV","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Ftesting-qa-benchmarking\u002Fofficial-reference\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Ftesting-qa-benchmarking\u002Fofficial-reference\u002Fwebapp-testing\u002FSKILL.md",[82,83],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[87,42,88,31,89,90,91,92,93,94,95,28,96,97,98,99,100],"webapp","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","playwright","web","behavior","ui","screenshots",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":111,"publishedAt":44},"01M71D4CQR2A2TB7GASCR5ZBG3","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Ftesting-qa-benchmarking\u002Fofficial-reference\u002Fskill-creator-anthropics\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Ftesting-qa-benchmarking\u002Fofficial-reference\u002Fskill-creator-anthropics\u002FSKILL.md",[108],{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,31,130],"skill creator","creator","performance","improve","run evals","new","when","analysis","create","optimize","variance analysis","run","edit","benchmark","a skill","existing skill","evals","modify","accuracy",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":139,"publishedAt":44},"01M71D488XHEZVXXSXFYP8ENMH","playwright-skill","Complete browser automation with Playwright. Auto-detects dev servers, writes reusable test scripts, and supports screenshots, responsive checks, UX validation, login flows, link checks, and arbitrary browser automation. Use when the user wants to test a website, automate browser interactions, validate web functionality, or perform browser-based testing.","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Ftesting-qa-benchmarking\u002Flatest-release-browser-automation\u002Fplaywright-skill\u002FSKILL.md",[137,138],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":109,"categoryName":110,"taxonomyType":21,"taxonomyTypeDesc":22},[96,140,141,142,42,143,144,118,145,95,146,147,148,149,150,151,152,153,154,155],"playwright skill","browser automation","flows","auto","access","Bash","website","ux","login","scripts","read","write","node","install","network","responsive",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":160,"sourceHtmlUrl":161,"categories":162,"keywords":164,"publishedAt":44},"01M71CY25GM939M6RES91QSG3T","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fsearch-retrieval-web-automation\u002Fofficial-reference\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fsearch-retrieval-web-automation\u002Fofficial-reference\u002Fweb-artifacts-builder\u002FSKILL.md",[163],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},[165,166,167,97,168,169,170,31,171,172,91,173,174,175,176,177,178,179,180,181],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":78,"licenseFileUrl":186,"sourceHtmlUrl":187,"categories":188,"keywords":198,"publishedAt":44},"01M71CXZB60QJJ1H4S3NN94WMZ","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fsearch-retrieval-web-automation\u002Fofficial-reference\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fsearch-retrieval-web-automation\u002Fofficial-reference\u002Ffrontend-design\u002FSKILL.md",[189,190,193],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":191,"categoryName":192,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":194,"categoryName":195,"taxonomyType":196,"taxonomyTypeDesc":197},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[91,199,200,170,201,202,203,89,204,205,174,118,167,39,176,206,177,207,208,28],"design","frontend design","ui design","generic","aesthetics","landing","pages","web ui","react components","examples",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":44},"01M71CVZ54WFBTVA7R16PFY1ZE","zarr-python","Chunked N-D arrays for cloud storage. Compressed arrays, parallel I\u002FO, S3\u002FGCS integration, NumPy\u002FDask\u002FXarray compatible, for large-scale scientific computing pipelines.","https:\u002F\u002Fgithub.com\u002Fstrmt7\u002Fai_skills_collection_benchmarked\u002Fblob\u002Fmain\u002Fincluded\u002Fskills\u002Fby-category\u002Fscience-research-data-analysis\u002Flatest-release-community\u002Fzarr-python\u002FSKILL.md",[],[216,217,218,219,220,221,222,223,224,31,225,226,227,228,229,230,231,232],"zarr python","python","zarr","arrays","Cloud Storage","scientific","storage","parallel","dask","numpy","gcs","s3","integration","scientific computing","cloud","scale","pipelines"]