novelty-check · diff
git:20260710.c3f9813 to git:20260826.78ad58d
36 added, 5 removed. Audit A to A.
---
name: "novelty-check"
description: "Verify research idea novelty against recent literature. Use when user says \"查新\", \"novelty check\", \"有没有人做过\", \"check novelty\", or wants to verify a research idea is novel before implementing."
---
> Override for Codex users who want **Gemini**, not a second Codex agent, to act as the reviewer. Install this package **after** `skills/skills-codex/*`.
# Novelty Check Skill
> **Gemini overlay assurance:** `review_independence: cross-family` and `acceptance_status: accepted`.
Check whether a proposed method/idea has already been done in the literature: **$ARGUMENTS**
## Constants
- **REVIEWER_MODEL = `gemini-review`** — Gemini reviewer invoked through the local `gemini-review` MCP bridge. Set `GEMINI_REVIEW_MODEL` if you need a specific Gemini model override.
## 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 would need to be novel:
- 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, search using ALL available sources:
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
- Include year filters for 2024-2026
2. **Known paper databases**: Check against:
- ICLR 2025/2026, NeurIPS 2025, ICML 2025/2026
- Recent arXiv preprints (2025-2026)
3. **Read abstracts**: For each potentially overlapping paper, WebFetch its abstract and related work section
### Phase C: Cross-Model Verification
Call REVIEWER_MODEL via `mcp__gemini-review__review_start` with high-rigor review:
```
mcp__gemini-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__gemini-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 exhaustively; judge calibrated. Two failures waste months equally:
+ passing an idea a published paper already contains, and killing a viable idea
+ because the territory has neighbors.
+ 1. Proximity is information, not a verdict. Someone working nearby goes in the
+ report; it is not by itself a reason to reject.
+ 2. ABANDON has exactly one qualification: a specific published paper already
+ contains this result — name that paper. No named paper, no ABANDON.
+ 3. Crowded-but-deltaed is PROCEED: state the delta in one sentence a reviewer
+ could verify. Thin or contested delta is PROCEED WITH CAUTION — say what
+ would make it carry, not why it should die.
+ 4. Concurrent or competing work is not a veto. That is a race — report it and
+ let the user decide whether to run it.
+ 5. A direct attack on a central problem is legitimate novelty when nobody has
+ executed it well. "This area is hot" does not mean "this area is taken."
+ 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] — Novelty: HIGH/MEDIUM/LOW — Closest: [paper]
2. [Claim 2] — Novelty: HIGH/MEDIUM/LOW — Closest: [paper]
...
### Closest Prior Work
| Paper | Year | Venue | Overlap | Key Difference |
|-------|------|-------|---------|----------------|
### Overall Novelty Assessment
- - Score: X/10
- - Recommendation: PROCEED / PROCEED WITH CAUTION / ABANDON
+ - 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: crowded-but-deltaed ground is PROCEED; ABANDON must name the paper)
- Key differentiator: [what makes this unique, if anything]
- Risk: [what a reviewer would cite as prior work]
### Suggested Positioning
- [How to frame the contribution to maximize novelty perception]
+ [State the delta honestly in one sentence a reviewer could verify]
```
### Important Rules
- - Be BRUTALLY honest — false novelty claims waste months of research time
- - "Applying X to Y" is NOT novel unless the application reveals surprising insights
+ - 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.
+ - "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