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 commands/car12o/claude-workflows/gopher-refactorgit clone --depth 1 https://github.com/car12o/claude-workflowsWrote 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/car12o/claude-workflows/gopher-refactor)<a href="https://agentmods.dev/commands/car12o/claude-workflows/gopher-refactor"><img src="https://agentmods.dev/badge/commands/car12o/claude-workflows/gopher-refactor.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 | $0.00025 | $0.01454 |
| Opus 5 | $0.00013 | $0.00727 |
| Sonnet 5 | $0.00005 | $0.00291 |
| Haiku 4.5 | $0.00003 | $0.00145 |
Grade A, and why
gopher-refactor 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.
How it starts
The opening of the file, as written. The whole thing — 158 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the gopher-refactor orchestrator for Go 1.24+ projects.
Core rule: You are an orchestrator. Your job is to delegate work to specialized subagents via the Task tool, make decisions at stop points, and communicate with the user.
Refactoring Request
$ARGUMENTS
Workflow
Phase 1: Analysis → go-analyzer (scope, coverage, risks)
[STOP 1: Plan approval]
Phase 2: Safety Net → go-implementer (add tests if needed)
→ go-quality-gate (verify tests pass)
Phase 3: Refactor → go-implementer (apply changes)
→ go-quality-gate (verify no regressions)
→ git commit
Phase 4: Review → go-reviewer (verify behavior preserved)
[STOP 2: Final approval]
Subagent Reference
| Phase | Agent | subagent_type |
|---|---|---|
| Analysis | go-analyzer | gopher:go-analyzer |
| Safety Net / Refactor | go-implementer | gopher:go-implementer |
| Quality Gates | go-quality-gate | gopher:go-quality-gate |
| Review | go-reviewer | gopher:go-reviewer |
Phase 1: Analysis
Use the Task tool with subagent_type: "gopher:go-analyzer" to delegate analysis. Include in the task prompt:
- The refactoring description from $ARGUMENTS
- Instruction to focus on: target files, existing test coverage on those files, dependencies between packages, and blast radius
- Do NOT ask the analyzer to determine scale or ADR triggers — this is a refactoring, not a new feature
The analyzer should return:
- Files targeted for refactoring
- Current test coverage on those files (run
go test -coverprofileon target packages) - Blast radius (files that import/reference the target code)
- Risks (behavior changes, interface changes, breaking dependents)
Capture the analysis output for subsequent phases.
[STOP 1: Plan Approval]
Present to the user:
- Files targeted for refactoring
- Current test coverage on target packages
- Safety net decision (tests will be added or coverage is adequate)
- Blast radius (files that import/reference the target code)
- Risks (behavior changes, interface changes, breaking dependents)
- Proposed approach (incremental steps if the refactoring is large)
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 · 158 lines · 25 tokens per session scan A fb4c70ae01ca
gopher-refactor is a command published in the GitHub repository car12o/claude-workflows (2 stars, last pushed 6mo ago), licensed MIT. It adds 25 tokens to every session and 1,454 once invoked, about $0.0001 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-31.
Other commands, from other repositories
go-review
Go code review for idiomatic patterns.
cli-patterns
Reference patterns for implementing CLI commands in internal/cli/.
refactor-clean
Find and remove dead Go code, orphaned tests, and complexity issues.
bench
Generate and run Go benchmarks with profiling and optimization analysis.
profile
Profile Go code, identify bottlenecks, optimize, and verify improvements.
generate-tests
Generate unit or integration tests for Go code following project patterns and coverage targets.