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.
Generates AGENTS.md files for repository folders with build commands, testing instructions, and coding boundaries when missing.
npx claudepluginhub linehaul-ai/linehaulai-claude-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
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.
AGENTS.md complements README.md. README is for humans; AGENTS.md is for coding agents.
AGENTS.md in the current directory, then walk up the treeAGENTS.md that takes precedence over the root one.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)This is the single most important rule.
NEVER overwrite an existing AGENTS.md.
Before generating for ANY folder:
# Check if AGENTS.md already exists
ls AGENTS.md 2>/dev/null
"AGENTS.md already exists at <path> — skipping"Identify which folders should have an AGENTS.md:
/)wiki/) — if generated by deep-wiki (has package.json with VitePress)tests/, src/, lib/, app/, api/packages/*/, apps/*/, services/*/package.jsonpyproject.tomlCargo.toml*.csproj / *.fsprojgo.modpom.xml / build.gradle.github/ — only if it contains workflows or actionsnode_modules/, .git/, dist/, build/, out/, target/vendor/, .venv/, venv/, __pycache__/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.
Agents reference these constantly. Use exact commands with flags, not just tool names.
## 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 sectionMakefile → targetspyproject.toml → [tool.poetry.scripts] or [project.scripts]Cargo.toml → standard cargo commands.github/workflows/*.yml, Jenkinsfile, .gitlab-ci.yml## 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:
## Project Structure
src/
├── api/ # FastAPI route handlers
├── models/ # Pydantic data models
├── services/ # Business logic
└── utils/ # Shared utilities
tests/ # Mirrors src/ structure
Include:
src/main.py, src/index.ts)One real code example beats three paragraphs of description.
## 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).
Use a three-tier system:
## Boundaries
- ✅ **Always do:** Run tests before committing. Write tests for new features. Use type hints.
- ⚠️ **Ask first:** Adding new dependencies. Changing database schemas. Modifying CI/CD configs. Changing public API signatures.
- 🚫 **Never do:** Commit secrets or credentials. Modify `vendor/` or `node_modules/`. Push directly to `main`. Delete migration files.
Tailor boundaries to the project:
When generating an AGENTS.md for a specific folder:
ls <folder>/AGENTS.md 2>/dev/null
If it exists, stop. Report and move to the next folder.
Identify:
Extract real commands and settings from:
package.json scriptsMakefile / Justfile targetspyproject.toml scripts and tool configsCargo.toml metadata.github/workflows/*.yml build/test stepsdocker-compose.yml service definitions.eslintrc, ruff.toml, rustfmt.toml)Read 3-5 source files to identify:
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.
Before writing the file:
<your-project> or 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
Omit any section that doesn't apply. A 20-line AGENTS.md with real commands beats a 200-line one with generic filler.
/AGENTS.md)Covers the entire project:
tests/AGENTS.md)Covers that specific subfolder:
cd tests && pnpm test)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):
# 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.
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:
# 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.
| 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 |
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.