cc-refactor
Skill0 starsChanged 26 days agoMITView on GitHub
Refactor description: $ARGUMENTS Describe what you want to refactor and why. Include: Before any agent is invoked, verify that the code being refactored has adequate test coverage. A refactor without tests is not a refactor — it is a rewrite with unknown behavioral consequences. If coverage is insufficient: Always invoke architect first, regardless of risk level. A refactor without a written justification is scope creep in disguise. architect must produce a Refactor Plan that includes: Scope creep warning: If during…
In this repository219 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- AGENTS.mdAGENTS.md
- .claude/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/behavioral-discipline.mdcCursor rule
- .cursor/rules/context-budget.mdcCursor rule
- .cursor/rules/orchestration.mdcCursor rule
- .cursor/rules/yagni-stdlib.mdcCursor rule
- androidSkill
- android-ui-designSkill
- api-versioningSkill
- astroSkill
- auth-token-inspectorSkill
- backlogSkill
- cc-api-contractSkill
- cc-db-migrationSkill
- cc-featureSkill
- cc-fixSkill
- cc-pagespeedSkill
- cc-reviewSkill
- cc-spec-mutationSkill
- cc-tdd-cycleSkill
- cc-test-planSkill
- code-reviewSkill
- commitSkill
- conductor-setupSkill
- councilSkill
- database-migrationsSkill
- django-ormSkill
- django-testingSkill
- django-uvSkill
- drizzle-schema-architectSkill
- evaluationSkill
- fastapi-pydantic-strictSkill
- find-skillsSkill
- jpa-nplusone-detectorSkill
- jpa-postgresSkill
- laravel-specialistSkill
- livewire-alpine-bridgeSkill
- multi-agent-orchestrationSkill
- nextjs-typescriptSkill
- openspecSkill
- pagespeed-insightsSkill
- pagespeed-perfSkill
- php-proSkill
- python-django-stackSkill
- python-fastapi-stackSkill
- pythonSkill
- rust-asyncSkill
- rust-engineeringSkill
- rust-sqlxSkill
- security-ai-llmSkill
- security-blue-teamSkill
- security-cloudSkill
- security-cryptoSkill
- security-exploit-devSkill
- security-grcSkill
- security-incident-responseSkill
- security-log-analysisSkill
- security-malware-analysisSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 13 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Before any agent is invoked, verify that the code being refactored has adequate test coverage.
- Distinctive: line 29
If coverage is insufficient:
- Distinctive: line 33
Do not proceed with the refactor until coverage is confirmed.
- Very specific: line 39
Always invoke architect first, regardless of risk level.
- Distinctive: line 51
Scope creep warning: If during planning architect identifies unrelated improvements, they must be listed separately as "Out of scope." They …
- Distinctive: line 62
Read the risk field from the Refactor Plan and follow the corresponding route.
- Distinctive: line 93
Read the Refactor Plan before opening any file
- Distinctive: line 95
Run the full test suite before and after — both runs must pass
- Distinctive: line 110
If new risks are found, STOP and report to the human before continuing
- Distinctive: line 118
All tests that existed before the refactor still pass
- Distinctive: line 119
No test was deleted or commented out to make the suite pass
- Distinctive: line 122
If any test fails that was passing before, the refactor has introduced a regression.
- Distinctive: line 134
No behavior was changed beyond the plan's scope
- Distinctive: line 135
No unrelated files were modified
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Refactor Workflow
Refactor description: $ARGUMENTS
Describe what you want to refactor and why. Include:
- The current structure or pattern being changed
- The target structure or pattern
- The motivation (performance, readability, architectural alignment, etc.)
- Known risk areas or dependencies
Prerequisite — Test coverage check
Before any agent is invoked, verify that the code being refactored has adequate test coverage.
A refactor without tests is not a refactor — it is a rewrite with unknown behavioral consequences.
If coverage is insufficient:
- STOP. Report the coverage gap to the human.
- Suggest invoking
/cc:test-planfirst to establish coverage. - Do not proceed with the refactor until coverage is confirmed.
Step 1 — Architectural justification (architect)
Always invoke architect first, regardless of risk level. A refactor without a
written justification is scope creep in disguise.
architect must produce a Refactor Plan that includes:
- Statement of the problem with the current structure
- Proposed target structure and rationale
- Affected files and module boundaries
- Risk level:
low,medium, orhigh - Behavioral invariants that must not change
- Open questions requiring human input
Scope creep warning: If during planning architect identifies unrelated improvements, they must be listed separately as "Out of scope." They are not part of this refactor.
STOP here. Show the Refactor Plan and wait for explicit human approval. Do not proceed without written approval of the plan.
Step 2 — Route by risk
Read the risk field from the Refactor Plan and follow the corresponding route.
Low-risk route
Applies when: the refactor is purely internal, no public interfaces change, full test coverage exists for the affected code, and behavioral impact is isolated to the refactored module.
Route: architect (done) → implementer
Proceed to Step 3a.
Medium or high-risk route
Applies when: module boundaries change, shared interfaces are affected, performance characteristics may change, or the refactor touches more than two files with behavioral impact.
Route: architect (done) → implementer → reviewer
Proceed to Step 3b.
Step 3a — Implementation, low-risk (implementer)
Invoke implementer with the approved Refactor Plan.
Implementer creates a Git Worktree before touching any file; all edits happen inside it.
implementer must:
- Read the Refactor Plan before opening any file
- Apply only the changes specified in the plan
- Run the full test suite before and after — both runs must pass
- Produce an Implementation Summary: what changed, what did not change, test results before and after
Any deviation from the plan — including "obvious improvements" encountered during implementation — must be flagged and held for a separate task.
Step 3b — Implementation, medium/high-risk (implementer)
Same rules as 3a. Additionally:
- implementer must document any unexpected complexity discovered during implementation and pause if the complexity changes the risk assessment
- If new risks are found, STOP and report to the human before continuing
Step 4 — Test suite verification
For all risk levels, confirm:
- All tests that existed before the refactor still pass
- No test was deleted or commented out to make the suite pass
- Behavior documented in the Task Card remains unchanged
If any test fails that was passing before, the refactor has introduced a regression. STOP and report.
Step 5 — Code review (reviewer) — medium/high-risk only
Invoke reviewer with the diff and Refactor Plan.
reviewer must verify:
- The implementation matches the approved plan
- No behavior was changed beyond the plan's scope
- No unrelated files were modified
Review Report must include CRITICAL / WARNING / SUGGESTION findings. CRITICAL findings block completion.
Completion
Report: Refactor Plan (approved), Implementation Summary, test results before and after, Review Report (if applicable).
The refactor is complete only when: all pre-existing tests still pass, the implementation matches the approved plan exactly, and no CRITICAL review findings remain.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

