agents-md
Scannednpx machina-cli add skill jmerta/codex-skills/agents-md --openclawAGENTS.md builder
Goal
Add lightweight, scoped guidance for an AI agent (and humans) by placing AGENTS.md files at key directory boundaries:
- root: cross-domain guidance + a module map (for monorepos)
- nested: tech-specific instructions for each component/module
- optional: feature maps at the module level
Optimize for concise and precise instructions (short bullets, minimal prose). Link to docs for depth.
Inputs to ask for (if missing)
- Is this a monorepo (multiple independently-built modules) or a single project?
- Repo layout: where backend, frontend, docs, infra live; list the major modules/subprojects.
- Cross-domain workflows to document (e.g., frontend calling backend API, auth flow, shared types, local dev).
- If you want feature maps: top 5-15 user-facing features (names) and which module owns them.
- Any rules about MCP usage to capture in root AGENTS.md (allowed servers/tools, safety constraints).
- Any hard rules (do not touch X, required commands, style rules).
Where to put AGENTS.md (heuristics)
Create AGENTS.md at:
- repo root (global rules + module map + cross-domain workflows)
- each major component/module root (e.g.,
backend/,frontend/,docs/,infra/) - any subdirectory that has different conventions, ownership, or high risk (payments, auth, data migrations)
Avoid placing AGENTS.md too deep unless there is a real boundary; too many files become noise.
Workflow (checklist)
- Inventory the repo
- List top-level directories and build files (Gradle/Maven, Node/Next, docs site).
- Identify the natural "component roots" and any critical submodules.
- Draft root
AGENTS.md- State global rules only (things that apply everywhere).
- If monorepo: add a module/subproject map (not a feature map) and links to each nested AGENTS.md.
- Keep tech-specific instructions out of root; push them into the owning module's AGENTS.md.
- Docs: do not open/read
docs/by default; consult only when asked or required. - Add cross-domain workflows (how modules connect): frontend <-> backend API, auth/session, contract location (OpenAPI/GraphQL), "run together" local dev.
- Add cross-repo verification guidance: where to run per module + prereqs; quiet first run; re-run narrowed failures with verbose logs when debugging.
- Draft nested AGENTS.md per component
- Put tech-specific instructions in the module that owns them:
- Backend: how to run, test, migrate DB; key modules and entrypoints.
- Frontend: how to run, build, test; env vars; key routes/areas.
- Docs: docs structure, where to add ADRs/runbooks, how to preview/build docs.
- Put tech-specific instructions in the module that owns them:
- Build maps (as needed)
- If monorepo: module map goes in root (use
references/module-map-format.md). - Feature maps should live in the owning module AGENTS.md (use
references/feature-map-format.md).
- If monorepo: module map goes in root (use
- Verify consistency
- Ensure guidance does not conflict between parent/child scopes.
- Keep each AGENTS.md short and actionable; move long detail into docs under
docs/.
Templates
Use these templates:
- Root + module AGENTS.md:
references/agents-template.md - Module map format:
references/module-map-format.md - Feature map table format (per module):
references/feature-map-format.md - Suggested
docs/layout (Spring + Next):references/docs-structure.md
Deliverable
Provide:
- Root
AGENTS.md(if requested) with module map and cross-domain workflows. - Nested
AGENTS.mdper component/module with tech-specific guidance. - Optional feature map tables per module (if requested).
- A list of files created/updated and any open questions.
Overview
This skill creates or updates AGENTS.md files at repo roots and module levels to document scoped conventions, monorepo module maps, cross-domain workflows, and optional per-module feature maps. It emphasizes concise, actionable guidance and links to depth in templates. Use it when AGENTS.md, nested agent instructions, or module/feature maps are requested.
How This Skill Works
The workflow inventories the repository, drafts a root AGENTS.md with global rules and a module map, and then creates nested AGENTS.md files for each component. If requested, it adds optional feature maps inside the owning module AGENTS.md and references the provided templates to ensure consistency across the repo.
When to Use It
- When you ask for AGENTS.md at the repo root to establish global rules and a module map.
- When you need per-module guidance (backend/frontend/docs/infra).
- When a monorepo requires a module/feature map for ownership and entrypoints.
- When documenting cross-domain workflows (frontend <-> backend, auth, APIs).
- When you want to outline hard rules (MCP usage, safety constraints) in root guidelines.
Quick Start
- Step 1: Inventory repo structure and list top-level components.
- Step 2: Draft root AGENTS.md with global rules and a monorepo module map.
- Step 3: Create per-module AGENTS.md with tech-specific guidance and optionally add feature maps.
Best Practices
- Ask clarifying questions about monorepo structure and module ownership before drafting.
- Keep root AGENTS.md concise; defer detailed instructions to module AGENTS.md.
- Use the provided templates for consistency (root and module maps, feature maps).
- Cross-reference modules with links to nested AGENTS.md and docs.
- Validate for conflicts between parent and child scopes and keep content actionable.
Example Use Cases
- A monorepo with backend/, frontend/, and docs/ where root AGENTS.md defines the global map and cross-domain flows.
- Module AGENTS.md for backend covering run/test/migrate and key entrypoints.
- Module AGENTS.md for frontend focusing on run/build/env vars/routes.
- Feature maps showing features like 'User login' mapped to backend auth and frontend login flow.
- Docs module with ADRs/runbooks; root AGENTS.md references docs-specific guidelines without deep content.