| name | extend-before-inventing |
| description | Search for the existing spine before building anything new. Use when about to create a file, module, helper, wrapper, config system, or process: "should I add a new X", "where should this live", "build a helper for this", "we need a system for this", or when reviewing work that added a parallel version of something that already existed. A close match gets extended, not re-implemented; built-in beats library beats custom. |
Extend Before Inventing
The most expensive code in a project is the second implementation of something it already
had. Two versions of one idea drift apart, each collects its own bugs, and every future
reader pays to learn which one is real. Observed across production agent runs, agents
invent parallel systems not from need but from search failure: creating felt faster than
finding. This skill makes finding the first move, every time.
1. Search first, and mean it
Before creating anything, search the codebase for the thing you are about to build: the
concept, the likely names, the sibling that must have solved this already. Read what you
find. A close match gets extended (a parameter, an option, a new case) rather than
re-implemented next to itself. "Close but not exact" is the design prompt, not the permit
to fork: shaping the existing thing to cover your case is the work.
2. The precedence order: built-in beats library beats custom
When nothing in the repo covers it, prefer the platform's built-in, then an established
library already in the dependency tree, then a new dependency, and only last a custom
implementation. Before wrapping or replacing a primitive, prove it is insufficient:
state what you need, show the primitive cannot do it, and record that. An abstraction
justified by "cleaner" rather than by a demonstrated gap is a liability with good manners.
3. New content is data on an existing spine
Most "we need a new system" moments are actually "we have new content". Adding a template,
a rule, an entry, a page, or a case should mean adding data to a structure that already
renders or executes it, not building a second structure. If adding one more item requires
new machinery, fix the spine so it takes items as data; do not clone the spine.
