melech-buy-vs-build

# Buy vs Build An agent asked to "add background jobs" will happily write a `tasks` table, a polling worker, a retry column, and a dead-letter flag. It works. It is also BullMQ, or Trigger.dev, or Cloud Tasks, or the queue library already sitting in `package.json` — rebuilt badly, and now owned forever. Nobody makes the call deliberately. Repo-level review only ever asks *"does this already exist in our code?"*, and model memory answers external questions with confident, stale, sometimes invented package names. The expensive, hard-to-reverse decision — own the implementation, or hand the capability to a third party — gets made by default instead of on evidence. `melech-buy-vs-build` owns that decision. It looks **outward** — finding what the rest of the world already shipped for the capability, verified against live sources — and it runs one **inward** check first: *adopt-vs-rebuild*, is this already covered by a dependency or vendor you already have? Then it brings back a shortlist and a verdict: adopt, or keep building. Think *"is there an AI for that?"* — but for the build-vs-buy call, and grounded in evidence instead of vibes. --- ## Two Intents Both intents are **outward** research feeding one build-vs-buy verdict. Whichever fires, run the inward **adopt-vs-rebuild** check first (step 2) — a capability you already own beats anything you would go find or build. | Intent | Trigger | Goal | |---|---|---| | **Intercept** | Code, a plan, or a diff exists and may be re...