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 skills add shandar/pwp-plugin --skill pwp-refactorgit clone --depth 1 https://github.com/shandar/pwp-pluginWrote 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/skills/shandar/pwp-plugin/pwp-refactor)<a href="https://agentmods.dev/skills/shandar/pwp-plugin/pwp-refactor"><img src="https://agentmods.dev/badge/skills/shandar/pwp-plugin/pwp-refactor/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/shandar/pwp-plugin/pwp-refactor"><img src="https://agentmods.dev/badge/skills/shandar/pwp-plugin/pwp-refactor.svg" alt="Reviewed on agentmods" width="80" 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.00098 | $0.00852 |
| Opus 5.5 | $0.00039 | $0.00341 |
| Sonnet 5.5 | $0.00020 | $0.00170 |
| Haiku 4.5 | $0.00010 | $0.00085 |
Grade A, and why
pwp-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 1mo 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 — 81 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Refactoring Skill
This skill defines how to refactor code safely. The cardinal rule: refactoring changes structure, never behavior. If behavior changes, it's not a refactor — it's a feature or a fix.
Refactoring Mindset
- Refactoring is not cleaning. It's restructuring code to make it easier to understand, extend, or maintain. It requires the same rigor as writing new features.
- Never refactor and change behavior in the same commit. Mixing structural changes with behavioral changes makes review impossible and debugging a nightmare.
- Tests are your safety net. If tests don't exist for the code you're refactoring, write them first.
- Approval required. Do not refactor code you weren't asked to touch. Flag ugly code, but don't fix it without explicit approval.
When to Refactor
| Signal | Example | Action |
|---|---|---|
| Duplication | Same logic in 3+ places | Extract to shared function/component |
| Complexity | Function > 50 lines, deeply nested conditionals | Decompose into smaller functions |
| Naming | Misleading or abbreviated names | Rename for clarity |
| God files | File > 500 lines mixing concerns | Split by responsibility |
| Dead code | Unused imports, unreachable branches | Remove |
| Type weakness | any types, missing interfaces |
Add proper types |
When NOT to Refactor
- During a bug fix (fix the bug, then propose a refactor separately)
- Without tests for the affected code
- Without explicit approval from the user/team
- When you're "just making it better" without a concrete improvement goal
- In the same commit as a feature change
Refactoring Protocol
Step 1: Justify
- State what you want to refactor and why
- Quantify the improvement: "Reduces duplication from 3 copies to 1"
Step 2: Ensure Safety Net
- Verify tests exist for the code being refactored
- If tests are missing: write them first, commit them separately, then refactor
Step 3: Plan the Changes
- List every file that will change
- Identify the refactoring pattern
- Declare the scope boundary: "I will only touch files X, Y, Z"
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.
- 1mo ago First seen · 81 lines · 98 tokens per session scan A 83e35b6493b1
pwp-refactor is a skill published in the GitHub repository shandar/pwp-plugin (1 stars, last pushed 7mo ago), licensed MIT. It adds 98 tokens to every session and 852 once invoked, about $0.0004 per session on Opus 5.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 skills, from other repositories
readme-doctor
Audit a GitHub repo's README against best-practice patterns and produce a prioritized punch list of fixes. Runs a structured review covering hero presence, install-to-first-success length, "what is this in one sentence" clarity, audience-jargon match, scannability, and drift signals (stale versions, dead links, badge…
review-checklist
Code review standards and checklist for the code-reviewer agent.
boundaries
Analyze Phoenix context boundaries and module coupling via mix xref. Use when checking cross-context calls, validating dependencies, before splitting modules, or reviewing architecture.
pr-threads-address
Address PR review feedback by systematically working through every unresolved PR review thread on the current branch's PR - analyze each comment, make the requested code changes (with tests where useful), commit, and optionally reply and resolve.
r-tidyverse-style
Use when the user asks to review or clean up R code for tidyverse style, standardize formatting or names, remove redundant comments or wrappers, or make a behavior-preserving style pass. Also use when writing substantial new R package code if the user requests tidyverse style or the package already follows it. Not for…
techdebt
Analyze Elixir/Phoenix technical debt — duplicates, refactoring opportunities, credo issues. Use when asked about code quality, cleanup, or what to improve.