Library-First Development

Default position: someone has probably already built this, better, and maintains it. Hand-rolling means you now own the bugs, the edge cases, and the maintenance forever. So you research first and reach for the project library, framework feature, or official CLI/generator — and you only build it yourself when nothing genuinely fits, and you say why.

This is not "add dependencies carelessly." It's "don't reinvent the wheel, and don't bolt on a junk wheel." Library-driven development means: use the ecosystem's maintained code path first, prefer mechanical generation for mechanical files, then vet hard.

The workflow

1. Name the capability in one sentence ("parse and diff ISO-8601 durations", "rate-limit outbound calls with backoff", "create a database migration for a new table"). If a mature library or framework tool category exists for it, you're in scope.
2. Check the project first — dependency files, framework docs, local scripts, bin/, scripts/, package scripts, Makefiles, task runners, and existing generated-file conventions. Prefer what the repo already uses.
3. For mechanical output, check the CLI/generator before editing files. Migrations, scaffolds, models, controllers, routes, SDK clients, generated types, config stubs, locks, snapshots, and boilerplate should usually start with the official command, not a hand-created file.
4. Find real candidates — use [[research]]. Get actual maintained options from primary sources (official docs, registries, GitHub, the ecosystem's "awesome" lists), not a half-remembered name.
5. Vet before adopting (below). A popular library that's abandoned or risky is not the answer.
6. Adopt the best fit, use the CLI, or hand-roll with a written reason (below).

CLI-first scaffolding

If the work creates or updates files that a framework normally generates, the first implementation question is: