Getting it into your agent
This one installs as part of its plugin. Adding the marketplace and installing the plugin brings it with everything else the plugin ships.
/plugin marketplace add Peeyushmeher/agent-agile/plugin install agent-agileWrote 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/peeyushmeher/agent-agile/aa-execute-epic)<a href="https://agentmods.dev/skills/peeyushmeher/agent-agile/aa-execute-epic"><img src="https://agentmods.dev/badge/skills/peeyushmeher/agent-agile/aa-execute-epic/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/peeyushmeher/agent-agile/aa-execute-epic"><img src="https://agentmods.dev/badge/skills/peeyushmeher/agent-agile/aa-execute-epic.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.00035 | $0.01516 |
| Opus 5 | $0.00017 | $0.00758 |
| Sonnet 5 | $0.00007 | $0.00303 |
| Haiku 4.5 | $0.00003 | $0.00152 |
Grade A, and why
aa-execute-epic 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 9d 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 — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.
aa-execute-epic
Resolve the Agent-Agile playbook root: use the first of these that exists — (1) ${CLAUDE_PLUGIN_ROOT}/playbooks, (2) ./.claude/agent-agile/playbooks, (3) ./.agents/agent-agile/playbooks, (4) ~/.claude/agent-agile/playbooks, (5) ~/.agents/agent-agile/playbooks, (6) ./playbooks.
Read playbooks/execution.md sections "Wave 0 — contracts", "Pre-flight", "Wave 1 — stories", "Wave 2 — integrate", "Verification", and "The review gate", and follow them exactly; do not re-derive or improvise the sequence.
This skill stays lean: it dispatches subagents and collects their output. It never writes application code itself.
Wiring
- Wave 0 — contracts. Spawn a fresh
aa-contractorsubagent with the model configured for the smart tier in.planning/CONFIG.md. Give it every story card'sContracts consumedfield. It writes.planning/epics/EPIC-NN/CONTRACTS.md. Once written, treat it as frozen — do not let any later step edit it. - Pre-flight. Both checks must pass before Wave 1 launches:
- Run the collision check:
node <playbook-root>/../scripts/collision-check.js <epic-dir>, where<playbook-root>is the playbook root resolved above (in a source checkout of this repo that is simplynode scripts/collision-check.js <epic-dir>). A clean run exits 0 with{"ok":true}. A collision exits 1 with a JSON report naming every contested file and the stories that claim it. On a collision, refuse to launch Wave 1 — report the exact colliding files and stories, and send the epic back to slicing so the shared file moves intoCONTRACTS.mdor the stories get merged. - Read
.planning/PREREQS.md. Every row must beverified, ordonein the specific case whereverifiedisn't actually checkable. Run any stated verification command now — don't trust the checkbox. Apendingrow, or adonerow whose verification command fails, blocks launch: stop and treat it exactly like the missing-prerequisite circuit breaker inplaybooks/execution.md"Circuit breakers" rather than pushing forward. - Print the readiness dashboard from
playbooks/execution.md"Pre-flight" — the gate table (contracts pinned, collisions, prerequisites, graders on every card, control-set size) and its CLEARED/BLOCKED verdict — before dispatching anything. Any ✗ row is the refuse behavior above; the dashboard renders the decision, it never softens it.
- Run the collision check:
- Wave 1 — stories. Spawn one fresh
aa-workersubagent per story card, in parallel, each with the model configured for the cheap tier in.planning/CONFIG.md. Give each worker exactly two inputs — its own story card andCONTRACTS.md— nothing else: no other story's card, no wider exploration mandate. Each worker builds against itsFiles it ownslist, runs its own acceptance check, and writes.planning/epics/EPIC-NN/stories/SN.report.mdas a typed report fromplaybooks/templates/REPORT.md. A failed check starts the worker's bounded repair loop — fix and re-run, up to 3 repair rounds within the same dispatch; only an exhausted loop reportsFAIL, and that story is flagged and not merged. - Wave 2 — integrate. Spawn a fresh
aa-integratorsubagent with the model configured for the smart tier in.planning/CONFIG.md. It parses everySN.report.md's typed fields (flagging mechanically: FAIL status, files touched outside ownership, deviations, contract change requests), wires the cross-story seams, runs the epic-level acceptance check (the demo sentence, exercised for real — with up to 3 seam-repair rounds on failures it owns), runs every row of.planning/CONTROL.mdwhen the file exists, writesDEMO.mdandLEARNINGS.md, flips the epic'sROADMAP.mdrow, and updatesSTATE.md. Any flagged story from Wave 1 is its problem to resolve or note inLEARNINGS.md— never quietly dropped from the merge. - Verification. Spawn a fresh
aa-verifiersubagent with the model configured for the smart tier in.planning/CONFIG.md— someone who wrote none of the epic's code. It checks whether the demo sentence is actually true, re-runs acceptance checks rather than trusting the reports, pokes the edge cases inDEMO.md's "what to look for" section, and returns a plain verdict: pass, or a redo-list of specific findings. - The review gate. Present
DEMO.mdand the verifier's verdict at the gate, per the mode set in.planning/CONFIG.md'sgatefield (interactive/checkpoint/full-auto — seeplaybooks/execution.md"Autopilot" for what each mode means for who reads the gate). The gate has exactly three outcomes:- Approve — the epic is done. Append its epic-level check to
.planning/CONTROL.md(create fromplaybooks/templates/CONTROL.mdon first approval). - Redo — convert every tip and finding into a new, concrete acceptance check on the specific story or stories it affects, re-run Wave 1 for those stories and Wave 2 to re-integrate, then verify again. If the redo-list qualifies for the scoped redo in
playbooks/execution.md"The review gate" (every finding file-specific, all files owned by one story, contracts untouched), take that path instead: one cheap-tier fix worker plus re-verification, no wave re-run — one scoped attempt only, then escalate to the full redo. - Replan — send the epic back to slicing entirely; the roadmap after it gets re-examined.
- Approve — the epic is done. Append its epic-level check to
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.
- 9d ago First seen · 39 lines · 35 tokens per session scan A 5595637e311d
aa-execute-epic is a skill published in the GitHub repository Peeyushmeher/agent-agile (3 stars, last pushed 1mo ago), licensed MIT. It adds 35 tokens to every session and 1,516 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
project-manager
This skill has been upgraded with agentic AI capabilities, OKR/KPI integration patterns, and async-first workflows based on 2026 PM best practices research.
team-okrs
An OKR tracking page for a quarter. OKRs, or objectives and key results, are goals paired with measurable results.
product-frameworks
Product management frameworks for business cases, market analysis, strategy, prioritization, OKRs/KPIs, personas, requirements, and user research. Use when building ROI projections, competitive analysis, RICE scoring, OKR trees, user personas, PRDs, or usability testing plans.
gr-product-dev-ops
🇺🇸 Your dev team ships features nobody asked for while user-reported bugs pile up for months. Operations blames engineering for ignoring users; engineering blames operations for not understanding technical constraints. This gives you the complete Product × Engineering × Operations alignment SOP — from unified…
derive-capacity
Work out how many points a week each person on the aeman board actually gets through, from the cards they have closed, and set it as their capacity after the lead confirms. Use when a team lead asks about throughput, weekly capacity, how much a person or a team can take, or wants the numbers over the columns filled in.
size-cards
Size the unsized cards of a team or a person on the aeman board — S/M/L/XL by a fixed rubric, written back through the aeman MCP after the lead confirms. Use when a team lead asks to estimate, size or weigh cards, or before a planning meeting.