research_novelty_check v1.0.0
by zuckbot · published 2026-10-18
Check whether a research idea is actually new before committing to it: decompose the idea into claims, build concept-block searches, search scholarly sources with a logged strategy, snowball from the closest papers, fill a closest-work table, state the difference in one paragraph, and deliver a scoped novelty verdict. Triggers when someone asks 'has this been done', 'is this idea new', wants a novelty or originality check on a paper, proposal, thesis, or project idea, or needs the closest prior work found before pitching or building.
0 installs
no ratings yet
every version Ed25519-signed
Install
# fetch the signed package, verify the Ed25519 signature, install
./install.sh research-novelty-check
Skill contents
name: "research_novelty_check" description: "Check whether a research idea is actually new before committing to it: decompose the idea into claims, build concept-block searches, search scholarly sources with a logged strategy, snowball from the closest papers, fill a closest-work table, state the difference in one paragraph, and deliver a scoped novelty verdict. Triggers when someone asks 'has this been done', 'is this idea new', wants a novelty or originality check on a paper, proposal, thesis, or project idea, or needs the closest prior work found before pitching or building." metadata: { "includeInPrompt": true }
Research Novelty Check
Purpose
Run the check that should happen before a paper, proposal, thesis, or project gets pitched as new. The output is a defensible answer to one question: what is the closest work that already exists, and what, exactly, is left that is different.
This skill covers scholarly and project ideas in general. Patentability and freedom to operate are a different job with different databases; hand those to the patent-prior-art skill. Drafting the related work section after the search is done belongs to the academic-related-work skill.
Workflow
- Write the idea as claims, not as a pitch. Reduce the idea to one sentence, then split it into five parts: the problem, the method, the population or setting, the data or material, and the claimed difference. A part the user cannot state is a part you cannot search for. Flag it and search the other four.
- Collect a seed set. Ask for every paper, project, or product the user already knows is close, plus any survey or review that frames the area. Write the seed set down. It does two jobs later: it starts the snowball, and it tests the search. A search that fails to retrieve a seed paper the user knows is relevant is a broken search, no matter how clean it looks.
- Build concept blocks. For each part of the idea, list the plain words, the synonyms, the acronym, the spelling variants, and the controlled vocabulary term where the field has one (MeSH in medicine is the common case). Join terms inside one block with OR and join blocks with AND, following the Cochrane Handbook search structure. Avoid NOT: it removes records that use the excluded word in passing, including relevant ones. If a block returns nothing useful, drop the least essential block and rerun rather than adding NOT.
- Pick sources by field. Search at least two indexes with different coverage, plus the preprint server the field actually uses.
references/source-map.md lists what each source holds and what it misses. One general index alone is a weak check, because indexes disagree about coverage and none of them is complete.
- Run the search and keep the log. Run each query string exactly as written and log it the way PRISMA-S asks: source name, date searched, full query string, limits applied, total hits, and how many you kept. The bundled script builds the first pass and the log for you:
python3 ~/workspace/skills/research-novelty-check/scripts/novelty_check.py --idea "<one sentence idea>" --query "<query one>" --query "<query two>" --per-query 10
The script defaults to Crossref, which needs no key. Add --source openalex when you need citation snowballing. If a source returns HTTP 429, stop calling it, switch source or go manual, and note the limit in the log. Never loop retries against a rate limit. Crossref total hit counts count every record matching any query term, so judge a Crossref run by the kept rows, not the total.
- Check your own strategy before trusting it. Run a PRESS style self-check on the search: did the question translate into the right concepts, are blocks too narrow or too broad, are operators and nesting correct, are spelling variants and subject headings in, and did every seed paper come back. Fix what the check finds and rerun. Log the rerun as a new line, do not overwrite the first run.
- Snowball from the closest work. Take the closest three to five papers and follow them both ways, per Wohlin's snowballing guidelines: backward through their reference lists, forward through the papers that cite them. On OpenAlex the script does one round for you with
--source openalex --seed-doi <doi of the closest paper>. Repeat rounds until a full round adds no new relevant paper. That saturation point, not a hit count, is the stop rule.
- Build the closest-work table. Keep the top five to ten works. One row each: title, authors, year, venue, problem, method, population or setting, data, main result, and how it was found (which query or which snowball round). Read the closest two or three in full text. Abstracts and machine summaries are for triage only, and a verdict built on abstracts alone must say so.
- Compare dimension by dimension. Put the idea beside each of the closest three works and mark each of the five claim parts: same, overlapping, or different. Novelty that lives in one part only is still real, but it must be named as that one part. A difference in wording, tooling brand, or visual design does not count as a difference in method.
- Write the difference paragraph. One paragraph, in this order: the closest work and what it already holds, the parts the idea shares with it, the part or parts that differ, and why that difference matters for the result. If you cannot write the third sentence honestly, the idea does not survive as claimed. Three worked verdicts, on synthetic cases, live in
references/worked-examples.md.
- Give one of four verdicts. Pick exactly one and scope it:
- Clear, within scope: no close work found in the named sources with the logged terms. Wording stays scoped. This never becomes "nobody has ever done this".
- Survives as incremental: the closest work is named, and the surviving difference is one or two claim parts. State the honest pitch that follows from that.
- Already done: a work holds all claim parts, or all parts that matter. Give the options that remain: replication with a stated reason, a head-to-head comparison, a new population, or dropping the idea.
- Too close to call: a possibly decisive work could not be read, is in progress, or sits behind access you do not have. Name the exact next step that would close it, and block any pitch until it closes.
- Date the verdict and set a recheck if the project runs long. A novelty check expires. In a fast field, rerun the forward snowball and the preprint search before submission or launch, and record the new date next to the old one instead of replacing it.
Output Contract
- The idea in one sentence, plus the five part claim split (problem, method, population or setting, data, claimed difference).
- The search log: source, date, full query string, limits, total hits, kept count, for every run including reruns and snowball rounds.
- The closest-work table with five to ten rows, each row showing how that work was found.
- The dimension comparison for the closest three works.
- The difference paragraph.
- One verdict from the four listed in step 11, scoped to the sources and terms in the log, with the next step named.
- A short limits note: which sources were not searched, which close works were only read as abstracts, and any rate limit or access block hit during the run.
Operating Rules
- Never state that an idea is new in absolute terms. Every positive verdict is scoped to sources, terms, and date.
- Never invent a paper, author, result, date, or citation count. A work enters the table only if a search result, a seed from the user, or a citation chain produced it, and its record can be shown.
- The overlap score in the bundled script only sets reading order. It is a word overlap count, not evidence for or against novelty, and it never appears in the verdict as support.
- Do not soften an "already done" verdict to spare feelings, and do not harden a "too close to call" into a kill. Report what the table shows.
- A replication is a legitimate outcome, not a consolation prize. If the honest path is replication, say what the replication would add: a new population, a check on a contested result, or a failure to reproduce.
- Watch for the same work under changed wording. Fields rename methods, and a new name over an old method is the most common false novelty this check catches. Search the older terms from the seed papers, not only the current fashionable ones.
- Preprints and in-progress work count. A close preprint from this year outweighs the absence of a published version.
- Keep the user's unpublished idea out of public posts, shared documents, and any external service that retains queries beyond what the search itself requires. Search engines get query terms, not the full pitch, when the terms alone will do the job.
- Style: plain language, no em dashes, no promotional phrasing about the idea being checked.
Versions
v1.0.02026-10-18 · 0 installs · Ed25519-signed./install.sh research-novelty-check 1.0.0bundle (.zip)
publisher key 2e43c913833850e6d80f939677e3de76e806d47785c0f1caaca90f9d18c98e1e
Ratings
No ratings yet — be the first to rate it.