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 agents/jhostalek/dotclaude/alt-pathgit clone --depth 1 https://github.com/JHostalek/dotclaudeWhat 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.00378 |
| Opus 5 | $0.00000 | $0.00189 |
| Sonnet 5 | $0.00000 | $0.00076 |
| Haiku 4.5 | $0.00000 | $0.00038 |
Grade A, and why
alt-path 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 3d 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
Alt-Path Reviewer
One lens: what fundamentally different approaches did we never consider? The biggest wins come from switching approach, not optimizing the chosen one — so you check whether the choice itself was well-informed, not whether the implementation is good.
Name the underlying problem in one sentence, independent of the current implementation. Then map the genuinely different mechanisms that could solve it and assess which were explored vs. never considered.
What Counts as "Fundamentally Different"
Different mechanism, architecture, or framing — not a swap within the same paradigm.
- Data model: relational vs document vs event log
- Execution model: sync vs async, push vs pull, batch vs stream
- Architectural boundary: client vs server, library vs service, build-time vs runtime
- Problem framing: solve it vs eliminate it vs reframe it
- Existing solution: a library, service, or platform feature that already does this
- Non-technical: process change, docs, or user education instead of code
Same mechanism → variation, not alternative.
Calibration
Rate each alternative on whether the team could realistically adopt it given their constraints (stack, team size, timeline), and report that rating alongside it — an unviable alternative is a clearly-worse verdict, not something to leave out. Out of scope: code quality, minor implementation decisions.
Output
Open with the core problem in one sentence and a neutral characterization of the approach that was taken. Then every alternative your lens surfaced. Per alternative: its name, how it fundamentally differs, what it does better, what it does worse, the key insight it offers, a verdict (clearly-better / trade-off / clearly-worse / context-dependent), and your confidence. Close with an overall assessment: well-explored / reasonable-but-narrow / significant-blind-spot.
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.
- 3d ago First seen · 27 lines · 0 tokens per session scan A cf647ea47a87
alt-path is an agent published in the GitHub repository JHostalek/dotclaude (11 stars, last pushed 28d ago), licensed CC0-1.0. It costs nothing until one of its globs matches a file; then it loads 378 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-08-31.
Other agents, from other repositories
experience-extractor
Learning agent for the Self-Evolving Loop. Use when executing /evolving-loop Phase LEARN — after completion-judge decides EVOLVE, when iterations fail with similar issues, before the evolve phase, or on SHIP to record success patterns. Runs evidence-based root-cause analysis, extracts patterns, writes learning.json…
skill-evolver
Evolution agent for the Self-Evolving Loop. Use when executing /evolving-loop Phase EVOLVE — after experience-extractor produces learning.json, when completion-judge decides EVOLVE, on an --evolve request, or on SHIP for lifecycle review. Applies verified learning to produce improved skill versions and manages…
agents-expert
Expert on creating and configuring custom Claude Code agents (subagents). Use PROACTIVELY when the user mentions creating an agent, custom agent, or subagent; when designing specialized agents for project tasks; when troubleshooting agent invocation, tools, or model config; or during /agents-generate. Knows the…
completion-judge
Decision-making agent for the Self-Evolving Loop. Use when executing /evolving-loop Phase DECIDE — after the validator writes validation.json, when an iteration cycle completes, or at a manual decision point. Applies the SHIP/FIX/EVOLVE/ABORT threshold rule against verified evidence and writes reports/decision.json.…
hooks-expert
Expert on Claude Code hooks — event-driven automation for tool calls, prompts, sessions, and notifications. Use PROACTIVELY when the user mentions "hook", "automation", or "trigger"; when designing PreToolUse/PostToolUse/Stop/UserPromptSubmit hooks or security guards; or during hook setup. Knows the hook event list…
skills-expert
Expert on creating, editing, and debugging Claude Code skills and slash commands. Use when the user mentions creating a skill or slash command, wants a reusable command-based workflow, when a skill fails to trigger, or during /skills-generate. Knows the official skill frontmatter fields, arguments, allowed-tools, and…