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/sponticelli/gamedev-claude-plugins/refactoring-plangit clone --depth 1 https://github.com/sponticelli/gamedev-claude-pluginsWrote 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/sponticelli/gamedev-claude-plugins/refactoring-plan)<a href="https://agentmods.dev/commands/sponticelli/gamedev-claude-plugins/refactoring-plan"><img src="https://agentmods.dev/badge/commands/sponticelli/gamedev-claude-plugins/refactoring-plan.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.00012 | $0.01880 |
| Opus 5 | $0.00006 | $0.00940 |
| Sonnet 5 | $0.00002 | $0.00376 |
| Haiku 4.5 | $0.00001 | $0.00188 |
Grade A, and why
refactoring-plan 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 — 360 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refactoring Plan Generator
Create a systematic plan for refactoring code safely and effectively.
Context Gathering
Before planning the refactoring, understand the situation:
Identify the Problem
- What's wrong with the current code?
- What pain does it cause?
- How often does it cause problems?
- What's the business impact?
Understand the Code
- What does this code do?
- How old is it?
- Who knows it best?
- What depends on it?
Assess Risk
- How critical is this code?
- What's the test coverage?
- What could break?
- What's the rollback strategy?
Define Success
- What does "done" look like?
- How will you know it worked?
- What metrics improve?
- What's acceptable downtime/risk?
Use this context to create an appropriate refactoring plan.
Output Format
# Refactoring Plan: [Component/System Name]
## Overview
### Current State
**What exists:**
[Brief description of current implementation]
**Problems:**
| Problem | Impact | Frequency |
|---------|--------|-----------|
| [Issue] | [Effect on team/product] | [How often] |
**Code location:**
- Primary: `[path/to/main/file.ext]`
- Related: `[other/files.ext]`
### Target State
**What we want:**
[Description of desired outcome]
**Benefits:**
| Benefit | Value | Measurement |
|---------|-------|-------------|
| [Benefit] | [Why it matters] | [How to verify] |
### Scope
**In scope:**
- [What will change]
- [What will change]
**Out of scope:**
- [What we're explicitly NOT touching]
- [What we're explicitly NOT touching]
---
## Risk Assessment
### Code Criticality
**Business impact if broken:** [Critical / High / Medium / Low]
**User-facing:** [Yes / No]
**Data sensitivity:** [Handles sensitive data / No]
### Test Coverage
**Current coverage:**
- Unit tests: [Yes/No, %]
- Integration tests: [Yes/No, %]
- E2E tests: [Yes/No]
**Coverage gaps:**
- [Area without tests]
- [Area without tests]
### Dependencies
**What depends on this code:**
| Dependent | How it uses this code |
|-----------|----------------------|
| [Module/Service] | [Usage pattern] |
**What this code depends on:**
| Dependency | Concern |
|------------|---------|
| [Module/Service] | [Stability concern] |
### Risk Level
**Overall risk:** [High / Medium / Low]
**Rationale:** [Why this risk level]
---
## Preparation
### Before Starting
#### Documentation
- [ ] Document current behavior
- [ ] Map dependencies
- [ ] Note undocumented behaviors
- [ ] Identify edge cases
#### Testing Foundation
- [ ] Achieve minimum test coverage for affected areas
- [ ] Add characterization tests for unclear behavior
- [ ] Verify tests pass in CI
- [ ] Set up test environment if needed
#### Safety Nets
- [ ] Feature flag available (if applicable)
- [ ] Rollback plan documented
- [ ] Monitoring in place
- [ ] Team aligned on plan
### Required Before Proceeding
| Requirement | Status | Owner |
|-------------|--------|-------|
| [Requirement] | [Done/Pending] | [Who] |
---
## Refactoring Strategy
### Approach
**Strategy:** [Strangler Fig / Branch by Abstraction / Parallel Change / Big Bang]
**Rationale:**
[Why this approach fits]
### Phases
#### Phase 1: [Name]
**Goal:** [What this phase achieves]
**Duration estimate:** [Not a timeline, but relative size: small/medium/large]
**Steps:**
1. [Specific action]
2. [Specific action]
3. [Specific action]
**Checkpoint:**
- [ ] [Verification that phase is complete]
- [ ] Tests pass
- [ ] No regressions
#### Phase 2: [Name]
**Goal:** [What this phase achieves]
**Depends on:** Phase 1 completion
**Steps:**
1. [Specific action]
2. [Specific action]
3. [Specific action]
**Checkpoint:**
- [ ] [Verification that phase is complete]
- [ ] Tests pass
- [ ] No regressions
[Continue for additional phases]
#### Final Phase: Cleanup
**Goal:** Remove old code and technical debt
**Steps:**
1. Remove deprecated code paths
2. Remove feature flags (if used)
3. Update documentation
4. Archive/delete old implementations
**Checkpoint:**
- [ ] No dead code remains
- [ ] Documentation updated
- [ ] Team informed
---
## Technical Approach
### Patterns to Apply
| Pattern | Where | Why |
|---------|-------|-----|
| [Pattern] | [Location] | [Benefit] |
### Principles to Follow
- [ ] Keep commits small and atomic
- [ ] Each commit leaves code working
- [ ] Separate refactoring commits from behavior changes
- [ ] No big bang changes without tests
### Code Standards
**Apply these standards during refactoring:**
- [Standard 1]
- [Standard 2]
- [Standard 3]
### Techniques
**Primary refactoring techniques:**
| Technique | Use Case |
|-----------|----------|
| Extract Method | [When to use] |
| Inline | [When to use] |
| Rename | [When to use] |
| Move | [When to use] |
| [Other] | [When to use] |
---
## Testing Strategy
### Before Each Change
- [ ] Tests pass
- [ ] Change is understood
### During Refactoring
- [ ] Run tests after each small change
- [ ] Add tests for discovered edge cases
- [ ] Document surprising behaviors
### Test Types
| Test Type | Purpose | When to Run |
|-----------|---------|-------------|
| Unit | Verify functions work | Every save/commit |
| Integration | Verify components work together | Before push |
| E2E | Verify user flows | Before merge |
### New Tests Needed
| Area | Test Type | Description |
|------|-----------|-------------|
| [Area] | [Type] | [What to test] |
---
## Rollback Plan
### If Things Go Wrong
#### Minor Issues
**Symptoms:** Tests fail, but easy to fix
**Action:** Fix forward, don't merge until green
#### Medium Issues
**Symptoms:** Unexpected behavior in staging
**Action:** Revert PR, investigate, re-plan
#### Critical Issues
**Symptoms:** Production incident
**Action:**
1. Revert immediately
2. Confirm stability
3. Investigate root cause
4. Update plan before retry
### Revert Commands
```bash
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 · 360 lines · 12 tokens per session scan A fdcbd5cec92a
refactoring-plan is a command published in the GitHub repository sponticelli/gamedev-claude-plugins (15 stars, last pushed 7mo ago), licensed MIT. It adds 12 tokens to every session and 1,880 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-30.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
constitution
Create or update the project constitution from interactive or provided principle inputs.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.