Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/affectionatec/agentic-engineering/agents-md-templatenpx skills add affectionatec/agentic-engineering --skill agents-md-templategit clone --depth 1 https://github.com/affectionatec/agentic-engineeringWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00104 | $0.02430 |
| Opus 5 | $0.00052 | $0.01215 |
| Sonnet 5 | $0.00021 | $0.00486 |
| Haiku 4.5 | $0.00010 | $0.00243 |
Grade A, and why
agents-md-template scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 194 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AGENTS.md Template
Design principle:
AGENTS.mdis the single source of truth. Tool-specific files (CLAUDE.md, copilot-instructions.md, .cursor/rules/) all point here. — substratia.io
Quick Reference
| Use when | Bootstrapping a repo for AI-assisted dev; no AGENTS.md exists yet |
| Skip when | AGENTS.md already exists — edit in place; don't recreate |
| Output | AGENTS.md at repo root + one-line pointer files for each tool |
| Sequence | Step 0 — before any documentation chain work begins |
| Iron rule | One source of truth. CLAUDE.md / .cursor / copilot all point here. |
| Sibling skills | [[project-kickoff-prd]] · [[technical-specification]] · [[architecture-decision-record]] · [[implementation-plan]] · [[status-tracker]] · [[independent-verification]] · [[git-workflow]] |
Template
Copy everything below into your project root as
AGENTS.md, then fill in the brackets.
> **Stop. Read this entire file before doing anything.**
> This is the single source of truth for how we work on this project.
> Tool-specific files (CLAUDE.md, copilot-instructions.md, .cursor/rules/)
> all point here. Do not look for instructions elsewhere.
## 1. Project Identity
- **Name:** [Project Name]
- **One-liner:** [What this project does in one sentence]
- **Tech stack:** [e.g., Python 3.12 / FastAPI / Terraform / GitHub Actions]
- **Repo structure:**
## 2. Documentation Chain — Read Before You Code
This project uses a six-document chain. **Read them in order.**
| Doc | Path | Purpose | When to Read |
|-----|------|---------|-------------|
| **PRD** | `docs/prd.md` | What we're building and why | Before any feature work |
| **SPEC** | `docs/spec/*.md` | Precise technical contracts (API, data model, edge cases) | Before writing any code |
| **ADR** | `docs/adr/ADR-*.md` | Why we chose A over B — append-only, never rewrite | Before making architectural decisions |
| **IMPL PLAN** | `docs/plans/implementation-plan.md` | Milestones and step-by-step tasks | Before starting a task |
| **STATUS** | `docs/status.md` | Where we are right now — live progress | **First thing every session** |
| **VERIFICATION LOG** | `docs/verification-log.md` | Verdicts with evidence for every completed task — append-only | Before marking anything done; when auditing what "done" meant |
### Session Protocol
1. **Start of session:** Read `docs/status.md`. If the In-Flight Checkpoint is not `none`, the previous session crashed — recover from it. Otherwise the latest handoff log entry is your briefing.
2. **Before coding:** Read the SPEC for the module you're working on. Follow the contract exactly.
3. **Decision point:** Check `docs/adr/` before making any architectural choice. If no ADR covers it, flag it to the user.
4. **Documentation drift:** If anything decided in this session makes a fundamental document (PRD, SPEC, ADR, IMPL PLAN, this file) stale or contradicted — or the user proposes a new feature — flag it the moment it happens and propose the update. **Never edit a fundamental document without the user's explicit approval.** Route the change through the chain before writing code.
5. **After each completed task:** Checkpoint `docs/status.md` (In-Flight Checkpoint + module table). Push the task branch and open a draft PR, then request independent verification — the task stays at 🔍 until a verifier with fresh context returns PASS. Never mark your own work ✅; never merge your own PR.
6. **End of session:** Update `docs/status.md` — module table, header block, append a handoff log entry, reset the In-Flight Checkpoint to `none`.
---
## 3. Coding Conventions
- **Language:** [e.g., Python — strict typing, all functions annotated]
- **Formatter:** [e.g., ruff format]
- **Linter:** [e.g., ruff check --fix]
- **Test framework:** [e.g., pytest]
- **Test command:** [e.g., `pytest tests/ -v`]
- **Build command:** [e.g., `docker compose build`]
- **Pre-commit checks:** [e.g., `ruff check && ruff format --check && pytest`]
---
## 4. Architecture Constraints (Quick Reference)
> Full rationale in `docs/adr/`. **Do not relitigate** — raise changes with the user.
- [e.g., Cloud-neutral orchestration; cloud-specific only at the provider layer (ADR-001)]
- [e.g., All network calls isolated behind a single function for offline testability (ADR-003)]
- [e.g., Point-in-time correctness: never read data filed after the decision date (ADR-005)]
---
## 5. Boundaries — What You Must NOT Do
- **Do not create files outside the defined structure** without asking.
- **Do not install new dependencies** without asking.
- **Do not modify ADRs.** They are append-only. Supersede with a new ADR if needed.
- **Do not edit a fundamental document** (PRD, SPEC, ADR, IMPL PLAN, AGENTS.md) without the user's explicit approval — propose the change, then wait for the nod.
- **Do not skip the status update.** Every session ends with a handoff log entry.
- **Do not guess when the spec is ambiguous.** Ask the user.
- **Do not grade your own work.** Marking a task ✅ requires an independent verifier's PASS, not your claim.
- **Do not delete, skip, or weaken tests to make a run pass.** The suite count only goes up (test ratchet). A failing test is information, not an obstacle.
- **Do not redefine "done" mid-task.** Acceptance criteria are locked when the task starts; changes require the user's explicit approval.
- **Do not commit directly to main.** Every task gets its own branch and ships as a draft PR (one task = one PR).
- **Do not merge your own PR.** Merge requires the verifier's PASS and a human who has read the diff.
---
## 6. Verification — Self-Check, Then Independent Gate
### 6.1 Producer self-check (necessary, never sufficient)
Before claiming a task is built:
1. **Lint clean:** `[lint command]` exits 0
2. **Tests pass:** `[test command]` — report exact count (e.g., "142/142 pytest")
3. **No regressions:** all pre-existing tests still pass
4. **Test ratchet holds:** suite count ≥ previous baseline — no tests deleted or skipped
5. **Spec compliance:** every acceptance criterion in the relevant spec is met
6. **Status updated:** `docs/status.md` reflects what you just did
### 6.2 Independent verification (the gate)
- A verifier with **fresh context** — sub-agent or fresh session, never this conversation — re-runs the task's done condition exactly as written in the SPEC / IMPL PLAN and appends a verdict with evidence to `docs/verification-log.md`.
- Only a PASS verdict moves the task from 🔍 to ✅ in STATUS.
- Three consecutive FAILs on the same task → stop and escalate to the user. Do not loop indefinitely; do not weaken criteria to converge.
### 6.3 Human gate (before merge)
- A human reads the diff and can explain the change in their own words before it merges. Code you can't explain is comprehension debt — and it compounds.
- The verification log entry is the review digest: what changed, what was proven, what the risks are.
---
## Full Chain Summary
```
Agent Start
│
▼
┌─────────────────────────────────────────────────────────┐
│ CLAUDE.md / copilot-instructions.md / .cursorrules │
│ → "Read AGENTS.md. It's the source of truth." │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ AGENTS.md ← 🎯 The one file that grabs attention │
│ │
│ §1 Project Identity (what is this?) │
│ §2 Documentation Chain (where to find context) │
│ → PRD → SPEC → ADR → IMPL PLAN → STATUS │
│ §3 Coding Conventions (how to write code) │
│ §4 Architecture Constraints (what's already decided) │
│ §5 Boundaries (what NOT to do) │
│ §6 Verification (self-check → independent gate) │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ docs/status.md ← Agent first move │
│ "Read the latest handoff log. That's your briefing." │
└────────────────────────┬────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────┐
│ docs/spec/*.md ← must read before coding │
│ "Follow the contract. Ambiguity = ask, don't guess." │
└────────────────────────┬────────────────────────────────┘
▼
Build the task.
│
▼
┌─────────────────────────────────────────────────────────┐
│ Independent verification ← fresh context, not you │
│ Verifier re-runs the done condition, appends verdict │
│ to docs/verification-log.md. Only PASS marks ✅. │
└────────────────────────┬────────────────────────────────┘
▼
Checkpoint docs/status.md. Next task or hand off.
```
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 194 lines · 104 tokens per session scan A 0e8c0aaaf511
agents-md-template is a skill published in the GitHub repository affectionatec/agentic-engineering (4 stars, last pushed 2mo ago), licensed MIT. It adds 104 tokens to every session and 2,430 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
vibe-to-agentic-framework
The conceptual framework behind the presentation — what "Vibe Coding to Agentic Engineering" means, why the journey is structured the way it is, and how every slide fits the narrative arc.
alignfirst-developer-openclaw-playbook
Operating-instructions dispatcher for an AlignFirst Developer running on OpenClaw. Routes every user message by surface — thread → working session, channel/DM → channel handling — and carries the global rules.
al
Execute the AlignFirst AAD protocol.
weather-fetcher
Instructions for fetching current weather temperature data for Dubai, UAE from Open-Meteo API.
time-skill
Display the current time in Pakistan Standard Time (PKT, UTC+5). Use when the user asks for the current time, Pakistan time, or PKT.
autopilot
Full autonomous execution from idea to working code.