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/kryptobaseddev/cleoWrote 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/commands/kryptobaseddev/cleo/complete-milestone)<a href="https://agentmods.dev/commands/kryptobaseddev/cleo/complete-milestone"><img src="https://agentmods.dev/badge/commands/kryptobaseddev/cleo/complete-milestone/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/commands/kryptobaseddev/cleo/complete-milestone"><img src="https://agentmods.dev/badge/commands/kryptobaseddev/cleo/complete-milestone.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.00016 | $0.01134 |
| Opus 5.5 | $0.00006 | $0.00454 |
| Sonnet 5.5 | $0.00003 | $0.00227 |
| Haiku 4.5 | $0.00002 | $0.00113 |
Grade A, and why
gsd:complete-milestone 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 1mo 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.
Copies of this mod
8 near-identical copies found in the catalogue:
- gsd:complete-milestone — 94% identical, 27 lines differ
- gsd:complete-milestone — 94% identical, 16 lines differ
- gsd:complete-milestone — 94% identical, 16 lines differ
- gsd:complete-milestone — 94% identical, 4 lines differ
- gsd:complete-milestone — 94% identical, 4 lines differ
- gsd:complete-milestone — 94% identical, 16 lines differ
- gsd-complete-milestone — 91% identical, 13 lines differ
- gsd-complete-milestone — 89% identical, 21 lines differ
How it starts
The opening of the file, as written. The whole thing — 137 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Purpose: Create historical record of shipped version, archive milestone artifacts (roadmap + requirements), and prepare for next milestone. Output: Milestone archived (roadmap + requirements), PROJECT.md evolved, git tagged.
<execution_context> Load these files NOW (before proceeding):
- @/tmp/pomodoro-bench/gsd/.claude/get-shit-done/workflows/complete-milestone.md (main workflow)
- @/tmp/pomodoro-bench/gsd/.claude/get-shit-done/templates/milestone-archive.md (archive template) </execution_context>
User input:
- Version: {{version}} (e.g., "1.0", "1.1", "2.0")
Follow complete-milestone.md workflow:
-
Check for audit:
- Look for
.planning/v{{version}}-MILESTONE-AUDIT.md - If missing or stale: recommend
/gsd-audit-milestonefirst - If audit status is
gaps_found: recommend/gsd-plan-milestone-gapsfirst - If audit status is
passed: proceed to step 1
## Pre-flight Check {If no v{{version}}-MILESTONE-AUDIT.md:} ⚠ No milestone audit found. Run `/gsd-audit-milestone` first to verify requirements coverage, cross-phase integration, and E2E flows. {If audit has gaps:} ⚠ Milestone audit found gaps. Run `/gsd-plan-milestone-gaps` to create phases that close the gaps, or proceed anyway to accept as tech debt. {If audit passed:} ✓ Milestone audit passed. Proceeding with completion. - Look for
-
Verify readiness:
- Check all phases in milestone have completed plans (SUMMARY.md exists)
- Present milestone scope and stats
- Wait for confirmation
-
Gather stats:
- Count phases, plans, tasks
- Calculate git range, file changes, LOC
- Extract timeline from git log
- Present summary, confirm
-
Extract accomplishments:
- Read all phase SUMMARY.md files in milestone range
- Extract 4-6 key accomplishments
- Present for approval
-
Archive milestone:
- Create
.planning/milestones/v{{version}}-ROADMAP.md - Extract full phase details from ROADMAP.md
- Fill milestone-archive.md template
- Update ROADMAP.md to one-line summary with link
- Create
-
Archive requirements:
- Create
.planning/milestones/v{{version}}-REQUIREMENTS.md - Mark all v1 requirements as complete (checkboxes checked)
- Note requirement outcomes (validated, adjusted, dropped)
- Delete
.planning/REQUIREMENTS.md(fresh one created for next milestone)
- Create
-
Update PROJECT.md:
- Add "Current State" section with shipped version
- Add "Next Milestone Goals" section
- Archive previous content in
<details>(if v1.1+)
-
Commit and tag:
- Stage: MILESTONES.md, PROJECT.md, ROADMAP.md, STATE.md, archive files
- Commit:
chore: archive v{{version}} milestone - Tag:
git tag -a v{{version}} -m "[milestone summary]" - Ask about pushing tag
-
Offer next steps:
/gsd-new-milestone— start next milestone (questioning → research → requirements → roadmap)
<success_criteria>
- Milestone archived to
.planning/milestones/v{{version}}-ROADMAP.md - Requirements archived to
.planning/milestones/v{{version}}-REQUIREMENTS.md .planning/REQUIREMENTS.mddeleted (fresh for next milestone)- ROADMAP.md collapsed to one-line entry
- PROJECT.md updated with current state
- Git tag v{{version}} created
- Commit successful
- User knows next steps (including need for fresh requirements) </success_criteria>
<critical_rules>
- Load workflow first: Read complete-milestone.md before executing
- Verify completion: All phases must have SUMMARY.md files
- User confirmation: Wait for approval at verification gates
- Archive before deleting: Always create archive files before updating/deleting originals
- One-line summary: Collapsed milestone in ROADMAP.md should be single line with link
- Context efficiency: Archive keeps ROADMAP.md and REQUIREMENTS.md constant size per milestone
- Fresh requirements: Next milestone starts with
/gsd-new-milestonewhich includes requirements definition </critical_rules>
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.
- 1mo ago First seen · 137 lines · 16 tokens per session scan A 4146c3166521
gsd:complete-milestone is a command published in the GitHub repository kryptobaseddev/cleo (160 stars, last pushed today), licensed MIT. It adds 16 tokens to every session and 1,134 once invoked, about $0.0001 per session on Opus 5.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-30.
Other commands, from other repositories
land
Resolve and squash merge one named, currently authorized pull request.
quality
A command for temporarily clearing a release quality gate or one named check, while recording the reason and expiry time. A quality gate is a required check that normally blocks completion or release.
release-notes
Generate consistent, well-structured release notes from git history. Triggered on release tags following semver patterns (v..) to produce categorized changelog with breaking changes, features, fixes, and contributor attribution.
create-pr
Push the current branch and open a pull request into main with a structured description derived from the branch's commits and the open issues it resolves.
release-manager
Automated release coordination and deployment with ruv-swarm orchestration for seamless version management, testing, and deployment across multiple packages.
doc-changelog
Generation and maintenance of the project changelog.