Skip to content
Back to skills

Novelty Check

ASecurity

Check a research idea against recent prior work and identify closest overlaps. Use to assess novelty before implementation; requires literature evidence.

  • 3 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 19, 2026
researchgodatabasebackend

Works with

  • claude code
  • mcp

Security analysis

A100/100

Scanned October 19, 2026

npx -y skills add Soceremite/EvoInquiry --skill novelty-check --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Novelty Check?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Novelty Check
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/soceremite-novelty-check-evoinquiry/badge)](https://www.skillsdirectory.com/skills/soceremite-novelty-check-evoinquiry)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: "novelty-check"
description: "Check a research idea against recent prior work and identify closest overlaps. Use to assess novelty before implementation; requires literature evidence."
---

> Override for Codex users who want **Claude Code**, not a second Codex agent, to act as the reviewer. Install this package **after** `skills/skills-codex/*`.
>
> Verify the actual returned reviewer identity before recording `review_independence: cross-family`. A phase receipt may record `acceptance_status: accepted` only after a positive verdict and the required evidence closure. Negative, unavailable and budget-stop outcomes grant no phase acceptance; same-family responses retain the base provisional contract.

<!-- EVO-INQUIRY:BEGIN -->
For research work, read [EvoInquiry](../shared-references/evo-inquiry.md),
or reuse it if already loaded and unchanged in this session. Apply relevant
principles within the user's scope and this skill's existing outputs, review
standards, and recovery contracts. Carry them into nested research tasks and
reviewer briefs. Continue authorized work through its necessary steps; honor
budgets, blocking checkpoints, and stopping conditions.
<!-- EVO-INQUIRY:END -->


# Novelty Check Skill

Check whether a proposed method/idea has already been done in the literature: **$ARGUMENTS**

## Constants

- **REVIEWER_MODEL = `claude-review`** — Claude reviewer invoked through the local `claude-review` MCP bridge. Set `CLAUDE_REVIEW_MODEL` if you need a specific Claude model override.
- **REVIEWER_BACKEND = `claude-review`** — reviews route through the claude-review MCP (Claude family; cross-family for a Codex executor).

## Instructions

Given a method description, systematically verify its novelty:

### Phase A: Extract Key Claims
1. Read the user's method description
2. Identify 3-5 core technical claims that carry the claimed delta:
   - What is the method?
   - What problem does it solve?
   - What is the mechanism?
   - What makes it different from obvious baselines?

### Phase B: Multi-Source Literature Search
For each core claim, choose sources and search variants appropriate to its discipline and required coverage. Use the literature-evidence reference and record actual coverage:

1. **Web Search** (via `WebSearch`):
   - Search arXiv, Google Scholar, Semantic Scholar
   - Use specific technical terms from the claim
   - Try at least 3 different query formulations per claim
   - Use a current, question-appropriate time window and include relevant foundational work

2. **Known paper databases**: Check against:
   - Relevant journals, conference proceedings and primary-source archives for this field
   - Recent preprints and subsequent versions or corrections where relevant

3. **Read abstracts**: For each potentially overlapping paper, WebFetch its abstract and related work section

### Phase C: Fresh-Agent Verification (verify actual reviewer family and evidence closure)
Call REVIEWER_MODEL via `mcp__claude-review__review_start` with high-rigor review:
```
mcp__claude-review__review_start:
  prompt: |
    [Full novelty briefing + prior work list + specific novelty questions]
```

After this start call, immediately save the returned `jobId` and poll `mcp__claude-review__review_status` with a bounded `waitSeconds` until `done=true`. Treat the completed status payload's `response` as the reviewer output, and save the completed `threadId` for any follow-up round.
Prompt should include:
- The proposed method description
- All papers found in Phase B
- Ask: "Is this method novel? What is the closest prior work? What is the delta?"
- The NOVELTY VERDICT LIMITS block below, verbatim — the reviewer judges under it

### The verdict limits

Copy this block **verbatim** into the reviewer's briefing; the report in
Phase D is judged under it too.

```
=== NOVELTY VERDICT LIMITS (these bound how you judge, never how widely you search) ===
Search within the question and declared resource boundary; report coverage.
1. Assess closest work and the concrete difference using verified sources.
   Proximity is not duplication; unfamiliarity is not novelty.
2. Report search_coverage: adequate | partial | unavailable and
   overlap_assessment: direct | partial | none_located | unknown.
3. ABANDON for duplication requires a named, checked work containing the
   claimed contribution. Explain the actual overlap, not only similar keywords.
4. PROCEED means an evidenced difference warrants further investigation;
   it is not proof of novelty or validity. If search or the difference is
   unresolved, use PROCEED WITH CAUTION and identify the missing check.
5. Keep the evidence assessment separate from the decision to spend resources.
   A limited next search can be worthwhile with novelty unknown. Do not mark
   incomplete coverage as an affirmative novelty verification.
6. Do not invent overlap or a favorable difference to satisfy a gate. Preserve
   the actual review source and unresolved issues; continuing exploration is
   not scientific acceptance.
Say plainly when an idea clears the check. Do not manufacture overlap.
```

### Phase D: Novelty Report
Output a structured report:

```markdown
## Novelty Check Report

### Proposed Method
[1-2 sentence description]

### Core Claims
1. [Claim 1] — Closest: [paper] — What stays unknown or different: [delta]
2. [Claim 2] — Closest: [paper] — What stays unknown or different: [delta]
...

### Closest Prior Work
| Paper | Year | Venue | Overlap | Key Difference |
|-------|------|-------|---------|----------------|

### Overall Novelty Assessment
- Score: X/10 (anchor: 5/10 = has clear neighbors but a defensible delta worth
  a pilot; reserve 1-3 for results a named published paper already contains)
- Recommendation: PROCEED / PROCEED WITH CAUTION / ABANDON (per the verdict
  limits: PROCEED requires a checked difference; uncertain coverage is CAUTION; duplication requires a checked paper)
- Key differentiator: [what makes this unique, if anything]
- Risk: [what a reviewer would cite as prior work]

### Suggested Positioning
[State the delta honestly in one sentence a reviewer could verify]
```

### Important Rules
- Two failures waste months equally: a false novelty claim, and a viable idea
  abandoned because the territory has neighbors. Be brutally honest in both
  directions — and when an idea clears the check, say so plainly.
- Novelty can live in the combination or the finding even when every
  individual claim rates LOW — judge the idea, not each claim in isolation.
  Known parts may yield a novel finding only when that finding and its difference from checked prior work are verified; a new arrangement alone is insufficient.
- "Applying X to Y" earns novelty by what the application reveals — a
  non-obvious interaction, failure mode, or insight. Judge the revelation, not
  the template.
- Check both the method AND the experimental setting for novelty
- If the method is not novel but the FINDING would be, say so explicitly
- Always check the most recent 6 months of arXiv — the field moves fast

## Review Tracing

After each `mcp__claude-review__review_start` or optional `oracle-pro` reviewer call, save the trace following `../shared-references/review-tracing.md`. Write files directly to `.ei/traces/novelty-check/<date>_run<NN>/` and record searched claims, closest papers, reviewer route, raw response, and final novelty decision. Respect the `--- trace:` parameter when present (default: `full`).

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.