/priorart

name: priorart
description: >-
  Prior-art check before you build — does this idea already exist? Takes a
  project/tool/library idea, reframes it in the vocabularies different
  communities would use, searches where builders publish (code registries,
  Show HN, arXiv), traces each match one dependency-layer down to the real
  incumbent, and returns a locator-backed landscape plus exactly one
  verdict: Build / Fork X / Contribute to Y / Use Z / Investigate first.
  Checked ideas persist in out/priorart/checked.md, so re-checking one opens
  with what changed. Keyless. Use for "does something like X already
  exist", "has anyone built this", "am I reinventing the wheel", "check
  prior art before I build" — e.g. "/priorart <idea>". For your existing
  project vs its peers use scout; for choosing between named options use
  verdict.

priorart — who built this before me?

`/priorart <idea>` — check whether the idea already exists `/priorart` — list ideas already checked (from `out/priorart/checked.md`)

Answer one question: **has someone already built this — and what does that mean for whether you should?** The deliverable is one honest verdict with the landscape as its evidence, not a survey. Advisory throughout: it recommends; the human decides what, if anything, gets built.

Step 0 — Check the memory

Read `out/priorart/checked.md` if it exists. If this idea (or a close variant) was checked before, open with **"Since last check"**: re-verify the previous brief's findings (status changes, new arrivals since that date) instead of redoing the whole search. The pipeline below is for ideas not yet in the log.

Step 1 — Restate before searching

Restate the idea in one sentence — what it does, who it's for, and the constraint that makes it distinctive — and confirm it with the user. Too vague to restate → ask exactly **one** clarifying question, offering at most 3 example dimensions (it's a question, not a questionnaire).

Step 2 — Vocabulary before queries

Before any search, write 6–10 framings of the idea from distinct vantage points: the builder's terms, the end-user's terms, the academic field's terms, the infrastructure/implementation terms, and the adjacent discipline that likely solved this first. Map each planned query to a framing — this is what prevents five queries landing in the same semantic neighborhood and calling it coverage. Most "novel" ideas are existing ideas under a different name; the framings are where that name gets found.

Step 3 — Search where builders publish

Budget: **≤10 queries for the whole check, with 1–2 held back for Step 4's lead-tracing.** Fan out 2–3 sub-agents grouped by venue class, each briefed with 2–3 framings and an explicit share of the rest (say the numbers; agents without a stated allowance keep searching). Together the briefs cover every vantage point from Step 2 — framings left out of every brief defeat the point of writing them:

• **Registries & code** — GitHub/GitLab search, PyPI, npm, crates.io,

Hugging Face for ML.

• **Products & launches** — Show HN, Product Hunt, the subreddits where the

target users live. Product venues matter because the incumbent may be closed-source; this stays a builder's check — market sizing and business-model analysis are a different job and out of scope.

• **Writing** — arXiv/Scholar for academic framings, engineering blogs.

When the domain has a high-signal venue where serious players cite the incumbent (model cards, RFCs, regulator guidance), check it over generic search.

Every finding returns with a **locator**: the URL plus a fetched signal — last-commit/push date, downloads, release date. A signal that couldn't be fetched is reported as "unknown", never asserted; one repo with real usage beats any listicle.

Step 4 — Trace one layer down

Read what each direct match is built on: "wraps X", "built on top of W", "official harness for Z" are leads, not background — follow each with a dedicated query. This check fails most often not at finding projects but at stopping one layer too early and crowning a thin wrapper the incumbent. Stop early only when the landscape is clear after 3–4 queries AND at least one of them followed such a lead; at the cap without confidence, say so plainly and report what was found.

Step 5 — The landscape

Cluster findings into four buckets, **max 3 rows each** — curation, not a dump: **direct matches** · **adjacent solutions** · **partial solutions** · **abandoned attempts** (note when each died and, where findable, why). Each row: Name | Link | Status | Relevance, where the Status cell quotes its fetched locator ("last commit 2026-05", "1.2k dl/mo") or says "unknown" — liveness is looked up, never assumed. Found nothing for a bucket? Leave it empty and say so; **never invent a competitor** — "no direct prior art found, searched: <where>" is a valid, useful result. But treat a clean landscape from same-neighborhood queries as a local minimum, not a green light: three queries returning the same project means a semantic cluster was searched, not the space — vary the framing before believing the blank.

Then extract the **standard patterns** across matches (common architecture, libraries, naming, pricing): the default playbook the user would be competing with or building on. Close with one honest **differentiator paragraph**: name the real differentiator, or say plainly there isn't one — manufactured novelty costs the user their next quarter.

Step 6 — One verdict, then the record

State exactly one of these in the verdict section's heading itself — `## Verdict: <one of the five>` — no hedging (nuance goes after the verdict, not instead of it):

• **Build it** — genuine gap, and the differentiator is real.
• **Fork X** — the right base exists but has diverged from the need.
• **Contribute to Y** — the delta is a feature, not a project.
• **Use Z** — it exists; wanting to have built it isn't a reason to build it.
• **Investigate first** — pr