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/phuonghx/aim-cli/ears-acceptance-criterianpx skills add phuonghx/aim-cli --skill ears-acceptance-criteriagit clone --depth 1 https://github.com/phuonghx/aim-cliWrote 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/phuonghx/aim-cli/ears-acceptance-criteria)<a href="https://agentmods.dev/skills/phuonghx/aim-cli/ears-acceptance-criteria"><img src="https://agentmods.dev/badge/skills/phuonghx/aim-cli/ears-acceptance-criteria.svg" alt="Measured on agentmods" 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 | $0.00106 | $0.01100 |
| Opus 5 | $0.00053 | $0.00550 |
| Sonnet 5 | $0.00021 | $0.00220 |
| Haiku 4.5 | $0.00011 | $0.00110 |
Grade A, and why
ears-acceptance-criteria 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 4d 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 — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
EARS Acceptance Criteria
One criterion, one behavior, one test.
EARS (Easy Approach to Requirements Syntax) constrains free-text requirements to a few keyword-driven templates. The result is unambiguous, reviewable, and maps 1:1 to a test case.
The five patterns
| Pattern | Keyword shape | Use for |
|---|---|---|
| Ubiquitous | THE SYSTEM SHALL <response>. |
Always-true invariants |
| Event-driven | WHEN <trigger> THE SYSTEM SHALL <response>. |
A reaction to an event |
| State-driven | WHILE <state> THE SYSTEM SHALL <response>. |
Behavior during a state |
| Unwanted behavior | IF <condition> THEN THE SYSTEM SHALL <response>. |
Errors, faults, abuse |
| Optional feature | WHERE <feature included> THE SYSTEM SHALL <response>. |
Behavior gated on a feature/config |
Keywords combine. Compound: WHILE <state> WHEN <trigger> THE SYSTEM SHALL <response>. Keep SHALL (the obligation) in every line.
Template
<pattern keywords> THE SYSTEM SHALL <single observable response>
[within <measurable bound>].
- Trigger / condition / state — the precondition, in user-visible terms.
- SHALL — exactly one behavior you can observe and assert.
- Bound (optional) — a number a test can check (time, count, size, %).
One atomic, verifiable behavior per criterion
- If a line contains "and" joining two behaviors, split it into two.
- If you can't picture the assertion, it's too vague — rewrite it.
- Responses must be observable (output, state change, status code), not internal ("the system processes the data correctly").
- Prefer measurable bounds over adjectives ("fast", "large", "secure").
Good vs. bad
| ❌ Bad | ✅ Good (EARS) |
|---|---|
| The system should be fast. | WHEN a user submits the form THE SYSTEM SHALL return a response within 500ms. |
| Handle invalid input gracefully. | IF the email field is malformed THEN THE SYSTEM SHALL reject the submission and show a field-level error. |
| Users can log in and see their dashboard. | WHEN valid credentials are submitted THE SYSTEM SHALL authenticate the user. (then a second criterion for the dashboard) |
| The app supports offline mode. | WHERE offline mode is enabled THE SYSTEM SHALL queue writes and sync them WHEN connectivity returns. |
| Keep the session secure. | WHILE a session is idle for 15 minutes THE SYSTEM SHALL log the user out. |
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.
- 4d ago First seen · 94 lines · 106 tokens per session scan A 66bb23361ad4
ears-acceptance-criteria is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 2mo ago), licensed MIT. It adds 106 tokens to every session and 1,100 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
hs-release
Cut a core Hindsight release (vX.Y.Z) and open the changelog + blog PR. Use when asked to cut/start a release, bump the version, or publish a new Hindsight version.
research-repository
Build a repository that makes findings findable, reusable, and cumulative across teams. Use when the same research keeps getting redone. For synthesising one study, use affinity-diagram.
form-design
Design a form end to end — field order, grouping, validation, and completion. Use when the artifact is a form. For product-wide error strategy use error-handling-ux; for first-run signup use onboarding-design.
peak-end-rule
Apply the Peak-End Rule — a flow is remembered by its most intense moment and its last. Use when designing completion, celebration, or cancellation moments. For sustaining engagement mid-flow, use zeigarnik-effect.
law-of-common-region
Apply the Law of Common Region — a shared container, background, or border groups elements regardless of spacing. Use when grouping must survive a tight layout. For grouping by spacing alone, use law-of-proximity.
presentation-deck
Structure a design presentation for a specific audience and decision. Use when presenting internally. For a portfolio narrative use case-study; for the written argument use design-rationale.