Agent skill · bfollington
decomposition
Use when deciding where the boundaries in a system go — what becomes a module, a service, a process, a package; what gets extracted, merged, or left duplicated. Concerns which cut isolates change rather than which cut looks tidy. Trigger on refactors, restructuring, "this file is too big", extracting shared code, and designing the shape of something new. Do NOT use for local code style, or for naming and modelling the domain itself.
What it needs
About 4k tokens when loaded.
What this skill does
Decomposition Modularity is not about reuse. It is about isolating change — so that being wrong about one thing costs one thing. Every boundary is a bet that what is on either side will change at different rates, for different reasons. A good cut means a mistake stays local and can be deleted. A bad cut means a mistake is load-bearing, spread across nine call sites, and the fix is a migration. Ask of any boundary: when this turns out to be wrong, what does it cost to remove? Cut by rate of change The instinct is to group things that look alike. Look-alike grouping produces a utils module containing business logic, and a models directory whose contents change for six unrelated reasons. Group what changes together, for the same reason. Volatile apart from stable. Policy apart from mechanism — the rule about what should happen apart from the machinery of making it happen. Hard problems isolated so the hardness has one address. The clearest signal a boundary is wrong: a single feature request keeps requiring edits on both sides of it, every time. Pull, transform, push The useful unit is a process: acquire data, turn it into other data, emit it. The three phases have opposite natures and should not be mixed. Pull and push meet the world. They fail, time out, arrive malformed, and can only be honestly tested against something real. Keep them thin and defensive, and hold low expectations of anything on the other side. Transform is where the decisions live. Pure, testable with literals, and it should be the large part. Business logic that drifts into the operational phases becomes untestable by accident. Effects described as data, then performed at the edge, stay inspectable — a decision you can print is a decision you can test. The boundary between phases is where invariants get enforced: strong at the edges means the interior can be understood on its own. Three things a transform can do Accrete — add information. Now more is known than before. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills bfollington/decomposition