ios-refactor
Skill1 starsChanged 14 days agoMITView on GitHub
Refactor Swift code in this iOS codebase without changing behaviour — extracting types, splitting oversized files, moving logic to the right layer, removing duplication, or migrating a pattern across features. Use when asked to clean up, tidy, restructure, extract, split, simplify or modernise existing code, or when a file has grown past the point of being readable.
In this repository37 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ios-accessibility-auditSkill
- ios-api-contract-migrationSkill
- ios-api-endpointSkill
- ios-app-intents-siriSkill
- ios-bug-triageSkill
- ios-build-configurationSkill
- ios-cloudkit-syncSkill
- ios-combine-patternsSkill
- ios-commit-and-prSkill
- ios-commitSkill
- ios-concurrency-auditSkill
- ios-coreml-apple-intelligenceSkill
- ios-deep-linkingSkill
- ios-dependency-assessmentSkill
- ios-design-fixSkill
- ios-feature-moduleSkill
- ios-knowledge-baseSkill
- ios-latest-os-adoptionSkill
- ios-localizationSkill
- ios-offline-writeSkill
- ios-performance-tuningSkill
- ios-port-from-androidSkill
- ios-port-to-androidSkill
- ios-precommitSkill
- ios-privacy-complianceSkill
- ios-push-and-background-tasksSkill
- ios-release-prepSkill
- ios-sdk-upgradeSkill
- ios-secure-reviewSkill
- ios-storekit-subscriptionsSkill
- ios-swift6-concurrency-migrationSkill
- ios-swiftdataSkill
- ios-swift-testing-migrationSkill
- ios-swiftui-screenSkill
- ios-unit-testsSkill
- ios-widgetkit-live-activitiesSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
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 16
Check the tests that cover the code: If there are none, write them *first*, against current behaviour, and confirm they pass.
- Very specific: line 19
Check
docs/DECISIONS.md: If the structure you dislike is a recorded decision, argue with the decision rather than quietly reversing it. - Distinctive: line 43
Keep the public shape of a type stable while you move its internals, then change the shape in a separate step.
- Distinctive: line 45
Run the tests after each step, not at the end.
- Distinctive: line 46
Leave the comments that explain *why* attached to the code they explain.
≈ “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 safely
A refactor that changes behaviour is not a refactor, it is an undocumented change. The discipline below is what keeps them apart.
Before touching anything
- Name the goal in one sentence. "Move date formatting out of the view into the view model." If you cannot, the change is not a refactor — it is a redesign, and needs discussion first.
- Check the tests that cover the code. If there are none, write them first, against current behaviour, and confirm they pass. Those tests are the only proof the refactor was safe.
- Check
docs/DECISIONS.md. If the structure you dislike is a recorded decision, argue with the decision rather than quietly reversing it.
Where things belong
Most refactors in this codebase are one of these five moves:
| Smell | Move |
| Formatting, string building or derived flags in a view | Into the view model as a computed property |
| Business rules or validation in a view model | Onto the model (validationMessages) or the repository |
Endpoint construction or cache keys in a view model | Into the feature's Data folder |
| The same helper in two features | Down into Core — never sideways between features |
| A repository over ~350 lines | Split by concern: reads, writes, replay — same type, // MARK: sections, or an extension per concern in separate files |
Things that must not move: URLSession out of Core/Networking, tokens out
of Core/Auth, cache and outbox access out of repositories.
Method
- One kind of change per commit. Renaming and extracting and re-ordering in one diff is unreviewable.
- Extract by copying, redirecting call sites, then deleting the original — never by editing in place and hoping.
- Keep the public shape of a type stable while you move its internals, then change the shape in a separate step.
- Run the tests after each step, not at the end.
- Leave the comments that explain why attached to the code they explain. Losing the "why the actor is here" comment costs more than the refactor gains.
What counts as done
The diff should read as obviously equivalent. If a reviewer has to reason about whether behaviour changed, split the change up further.
Verification
- Tests existed before, still exist, and still pass unchanged. Changing a test to match the refactor means behaviour changed — stop and say so.
- No new dependency across the layer boundaries.
- No feature now imports another feature.
- Public behaviour identical: same states, same error copy, same requests.
- Comments explaining non-obvious decisions were carried across.
project.pbxprojis untouched. The source folders are synchronised, so a file or folder move needs no project-file change; if one appears in the diff, explain why.- The summary says explicitly what did not change.
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.