https://dotagentsprotocol.com/
/agents.md — The project README for agents.
The root entry point. Describes what the project is, its domain language, architecture philosophy, and pointers to deeper context. Ideal size: one screen.
/system-prompt.md — Default system prompt injected into every agent.
Global behavioral rules. Coding style, conventions, what the agent must never do. Front-matter use: scope (global/agent-specific), priority
Rules that apply everywhere, always, with no exceptions.The things you'd say to every agent before they touch a single file. Think of it as the non-negotiables a senior dev would tape to a new hire's monitor.
Would I say this regardless of which agent is working?
If yes → system-prompt.md.
If it only matters in a specific context → ./agents/subagent/agent.md.
agents.md— what the project is. Facts, structure, glossary, layout. Descriptive.system-prompt.md— how to behave inside it. Rules, constraints, philosophy. Prescriptive. One is a map. The other is a rulebook.
Example:
# System Prompt
## Code style
- Angular modern control flow only: `@if`, `@for` — never `*ngIf`
- Standalone components, no NgModules
- RxJS imported as `import * as rx from 'rxjs'`
- Prefer signals for ids and booleans
## Philosophy
- Boring, obvious code is a feature
- Readability over cleverness — no clever abstractions
- Discuss architecture before implementing
## Never
- Hardcode colors outside the SCSS color maps
/skills/*/skill.md — Reusable capability definitions
Each subfolder = one skill. A skill is a capability an agent can invoke — like a function, but described in prose + examples. Agents reference skills by name.
Skills are reusable how-to knowledge: e.g. TS best practices, SCSS guidelines, theming guidelines.
Everything that answers "how do we do X here" is a skill.
Don't put them all in agents.md: use skills for this.
Examples:
/skills/write-tests/skill.md: Knows the testing framework, conventions, what to cover, what not to bother with./skills/db-migration/skill.md: Knows how to write a migration file, how to make it reversible, naming conventions, where it lives./skills/api-endpoint/skill.md: Knows the pattern: route → controller → service → repo. Auth middleware, error shapes, validation./skills/feature-flag/skill.md: How to gate code behind a flag, where flags are registered, how to clean one up after rollout./skills/logging/skill.md: What to log, at what level, what format, what must never be logged (PII, tokens)./skills/loading-states/skill.md: Skeleton vs. spinner vs. nothing, where the loading flag lives, what the component looks like during each async phase.
/agents/*/agent.md — Specialized agent definitions
Each agent has a role, knows which skills it can use, and gets extra context beyond the global system prompt.
Use skills for reusable how-to knowledge. Use agents for who handles what.
Typically, you'd have one "ui-agent" for everything — and create specialized agents if a specific domain requires specific instructions.
An AI would use the description: routing hint to choose which sub-agent to use.
The orchestrating AI reads all agent descriptions and picks the best match. That's why the description front-matter field matters — it's not for humans, it's for the router.
If you're not using an orchestrator and you're just prompting manually, you are the router. You just say "use filling-agent" and it loads that context.
Example:
/agents/
ui-agent/agent.md -- the default agent
calendar-agent/agent.md
device-agent/agent.md
Calendar agent works exclusively on the calendar widget and has its own memory:
---
id: calendar-agent
name: Calendar Agent
description: Calendar & scheduling feature developer
skills:
- rxjs-operator
- calendar-grid
- scss-theming
model: code-generation
memory: calendar-context.md
---
# Calendar Agent
You work exclusively on the multi-week calendar view and cassette/event display logic.
## Key files
- `src/app/calendar/calendar.component.ts` — main grid component
- `src/app/calendar/calendar.component.scss` — CSS Grid layout
- `src/app/core/operators/` — custom RxJS operators
## Layout rules
- Grid uses `repeat(7, minmax(0, 1fr))` + `min-width: 0` on children
- Row count driven by CSS custom property `--week-count`
- Cassettes span via `grid-column` / `grid-row`, never absolute positioning
## Live data
WebSocket updates forwarded through a Subject — never subscribe twice to the raw socket.
Another sub-agent may be configured to do a completely different task: e.g. code review or security audit:
---
id: code-reviewer
name: Code Reviewer
description: Reviews code for security
role: delegation-target
enabled: true
connection-type: internal
---
You are a code review specialist.
Focus on security vulnerabilities,
performance, and test coverage.
To make a sub-agent use instructions from another sub-agent, say this:
Also apply all instructions from
./agents/ui-agent/agent.md.
Or, alternatively, describe it as a skill.
Agent memories go into /memories/*.md:
/memories/*.md — Persistent agent memory
Long-lived facts an agent should always carry. Like sticky notes that survive across sessions. Agent front-matter points to relevant memory files.
This is something that typically agents manage themselves. But you can create files yourself, why not? They usually describe why we done something:
---
id: arch_001
title: Database Architecture
content: PostgreSQL with Drizzle ORM
importance: high
tags: database, architecture, orm
---
We chose PostgreSQL over MongoDB for
relational data integrity and complex
query support across billing.
/tasks/*/task.md — Predefined repeatable tasks
A task is a concrete job an agent can be asked to execute. Think of it as a prompt template with structured inputs.
Use case: When multiple people need to trigger the same agent job and you can't trust everyone to phrase it the right way. For a solo dev iterating fast, tasks are mostly overkill.
Example: Adding a new (something) all over the place when you need to make sure that multiple things align alright. The task exists to prevent the "I updated 3 of the 4 files" bug.
Example:
---
kind: task
id: daily-code-review
name: Daily Code Review
intervalMinutes: 60
enabled: true
runOnStartup: false
profileId: abc-123
---
Review all open pull requests and
summarize their status. Check for
any failing CI pipelines.
/models.json — Model routing config.
Maps tasks to models. Lets you assign expensive models to complex tasks, cheap/fast to simple ones. Example:
{
"default": "claude-sonnet-4-5",
"routing": {
"code-generation": "claude-opus-4-5",
"refactor": "claude-sonnet-4-5",
"explain": "claude-haiku-4-5",
"test-generation": "claude-sonnet-4-5",
"scss-fix": "claude-haiku-4-5"
}
}See also: MCP servers