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 skills add FerroxLabs/ferrox-factory --skill ferrox-complete-milestonegit clone --depth 1 https://github.com/FerroxLabs/ferrox-factoryWrote 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/ferroxlabs/ferrox-factory/ferrox-complete-milestone)<a href="https://agentmods.dev/skills/ferroxlabs/ferrox-factory/ferrox-complete-milestone"><img src="https://agentmods.dev/badge/skills/ferroxlabs/ferrox-factory/ferrox-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/skills/ferroxlabs/ferrox-factory/ferrox-complete-milestone"><img src="https://agentmods.dev/badge/skills/ferroxlabs/ferrox-factory/ferrox-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.00022 | $0.01210 |
| Opus 5 | $0.00011 | $0.00605 |
| Sonnet 5 | $0.00004 | $0.00242 |
| Haiku 4.5 | $0.00002 | $0.00121 |
Grade A, and why
ferrox-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 5d 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.
This is a copy
83% identical to gsd-complete-milestone — 23 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 143 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):
- @~/.claude/ferrox-core/workflows/complete-milestone.md (main workflow)
- @~/.claude/ferrox-core/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
/ferrox-audit-milestonefirst - If audit status is
gaps_found: recommend closing the gaps inline (the audit output already enumerates them — insert closure phases via/ferrox-phase --insert <N>plus the standard discuss/plan/execute chain) before proceeding. - If audit status is
passed: proceed to step 1
## Pre-flight Check {If no v{{version}}-MILESTONE-AUDIT.md:} ⚠ No milestone audit found. Run `/ferrox-audit-milestone` first to verify requirements coverage, cross-phase integration, and E2E flows. {If audit has gaps:} ⚠ Milestone audit found gaps. The audit output already enumerates the unsatisfied requirements, cross-phase issues, and broken flows — insert a closure phase per gap with `/ferrox-phase --insert <N>` and run the standard `/ferrox-discuss-phase` → `/ferrox-plan-phase` → `/ferrox-execute-phase` chain. Or proceed anyway to accept the gaps 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:
/ferrox-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 (if
git.create_tagenabled) - Commit successful
- User knows next steps (including need for fresh requirements) </success_criteria>
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.
- 5d ago First seen · 143 lines · 22 tokens per session scan A ffcfda442ae4
ferrox-complete-milestone is a skill published in the GitHub repository FerroxLabs/ferrox-factory (22 stars, last pushed 1mo ago), licensed MIT. It adds 22 tokens to every session and 1,210 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 83% identical to gsd-complete-milestone, differing in 23 lines, and is treated as a copy.
Other skills, from other repositories
batch
Research and plan a large-scale change, then execute it in parallel across 5–30 isolated worktree agents that each open a PR.
gsd-complete-milestone
Archive completed milestone and prepare for next version.
github-cli
Default GitHub skill for the action agent. Use githubcli for any GitHub request — create/list/view/close issues and PRs, assign, labels, repos, releases, checks, github.com/owner/repo URLs, or gh api. Prefer over shellrun/!gh. Run these with githubcli in the current agent turn.
github
Drive GitHub via the official gh CLI — repos, issues, pull requests, releases, gists, Actions runs, and raw REST through gh api. Use when the user asks to inspect or manage GitHub.
testdino-releases
Use when the user wants to browse, inspect, create, or update releases/milestones in a TestDino project. Covers listreleases, getrelease, createrelease, and updaterelease. Accepts counter-style IDs like MS-12.
create-milestone
Create a GitHub milestone for an upcoming release. Suggests the next version based on the latest release, gathers all merged PRs and closed issues since that release, presents a draft with two tables (Issues and PRs) for user approval, then creates the milestone and assigns all approved items.