dont-reinvent-the-wheel

# Don't reinvent the wheel

A prior-art check. Runs before committing to build something "new" — catches
the case where the user's own repos (especially the meta/infra ones) already
solve most of the problem, or where an established external project already
does.

## When to use

Fires whenever the user proposes a new tool, script, automation, recurring
task, or skill — before any scaffolding, file creation, or scheduling
happens. Skip it for ordinary bug fixes or feature work inside a codebase
that's already been identified (there's nothing to dedupe against there).

## Step 1 — pull keywords, don't guess scope

Extract 2-4 concrete keywords from the idea (e.g. "PR queue cleaner" →
`pr`, `merge`, `review`, `ci status`). Don't ask the user to restate it —
work from what they already said.

## Step 2 — search the user's own ecosystem first

Check `~/code` for prior art, in this order:

1. **Meta/infra repos first** — these are where cross-cutting tooling lives:
   `dev-forge` (standards layer, cron conventions, agent/skill conventions,
   work-intake process), `repo-health` (.NET repo audit/standardizer),
   `homelab-health` (deterministic fact-collector, avoids burning AI calls
   on broad discovery), `homelab-gitops` (homelab infra source of truth).
   Read each repo's README first for a fast yes/no on relevance.
2. Use `mcp__lumen__semantic_search` over `~/code` for the extracted
   keywords if available (preferred over raw grep/find per this project's
   tooling setup); fall back to `grep -ril` / `find` across `~/code` scoped
   to script and doc files if semantic search isn't available.
3. Look specifically for: existing scripts/cron jobs doing something
   similar, existing docs describing a convention for this class of
   problem, existing skills (`~/.claude/skills`, `dev-forge`'s
   `openclaw-forge/skills`) that already cover it.

Note: dev-forge's `workflows/work-intake.md` and
`templates/repository-finding.md` already define a formal "Duplicate
check" step for repo-audit findings — this skill is the lightweight,
conversational version of the same idea, not a replacement for that
process when working inside dev-forge's own formal intake.

## Step 3 — sanity-check against known current policy

Before recommending reuse of anything found, verify it against current
direction rather than trusting the doc at face value — conventions drift.
Known drift as of 2026-08-01: **Hermes is deprecated** (user has been
purging it for months; GitHub Issues is now the only work tracker), and
the old "autonomous workers never auto-merge" rule is outdated (current
rule: define goals up front, auto-merge is fine once met, with `main`
reserved for production and a separate `dev` branch for development).
If what you find still assumes Hermes or a blanket no-auto-merge rule,
flag it as stale rather than proposing it as-is.

## Step 4 — quick external check (only if nothing internal fits)

If the internal search comes up empty or thin, do a fast mental/web check
for whether an established open-source or SaaS project already solves this
class of problem well (e.g. Mergify/Kodiak/GitHub merge queue for PR
auto-merge, Renovate/Dependabot for dependency PRs). Mention it as an
option, not a mandate — the user may still prefer to own the tooling.

## Step 5 — report before building

Summarize findings compactly:

- **What already exists** (repo/file, one line on what it does)
- **What's missing / doesn't fit**
- **Recommendation** (reuse as-is / extend existing / build new because
  nothing fits / this is already solved externally, consider adopting)

Then hand the decision to the user — use `AskUserQuestion` with the
recommendation as the first, "(Recommended)"-labeled option, per this
user's standing preference for tappable choices over prose. Do not start
building until they pick.

## Non-negotiables

- Never silently build something new without first checking meta/infra
  repos — that's the whole point of this skill.
- Never assume a doc found during the search reflects current policy;
  cross-check against Step 3's known drift points and anything the user
  has said more recently in the conversation.
- Keep the report short — file paths and one-line summaries, not full
  file dumps.