R&D project initiation pre-screen and proposal audit for go/no-go decisions, public novelty boundary review, innovation-point assessment, and evidence-backed project rating. Use when the user asks for project initiation pre-screening, initiation review, proposal review, R&D project evaluation, proposal-package review, novelty pre-screening, innovation-point review, project rating, or wants a formal review around a concrete project, proposal, or research-package material set — even if they only provide the proposal and do not explicitly say "review".
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
R&D project initiation pre-screen and proposal audit for go/no-go decisions, public novelty boundary review, innovation-point assessment, and evidence-backed project rating. Use when the user asks for project initiation pre-screening, initiation review, proposal review, R&D project evaluation, proposal-package review, novelty pre-screening, innovation-point review, project rating, or wants a formal review around a concrete project, proposal, or research-package material set — even if they only provide the proposal and do not explicitly say "review".
argument-hint
[project proposal, initiation report, or review request]
provider
Patsnap Eureka
compatibility
Designed for Claude Code, Codex, and similar agent runtimes that can read/write local files and call whatever search tools are available.
deliverable-default
Structured Markdown review report plus novelty note and traceable evidence files; docx/pdf export is optional.
fallback-policy
Start from proposal materials; prefer structured patent/paper retrieval when available; otherwise downgrade through domain-specific sources, Exa, Tavily, Brave, web, and a known-URL reader without blocking the run.
R&D Initiation Review
Provided by Patsnap Eureka.
Use this skill when the decision object is a concrete project, proposal,
innovation package, or initiation document set. The goal is to judge whether
it should move forward, how similar it is to public prior work, which
innovation claims still stand, and what evidence or materials are still missing.
The customer-visible value should land first on four questions:
Is this project worth advancing?
How close is it to public prior work?
Do the innovation claims hold up?
What is still missing before the next gate?
Use When
The user provides a project or proposal and asks whether it is worth advancing
Formal initiation review report for a concrete project
Pre-screening / public novelty pre-check / client-facing pre-screen
Go/no-go or budget-release recommendation around a proposal
If the request is for pre-screening, novelty pre-check, overlap check,
"is it worth advancing", or an early customer-facing review → default to screen
If the request is for expert review, go/no-go, budget release, evidence
sufficiency, or committee-ready bundle → default to assurance
Otherwise → default to review
Core Principles
Proposal As Input, Not Truth
The proposal is the starting point for extraction, not a source of verified
facts. A proposal claim does not become a review conclusion unless it is either
corroborated externally or explicitly labeled as proposal-only.
Four-Layer Evidence Separation
Every substantive claim in the review must be tagged as one of:
Proposal-stated: what the proposal says (quoted or summarized)
Externally corroborated fact: confirmed by patent, paper, or official source
Evidence-backed inference: reasonable conclusion from multiple signals
Open gap: insufficient evidence — state what is missing and what would resolve it
Do not let proposal-stated claims silently become review conclusions.
Novelty As First-Class Visible Module
Novelty search is not a side effect of baseline retrieval. The review must
clearly state:
Novelty-search scope (databases, time window, field scope)
Main comparison objects (prior art, prior routes, existing solutions)
Point-by-point overlap assessment
Residual differentiators
Explicit novelty judgment level for each major claim
Search limitations and unsearched areas
When novelty is downgraded because of prior art, build a structured
differentiation-boundary table showing overlap, residual differentiators,
and replacement risk.
Material Completeness As First-Class Module
Even when the platform cannot solve the client's full data governance problem,
the report should clearly say which missing materials or data are currently
blocking:
novelty or overlap boundary judgment
feasibility judgment
next-step initiation actions
If internal archives or non-public project databases are not available, say so
explicitly. Do not imply that a public-only retrieval pass proves exhaustive
internal duplicate-project exclusion.
Tool Routing And Fallback
This skill works across multiple tool environments. Before retrieval, detect
which capabilities are available and select the highest tier that is reachable.
Use the host's best structured patent and paper retrieval stack to test
novelty, feasibility, and frontier evidence around normalized innovation points.
This usually means structured search plus record-level deep fetch.
Evidence grade: S/A
Tier 2 (Fallback): Exa Search + Companion Skills
Use the host's best broad web research tool plus scholarly or finance
companion lanes when available.
Exa, Tavily, Brave, official filings, and domain-specific research databases
are good examples, not hard requirements.
Evidence grade: A/B
Coverage loss vs Tier 1: no structured patent field search, no assignee
filtering, novelty conclusions less precise
Tier 3 (Fallback): Generic Web Tools
Use generic web search and page/PDF reading tools available in the host.
Evidence grade: B/C
Tier 4 (Minimum): Pure LLM + Proposal Materials
No external tools required
Evidence grade: C/U
The review can still extract and organize proposal claims, identify logical
gaps, and flag what external evidence would be needed
Routing Rules
Always start from proposal materials (Tier 0) regardless of tool availability.
Select the highest available external tier for verification.
When a tier is unavailable, explicitly state the downgrade.
Do not pretend a public-only pass equals full duplicate-project exclusion.
When using Tier 3 or 4, increase explicit gap statements and reduce
confidence on novelty and completeness claims.
Minimum Working Files
Create or update these files in a writable run folder:
Every claim must cite its source type and identifier, e.g., [Patent: CN1234567B],
[Paper: DOI or title], [Web: source name], [Proposal: section/page].
Formal Output Rules
For formal review audiences such as large enterprises, public-sector bodies,
and research institutions:
Remove empty opening filler such as trend-setting or era-setting lead-ins.
Remove promotional language and replace it with concrete review judgments.
Replace vague attribution with named evidence and explicit citations.
Rewrite formulaic paired constructions into direct standalone judgments.
Do not leak control-plane jargon such as proposal-only, prior-art,
assurance, gate, or owner into the main report unless the term is
necessary and clearly explained.
Headings and body text should use plain formal wording suitable for a written
review or committee memo.
When novelty is a live decision question, promote the method and point-by-point
comparison into novelty-note.md. A suitable file title is
Public Novelty and Prior-Art Review Note or Novelty and Benchmarking Appendix.
Completion Gates
All Modes
Concrete project object identified (not just a topic)
Proposal-stated claims extracted before external search
Four-layer evidence separation maintained throughout
Tool tier and coverage limitations explicitly stated
Material completeness assessment present
If internal archives are unavailable, the duplicate-project boundary is marked as unverified
Screen Mode Additional
Go/no-go recommendation present with conditions
Novelty boundary summary present
Key gaps and next steps identified
Review Mode Additional
At least 2 patent searches and 1 paper search executed per innovation point
Novelty comparison table present
Every major claim has a traceable source citation
Innovation Mode Additional
Each innovation point assessed individually
Differentiation boundary table present
Residual differentiators explicitly stated per point
Assurance Mode Additional
Scoring rubric explicit and traceable
Stage-gate matrix with conditions, owners, and consequences
Counterevidence pass completed
Technical decomposition covers main chain, dependencies, and failure modes
Guardrails
The proposal is an input object, not a source of truth. Do not let proposal
rhetoric substitute for external evidence.
Do not imply that a public-only retrieval pass proves exhaustive coverage or internal
duplicate-project exclusion.
Do not let raw search hit counts or internal ledger jargon become the main
management-facing argument.
Treat proposal promises, roadmap claims, and commercialization statements as
signals until corroborated.
Keep scoring as a support layer, not the main selling point. Prefer direct
judgments (proceed / proceed with conditions / hold) over dense weighted scoring tables
in the main body.
When novelty is downgraded, do not stop at prose caution — build a structured
differentiation-boundary table.
Do not force a strong go/no-go when the evidence base is thin — prefer
conditional recommendations with explicit next-evidence-gathering steps.
Separate the novelty methodology (scope, queries, limitations) from the
novelty conclusion.
Do not mix proposal-stated claims with externally verified facts without
clear labeling.
For formal reports, do not leak control-plane jargon into the
management-facing narrative.
Treat internal duplicate-project exclusion as data-dependent — do not promise
it when internal project history is unavailable.
