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/sairam0424/MindForgeWrote 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/sairam0424/mindforge/change)<a href="https://agentmods.dev/commands/sairam0424/mindforge/change"><img src="https://agentmods.dev/badge/commands/sairam0424/mindforge/change.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.1 | $0.00041 | $0.00724 |
| Opus 5 | $0.00020 | $0.00362 |
| Sonnet 5 | $0.00008 | $0.00145 |
| Haiku 4.5 | $0.00004 | $0.00072 |
Grade A, and why
mindforge:change 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 4d 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.
What it actually says
<execution_context> @.mindforge/skills/change-management/SKILL.md </execution_context>
-
Rollout Strategy Selection: Big bang (cut over in one release, acceptable for low-risk cosmetic changes). Phased (rollout in waves by user cohort, standard for moderate risk). Parallel run (old + new coexist with feature flag, required for high-risk data migrations). Strangler fig (gradually replace old system piece by piece, for rewrites).
-
Phase Decomposition: Phase 0 (foundation) → infra + logging + kill switches. Phase 1 (alpha) → 1% internal users, validate happy path. Phase 2 (beta) → 10% friendly external users, surface edge cases. Phase 3 (GA) → 100% rollout with automated rollback if error rate >threshold. Each phase requires explicit go/no-go decision.
-
Rollback Design: Define rollback triggers (error rate >2%, latency >500ms, complaint rate >5%). Implement kill switch (feature flag to instantly revert to old code). Test rollback procedure before each phase. Document runbook with exact rollback steps. Assign rollback decision maker (on-call engineer or release manager).
-
Communication Plan: T-30d → announce migration to eng team, share technical RFC. T-14d → email affected users with "what's changing, when, what to expect". T-1d → final reminder + support channel link. T+0 → rollout begins, status page live. T+7d → retrospective on what worked/failed. Tailor message density to urgency (high urgency = daily updates).
-
Training & Enablement: For eng team → brown bag session on new patterns + runbook. For support team → FAQ doc + escalation paths. For users → migration guide with before/after examples. For stakeholders → one-pager on timeline + risk mitigation. Schedule training 2 weeks before rollout, not 2 months (recency matters).
-
Success Metrics & Monitoring: Define success criteria before migration starts (zero data loss, latency within 10% of baseline, <5 support tickets). Set up real-time monitoring dashboard. Alert on anomaly detection (sudden spike in errors). Run comparison reports (old vs new performance). Plan for post-migration optimization sprint (address performance regressions found in production).
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.
- 4d ago First seen · 38 lines · 41 tokens per session scan A d35ebcbd31df
mindforge:change is a command published in the GitHub repository sairam0424/MindForge (0 stars, last pushed 5d ago), licensed MIT. It adds 41 tokens to every session and 724 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-09-03.
Other commands, from other repositories
record
Record a browser walkthrough of a URL using Antigravity (agy). Generates .webm video, screenshots, and a report. Auto-converts to MP4 if ffmpeg is available.
p0-regulatory
Identifies regulatory requirements, DSGVO (GDPR) obligations, and legal knock-out criteria early on, before significant time is invested in the idea. A regulatory showstopper should be recognised as early as possible.
p3-infra-monitoring
Defines logging, metrics, alerting and error tracking.
p3-infra-teststrategy
Defines test levels, test tools, coverage targets and critical test paths.
gate-p1
Checks whether all results of the conception phase are complete and robust, and prepares the transition to the validation phase. No argument – this gate always checks the complete checklist.
p6-a11y
Systematically checks the application for accessibility. Each A11y dimension is a separate sub-command.