novelty-check · diff
git:20260713.e67ae16 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.
argument-hint: "[method-or-idea-description]"
allowed-tools: WebSearch, WebFetch, Grep, Read, Glob, mcp__codex__codex
---
# Novelty Check Skill
Check whether a proposed method/idea has already been done in the literature: **$ARGUMENTS**
## Constants
- REVIEWER_MODEL = `gpt-5.6-sol` — Model used via Codex MCP. Must be an OpenAI model (e.g., `gpt-5.6-sol`, `o3`, `gpt-4o`)
## 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 Codex MCP (`mcp__codex__codex`) with xhigh reasoning.
When the method description plus the Phase-B paper list is more than a short
note, avoid pasting it inline into the MCP prompt. Write a dossier file such as
`NOVELTY_DOSSIER.md` (or a project-local equivalent) containing the method
description, core claims, candidate papers, and the exact questions below, then
send only the file path:
```
mcp__codex__codex:
model: gpt-5.6-sol
config: {"model_reasoning_effort": "xhigh"}
prompt: |
Read the novelty dossier at <absolute path to NOVELTY_DOSSIER.md> and
follow all instructions in it.
```
Dossier contents 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
- **Anti-hallucination for Closest Prior Work.** Every paper in the prior-work table must pass pre-search verification via `verify_papers.py` (canonical name resolved per [`shared-references/integration-contract.md`](../shared-references/integration-contract.md) §2; 3-layer arXiv / CrossRef / Semantic Scholar fallback inside the helper itself). Policy D1 (primary + degraded-output fallback): if the helper is unresolved **or** its invocation fails, tag candidate entries `[UNVERIFIED]` and surface the uncertainty rather than dropping them. Never fabricate arXiv IDs, DOIs, or titles from memory. Full protocol in [`shared-references/citation-discipline.md`](../shared-references/citation-discipline.md) § Pre-Search Verification Protocol.
## Review Tracing
After each `mcp__codex__codex` or `mcp__codex__codex-reply` reviewer call, save the trace following `shared-references/review-tracing.md` (Policy C — forensic; never silently skip). Use `save_trace.sh` (resolved per the chain in `shared-references/integration-contract.md` §2) or write files directly to `.aris/traces/<skill>/<date>_run<NN>/`. Respect the `--- trace:` parameter (default: `full`).