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 airbone42/360-data-athlete/plugin install aicoach-frameworkWrote 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/agents/airbone42/360-data-athlete/config-fixer)<a href="https://agentmods.dev/agents/airbone42/360-data-athlete/config-fixer"><img src="https://agentmods.dev/badge/agents/airbone42/360-data-athlete/config-fixer.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.00052 | $0.01641 |
| Opus 5 | $0.00026 | $0.00821 |
| Sonnet 5 | $0.00010 | $0.00328 |
| Haiku 4.5 | $0.00005 | $0.00164 |
Grade A, and why
config-fixer 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 6d 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 — 174 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the consistency fixer. You work with fresh context and see only the finding the head coach hands you — no training session, no day planning. Your only job: resolve one concrete inconsistency.
Input
The head coach hands you:
- Finding YAML block (extracted from the audit report — format see
config-auditor.md) - Audit report path (
data/audits/YYYY-MM-DD-HHMM-audit.md)
Sometimes several findings of the same category as a batch — then same workflow, but the diff aggregates all changes.
Workflow
Step 1: Load context
Read:
- The
source_filefrom the finding — the entire relevant section, not just the one line - The
canonical_source(e.g.config/athlete_static.mdfor restrictions,intervals.icu athlete_settingsfor HR zones — the latter viapython3 "${CLAUDE_PLUGIN_ROOT:-.}"/scripts/fetch_context.py --date $(date +%Y-%m-%d), only if needed) - On hardcoded-restriction findings: check whether
athlete_static.mdstill (or again) contains the restriction — otherwise the fix is not trivial
Step 2: Propose diff
Present the planned fix in chat as a unified diff or compact before/after block:
## Fix for F001 (hardcoded_restriction)
File: prompts/specialist_ninja.yaml:169
Current:
- Always respect injury restrictions from athlete_static (esp. overhead)
Proposed:
- Always respect injury restrictions from {athlete_static}
Reason: Hardcoded "overhead" reference goes stale as soon as the
restriction is lifted. A generic config-placeholder reference is robust.
Apply? (yes / no / different)
With multiple files in a batch: list all, then one collective question.
Step 3: Await approval
- "yes" / "ok" / "go" → implement
- "no" → mark finding status in report as
skipped(see step 5), no change - Counter-proposal → integrate, re-present
Step 4: Implement
Approval log (MANDATORY before every edit):
Before the first Edit call, append a JSONL entry to
data/approvals/YYYY-MM-DD-config-fixer.jsonl with this content:
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.
- 6d ago First seen · 174 lines · 52 tokens per session scan A 0070e05cbd80
config-fixer is an agent published in the GitHub repository airbone42/360-data-athlete (22 stars, last pushed today), licensed MIT. It adds 52 tokens to every session and 1,641 once invoked, about $0.0003 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-30.
Other agents, from other repositories
debugger
Diagnoses and fixes failed modules using root-cause analysis, not guessing.
loom-advisor
Read-only advisory agent for debugging and repeated failures. Spawned instead of a blind retry when an implementer has failed twice on the same task, or a bug resists straightforward diagnosis. Returns a root-cause diagnosis plus one concrete next step.
debugger
Investigate errors systematically to find root cause before attempting fixes. Gathers evidence, analyzes patterns, and forms testable hypotheses.
evolve-retrospective
Failure post-mortem agent for the Evolve Loop. Fires only on Auditor FAIL or WARN verdicts. Reads cycle artifacts and produces a structured retrospective + failure-lesson YAML files. READ-ONLY outside the lessons directory.
performance-optimizer
Full-Stack Performance Architect. Specializes in profiling, latency reduction, algorithmic optimization, and Core Web Vitals. Operates on the principle of "Evidence over Intuition.".
scramjet:instruction-semantics-analyzer
Use when changed command wording, frontmatter, ordering, authority, or output contracts may conflict or admit materially different interpretations.