# Priorart > 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 ". For your existing project vs its peers use scout; for choosing between named options use verdict. - Skill: `duthaho/priorart` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add duthaho/priorart` - Raw SKILL.md: https://api.skillmd.com/api/skills/duthaho/priorart/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: duthaho (https://skillmd.com/u/duthaho) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/duthaho/priorart --- # priorart — who built this before me? `/priorart ` — 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: " 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: ` — 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/-.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.