architecture-cleanup
Skill452 starsChanged 23 days agoApache-2.0View on GitHub
Find and execute bounded architecture cleanup across public exports, package ownership, Convex bundle graphs, plugins, CLI/scaffolds, generated files, docs, and agent navigation.
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use this for structural cleanup whose value comes from removing ownership confusion, duplicate concepts, leaky public APIs, expensive …
- Very specific: line 26
Use task for a narrow implementation and major-task for a new framework, migration, benchmark, or public-API proposal.
- Very specific: line 41
Create a goal plan from the architecture-cleanup template with the agent-native pack.
- Distinctive: line 49
import-graph and bundle-size consequences.
- Distinctive: line 65
Remove dead aliases and compatibility shims unless explicitly required.
- Distinctive: line 66
Prefer a small composable API over a monolithic global.
- Distinctive: line 78
Do not patch fixtures, example plugin files, generated skills, or generated root guidance directly.
- Distinctive: line 119
Use bounded TDD for changed live behavior.
- Distinctive: line 127
Search for old names, aliases, reach-through imports, and stale docs.
- Distinctive: line 129
Run package build, focused tests, fixtures/scenarios, docs/skill sync, and repository checks required by the changed surface.
- Very specific: line 131
Run deslop after behavior works.
- Very specific: line 132
Run agent-native-reviewer, then autoreview.
- Distinctive: line 135
Stop rather than inventing a compatibility layer, changing an unrelated public contract, or editing generated output without its owner.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
Architecture Cleanup
Use this for structural cleanup whose value comes from removing ownership confusion, duplicate concepts, leaky public APIs, expensive import graphs, or generated-source mistakes. It is not a prettier-file pass.
Use When
- a concept has multiple owners or multiple public names;
- package boundaries and exports no longer describe runtime ownership;
- a Convex function imports a large graph for a narrow operation;
- plugin, CLI, scaffold, fixture, docs, and runtime shapes disagree;
- generated files are being edited instead of their source;
- agents repeatedly need broad searches to locate one responsibility;
- an old path should be removed with a hard cut.
Use task for a narrow implementation and major-task for a new framework,
migration, benchmark, or public-API proposal.
Read Order
VISION.mdanddocs/README.md.- The active goal plan or named source.
- Root/package manifests, exports,
turbo.json, and build scripts. - Runtime entry points and their static import graphs.
- CLI/template source, regeneration commands, fixtures, and scenarios.
- User docs and matching
packages/kitcn/skills/kitcn/**content. - Tests and proof commands that guard the current contract.
Goal Contract
Create a goal plan from the architecture-cleanup template with the
agent-native pack. Add package-api when a package export or public API is in
scope and docs when user docs move.
The plan must state:
- current and target owner maps;
- public names being kept, added, or deleted;
- import-graph and bundle-size consequences;
- source/generated ownership and regeneration commands;
- docs and package-skill synchronization;
- fixtures, scenarios, compatibility stance, and proof gates;
- deletion receipts and a rollback or safe-stop boundary.
Core Laws
One semantic owner
Each durable concept gets one canonical implementation owner. Adapters may translate at a boundary, but they do not redefine the concept.
Public API is deliberate
- Trace every public export to a real supported entry point.
- Remove dead aliases and compatibility shims unless explicitly required.
- Prefer a small composable API over a monolithic global.
- A hard cut deletes old exports, docs, tests, examples, and scaffold output.
Convex bundles stay narrow
Convex statically bundles each function entry. Never solve convenience by pulling a monolithic registry, every plugin, or browser-only code into a narrow entry. Prefer per-module callers, plugins, and leaf imports. Prove the relevant entry graph when moving shared code.
Generated output has an owner
Do not patch fixtures, example plugin files, generated skills, or generated root guidance directly. Change the source and regenerate. Record the source, command, and representative generated diff.
Agent navigation is architecture
A good structure lets an agent find the owner from manifests, exports,
docs/README.md, and nearby tests. Penalize duplicated naming, hidden runtime
registration, cross-package reach-through, and docs that point to stale paths.
Candidate Method
Inventory concrete candidates before editing:
| Candidate | Current owner | Target owner | Public impact | Bundle impact | Generated impact | Evidence |
Score only when choosing between valid candidates:
- correctness and owner clarity;
- deleted surface and reduced navigation cost;
- bundle/import-graph improvement;
- DX and API coherence;
- proof availability;
- conflict and migration risk.
Reject cleanup that merely renames files, adds forwarding wrappers, or moves complexity without reducing an owner.
Implementation Packet
Each packet names:
- one owner and exact files;
- acceptance behavior;
- public API and import-graph deltas;
- generated files and regeneration command;
- tests, fixtures, scenarios, docs, and skill sync;
- deletions and forbidden fallback paths;
- proof required before the next packet.
Use bounded TDD for changed live behavior. Do not write tests whose only purpose is asserting that dead code remains dead.
Closeout
Before completion:
- Prove the target owner map from source and exports.
- Search for old names, aliases, reach-through imports, and stale docs.
- Regenerate every owned artifact and prove no hand-edited drift remains.
- Run package build, focused tests, fixtures/scenarios, docs/skill sync, and repository checks required by the changed surface.
- Run
deslopafter behavior works. - Run
agent-native-reviewer, thenautoreview. - Record deletion receipts, residual risks, and the next owner if incomplete.
Stop rather than inventing a compatibility layer, changing an unrelated public contract, or editing generated output without its owner.
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- mgerdov-igt/ai-cookbook★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository54 other files it gives its agents.
- .agents/AGENTS.mdAGENTS.md
- AGENTS.mdAGENTS.md
- .agents/skills/autoreview/AGENTS.mdAGENTS.md
- .agents/skills/autoreview/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- 4-ultraciteSkill
- agent-browser-issueSkill
- agent-native-reviewerSkill
- autoclosureSkill
- autogoalSkill
- autoreviewSkill
- autoSkill
- avoid-feature-creepSkill
- better-auth-best-practicesSkill
- changeset-doc-syncSkill
- changeset-resolveSkill
- changesetSkill
- component-colocationSkill
- concave-paritySkill
- concaveSkill
- convex-release-auditSkill
- designSkill
- deslopSkill
- diagnosing-bugsSkill
- find-skillsSkill
- grill-with-visionSkill
- hard-cutSkill
- jotai-xSkill
- kitcnSkill
- linear-backlogSkill
- major-taskSkill
- next-dev-loopSkill
- nextjsSkill
- orchestratorSkill
- package-release-auditSkill
- prototypeSkill
- react-querySkill
- research-wikiSkill
- resolve-pr-feedbackSkill
- resolving-merge-conflictsSkill
- scenariosSkill
- shadcn-paritySkill
- sync-convex-authSkill
- sync-visionSkill
- taskSkill
- tddSkill
- testingSkill
- toastSkill
- to-milestoneSkill
- to-prdSkill
- turborepoSkill
- video-transcriptsSkill
- visionSkill
- walkthroughSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
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.

