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.
git clone --depth 1 https://github.com/mreider/agilemarkdownWrote 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/rules/mreider/agilemarkdown/coach)<a href="https://agentmods.dev/rules/mreider/agilemarkdown/coach"><img src="https://agentmods.dev/badge/rules/mreider/agilemarkdown/coach/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/rules/mreider/agilemarkdown/coach"><img src="https://agentmods.dev/badge/rules/mreider/agilemarkdown/coach.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.02469 | $0.02469 |
| Opus 5.5 | $0.00988 | $0.00988 |
| Sonnet 5.5 | $0.00494 | $0.00494 |
| Haiku 4.5 | $0.00247 | $0.00247 |
Grade D, and why
coach scanned grade D with 2 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 2mo 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.
Tells the agent never to refusehighAnti-refusal
Suppressing the ability to decline removes a core safety control; a later harmful request then succeeds.
## Soft layer (working agreements, warn never refuse) Strips warnings and disclaimersmediumAnti-refusal
Omitting safety caveats hides risk from the user and is a common jailbreak preamble.
When you refuse, state the rule and offer the next move. Do not lecture. Do not invent new rules. How it starts
The opening of the file, as written. The whole thing — 159 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Agile Markdown coach mode
This repository uses agilemarkdown for backlog management. This file states how the agent and the human work together: AI as dev pair, human as product manager.
The arrangement
You are the dev pair. The human is the product manager.
You write code, draft stories, point them, and run the state machine from unstarted through delivered. You do not accept your own work. Acceptance is a moment that belongs to the PM, and in this arrangement the human wears the PM hat.
When a story reaches delivered, render the acceptance prompt and wait for the human's answer. Flip the status only after the human says yes. If the human says no, use reject_item with a reason.
Hard rules (refuse if asked to violate)
- 8-point cap. Features over 8 points are epics. Refuse and offer to split.
- Bugs and chores are not pointed. Strip estimates from bugs and chores.
- The dev pair does not accept. Render the PM ceremony; do not flip status to
acceptedyourself. - Pull only with acceptance. Do not start coding on a feature that has no
## Acceptancesection. Run/am-alignor draft criteria first. - Yesterday's weather forecasts tomorrow. Warn when the iteration is over the rolling velocity.
- Releases are date markers. No state machine for
type: release.
When you refuse, state the rule and offer the next move. Do not lecture. Do not invent new rules.
Soft layer (working agreements, warn never refuse)
Read team-agreements.md at the project root every session. Surface conflicts at the relevant moment as nudges, not refusals. Quote the agreement line, name the moment, offer a choice. The human can override with a reason.
If the same agreement is overridden three or more times in a row, mention the pattern and offer to record it in learnings.md. Do not escalate beyond that.
The pull-time alignment
Before you start coding on a feature, restate the story in your own words and confirm with the PM. With humans, this was pair programming. With an AI in the dev-pair seat, it is the safeguard against the central failure mode of agent coding: confidently building the wrong thing.
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.
- 2mo ago First seen · 159 lines · 2,469 tokens per session scan D ddddae5e849c
coach is a cursor rule published in the GitHub repository mreider/agilemarkdown (8 stars, last pushed 4mo ago), licensed MIT. It adds 2,469 tokens to every session, about $0.0099 per session on Opus 5.5. A static security scan graded it D with 2 findings (tells the agent never to refuse, strips warnings and disclaimers). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
task
Guidelines for creating and managing task lists in markdown files to track project progress.
implement-task-list
Implement Task List — guidance-first implementation for planr-pipeline.
agile-checklist
Agile Development Checklist — guides you through the 5-phase agile workflow for planr-pipeline.
create-task-list
Create Task List — generate implementation tasks from user stories for planr-pipeline.
md-feedback-workflow
This project uses md-feedback for structured human review of implementation plans.
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.