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.

Novelty Check Skill Check whether a proposed method/idea has already been done in the literature: $ARGUMENTS Constants REVIEWER MODEL = gpt 6 astra — Model used via Codex MCP. Must be an OpenAI model (e.g., gpt 6 astra , 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 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, 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: 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. Phase D: Novelty Report Output a structured report: 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 arranged to reveal something unknown are novel. "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 ).

novelty-check