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 skills add niels-emmer/myace --skill agent-design-principlesgit clone --depth 1 https://github.com/niels-emmer/myaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/niels-emmer/myace/agent-design-principles)<a href="https://agentmods.dev/skills/niels-emmer/myace/agent-design-principles"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/agent-design-principles/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/niels-emmer/myace/agent-design-principles"><img src="https://agentmods.dev/badge/skills/niels-emmer/myace/agent-design-principles.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00034 | $0.00749 |
| Opus 5 | $0.00017 | $0.00375 |
| Sonnet 5 | $0.00007 | $0.00150 |
| Haiku 4.5 | $0.00003 | $0.00075 |
Grade A, and why
Agent Design Principles 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 10d 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 — 32 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose
Agent/prompt quality tends to erode the same way code quality does when there's no checklist forcing a second look: an agent persona quietly grows to cover more than it should, context accumulates instead of getting curated, and failures get retried with the same full error dump instead of a compacted summary. This skill exists to catch that drift when authoring or revising an agent, skill, or command — for this repo's own artifacts, or for a target repo an ai-engineer/prompt-engineer is working in.
It draws specific, named ideas from 12-factor-agents (humanlayer, Apache-2.0) — cited individually below, not reproduced wholesale; read the source for the full essays behind each one.
When to use it
Before adding a new agent persona or skill, before letting an existing one grow a new responsibility, and when designing how multiple agents hand work to each other (an orchestrator pattern, a pipeline of specialist agents).
The checklist
- Small, focused agents — Does this persona do one job well, with a clearly stated permission posture (what it does freely, what it never does)? If a persona's responsibility list is growing past what fits in a short paragraph, it's probably two personas.
- Own your control flow — Is the sequence between stages/agents explicit (a named handoff, like this repo's
orchestrator→builder→verifierpattern), rather than an open-ended loop hoping the model figures out when to stop or what to do next? - Own your context window — For each stage, is it clear what context it actually needs? Passing everything by default (full history, every file touched so far) degrades output quality as much as passing too little.
- Compact errors into context — When a step fails and gets retried, is the failure summarized (what was tried, what broke, what's already ruled out) rather than re-fed as a raw stack trace or full tool output on every attempt?
- Unify execution state — Is task progress tracked in one place (e.g. this repo's
plan-tracking/memory-systemskills) rather than scattered across an agent's implicit memory of the conversation, which doesn't survive a session boundary? - Natural language to concrete action — Are instructions phrased as checkable, concrete steps ("run the test suite and quote the result") rather than vague goals ("make sure it's tested")? A step that can't be verified as done or not-done will eventually be skipped.
- Resumability — If this session ended right now, could a fresh session pick up correctly from persisted state (memory files, task tracking) rather than needing the prior conversation's context to make sense of where things stand?
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.
- 10d ago First seen · 32 lines · 34 tokens per session scan A a27115593db3
Agent Design Principles is a skill published in the GitHub repository niels-emmer/myace (1 stars, last pushed 3d ago), licensed MIT. It adds 34 tokens to every session and 749 once invoked, about $0.0002 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
loom-plan-writer
REQUIRED skill for creating Loom execution plans.
loom-react
Modern client-side React development patterns.
loom-database-design
Database schema and data model design for relational, NoSQL, time-series, and warehouse systems.
loom-event-driven
Event-driven architecture patterns including message queues, pub/sub, event sourcing, CQRS, and sagas.
loom-python
Python language expertise for idiomatic, production-quality code.
loom-typescript
TypeScript language expertise for type-safe, production-quality code.