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 rules/hundia/autospec/sprint-rungit clone --depth 1 https://github.com/Hundia/autospecWrote 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/hundia/autospec/sprint-run)<a href="https://agentmods.dev/rules/hundia/autospec/sprint-run"><img src="https://agentmods.dev/badge/rules/hundia/autospec/sprint-run.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.00000 | $0.00650 |
| Opus 5 | $0.00000 | $0.00325 |
| Sonnet 5 | $0.00000 | $0.00130 |
| Haiku 4.5 | $0.00000 | $0.00065 |
Grade A, and why
sprint-run 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 today.
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.
Sprint Run
Execute a full sprint from start to finish. Follow all six phases in order.
Phase 1: Sprint Briefing
- Read
specs/backlog.mdto identify the current sprint and its tickets - List all tickets with their statuses and dependencies
- Determine execution order based on dependencies
- Identify which spec files and docs are relevant
- Read
agents/sprint-X-brief.mdif it exists for additional context
Output: Ordered list of tickets to execute with dependency notes.
Phase 2: Ticket Execution
For each ticket in dependency order:
- Set ticket status to 🔄 in
specs/backlog.md - Read the relevant spec and doc files
- Implement the change following project conventions
- Run appropriate tests (see QA table below)
- Commit with format:
type(scope): description
QA by Change Type
| Type | Verification |
|---|---|
| Docs/config | Review accuracy |
| Bug fix | Reproduce → fix → verify → test |
| CLI change | cd cli && npm run build && npm test |
| Viewer change | cd viewer && npm run build |
| New feature | Full tests + new test cases |
Do not proceed to the next ticket if the current one fails QA.
Phase 3: QA Verification
After all tickets are implemented:
- Run the full test suite:
cd cli && npm test - Build all artifacts:
cd cli && npm run build && cd ../viewer && npm run build - Check for regressions in related features
- Verify each ticket's acceptance criteria is met
Phase 4: Documentation Update
For each completed ticket:
- Update relevant
docs/files - Add implementation notes if the approach deviated from the plan
- Update
specs/backlog.mdwith completion notes
Phase 5: Sprint Close
- Set all completed tickets to ✅ in
specs/backlog.md - Create
sprints/sprint-X/summary.mdwith:- Sprint goal
- Tickets completed (with brief descriptions)
- Tickets deferred (with reasons)
- Key decisions made
- Known issues or follow-ups
Phase 6: Final Report
Present a summary:
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.
- today First seen · 94 lines · 0 tokens per session scan A 0a36e371d8c1
sprint-run is a cursor rule published in the GitHub repository Hundia/autospec (4 stars, last pushed 2mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 650 tokens. 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-09-03.
Other cursor rules, from other repositories
development-workflow
AAMAD modular development workflow for context-aware agent coordination.
feedback-enhanced
Enhanced feedback mechanism with 1-hour timeout - 增强反馈机制，1小时超时.
project-onboarding-rule
Automatically onboards existing projects into the AI-driven development workflow.
linear-in-review
After finishing a Linear issue, set its status to In Review (never Done).
sprint-planning
BMAD BMM Agent: sprint-planning.
generate-tasks
Understanding our task list for our project or how to make one from a PRD.