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** — prior art is dead or ambiguous: name exactly what
  to read (usually the corpse's issue tracker) before writing a line of code.

Follow with the one concrete next step. Render the brief in chat per
`references/brief-template.md` (read it at this step), save it to
`out/priorart/<idea-slug>-<YYYY-MM-DD>.md` (date via `date +%F`, never
guessed; create the folder if needed), and append one line to
`out/priorart/checked.md` — the memory Step 0 reads. Committing either is
the user's call.