@research-copilot/plugin 1.1.16 → 1.1.18

package/dist/skills/pre-submission-reviewer/references/latex-rules.md

@@ -0,0 +1,158 @@
+# LaTeX format rules
+
+## Table of contents
+
+1. File organisation
+2. Macro definitions
+3. Citations
+4. Labels and references
+5. Figures and tables
+6. Equations
+7. Quotation marks and dashes
+8. Revision conventions
+
+## 1. File organisation
+
+A multi-section paper should split content into files under a
+`sections/` directory, with `main.tex` using `\input{sections/...}`.
+Typical structure:
+
+```
+sections/
+figs/
+exps/
+algs/
+main.tex
+commands.tex
+bibfile.bib
+```
+
+A monolithic `main.tex` with everything inline is acceptable for
+very short papers but harder to version-control across multiple
+authors.
+
+## 2. Macro definitions
+
+Define macros for recurring strings: system names, method names,
+commonly misspelled words, or frequently used highlighting.
+
+Example in `commands.tex`:
+
+```latex
+\newcommand{\sys}{\texttt{Alpha-SQL}\xspace}
+\newcommand{\hi}[1]{\vspace{.25em}\noindent \textbf{#1}}
+\newcommand{\lgl}[1]{\textcolor{blue}{LGL: #1}}
+\newcommand{\revision}[1]{\textcolor{blue}{#1}}
+```
+
+Renaming becomes a one-line change rather than a find-and-replace
+across dozens of sections. When a system name changes mid-
+revision, the macro is the only edit required.
+
+## 3. Citations
+
+Rule L1: always use the non-breaking tilde between a word and its
+citation, to prevent awkward line breaks.
+
+| Bad | Good |
+|---|---|
+| `ResNet\cite{X}` | `ResNet~\cite{X}` |
+| `ResNet \cite{X}` | `ResNet~\cite{X}` |
+
+Multiple citations go inside one command:
+
+```latex
+Artificial Intelligence~\cite{xxxx, yyyy, zzzz}
+```
+
+Rule L2: follow the venue's citation style. ACL uses natbib with
+`\citep` for parenthetical and `\citet` for textual. Data
+management venues (SIGMOD, VLDB) use IEEE or ACM numeric styles.
+Convert before submission.
+
+Rule L3: bib entries must include conference name, year, pages,
+authors, title. Pull from DBLP for correctness.
+
+## 4. Labels and references
+
+Rule L4: labels use underscores and a prefix for readability.
+
+- `\label{fig:system_overview}` (good).
+- `\label{sec:intro}` (good).
+- `\label{system overview}` (bad; contains a space).
+- `\label{system-overview}` (bad; hyphens break some references).
+
+Rule L5: references also use the non-breaking tilde.
+
+```latex
+as shown in Figure~\ref{fig:system_overview}
+discussed in Section~\ref{sec:intro}
+```
+
+## 5. Figures and tables
+
+Rule L6: every figure and table must have a caption. Captions
+describe the finding, not just the setup, especially for
+experimental figures.
+
+Rule L7: default placement is top of page (`[t!]`). If the figure
+does not fit at the top, `[b!]` (bottom) is acceptable. Inline
+`[h]` placement rarely works; let LaTeX decide.
+
+Rule L8: figures use vector formats (PDF, EPS, SVG). Never insert
+PNG or JPG screenshots in the final paper; pixelation appears on
+zoom.
+
+Rule L9: always reference the figure or table in prose before it
+appears. "Figure 2 shows..." is the canonical pattern.
+
+## 6. Equations
+
+Rule L10: every numbered equation should be referenced in the
+prose at least once. If an equation is not referenced, either
+reference it or remove the numbering with `\begin{equation*}`.
+
+Rule L11: equation numbering should be contiguous within a
+section. Use `\label` on each numbered equation to allow
+rearranging without renumbering manually.
+
+## 7. Quotation marks and dashes
+
+Rule L12: use the LaTeX convention for quotation marks.
+
+- Double quotes: use `` `` `` for open, `` '' `` for close.
+- Single quotes: use `` ` `` for open, `` ' `` for close.
+- Never use the straight ASCII typewriter `"` character.
+
+Rule L13: dashes have three types in LaTeX; use each correctly.
+
+- Hyphen `-`: compound adjectives (high-efficiency, zero-shot).
+- En-dash `--`: number ranges (pages 10--15, 2024--2026).
+- Em-dash `---`: semantic break. Project rule: do not use em-
+  dashes in the body. Use commas, colons, or periods instead.
+
+## 8. Revision conventions
+
+For revision submissions, preserve the review history in
+dedicated files.
+
+```
+responses/
+  meta.tex
+  r1.tex
+  r2.tex
+  r3.tex
+```
+
+Mark revised text with `\revision{...}` (defined as a blue color
+macro). Mark revision pointers in the margins with `\marginpar`:
+
+```latex
+\marginpar[]{\revision{R1.W1}}{\revision{text}}
+\marginpar[\revision{R3.W2}]{}{\revision{text}}
+```
+
+Each `r<n>.tex` file opens with a summary table of the reviewer's
+comments and the sections that respond to them. Make the summary
+table the first content in the response file so reviewers can see
+at a glance what was done.

package/dist/skills/pre-submission-reviewer/references/logic-and-structure.md

@@ -0,0 +1,125 @@
+# Logic and structure rules
+
+## Table of contents
+
+1. Logic First rule
+2. Self-contained rule
+3. Leading Text rule
+4. Running Example rule
+5. Paragraph discipline
+6. Section-level consistency
+7. Failure patterns
+
+## 1. Logic First rule
+
+Every sentence has a purpose. Every two consecutive sentences have
+a connection. Every claim carries evidence. Every critique cites
+a ground.
+
+When reviewing a paragraph, ask for each sentence: what is this
+sentence trying to do? If the answer is vague, the sentence is a
+candidate for cutting or rewriting. When reviewing two consecutive
+sentences, ask: how does sentence 2 advance the point made by
+sentence 1? If the link is not apparent, a transitional phrase or
+a restructure is needed.
+
+Logic First is the highest-priority writing rule. A paper can
+recover from many writing weaknesses if its logic is airtight;
+strong prose cannot compensate for broken logic.
+
+## 2. Self-contained rule
+
+The paper should be readable without referencing external material
+for basic understanding. A reader without access to prior work
+should be able to follow the paper's contribution; external
+citations are for context and credit, not for load-bearing
+content.
+
+Self-containment checks:
+
+- Every abbreviation defined on first use.
+- Every symbol defined on first use.
+- Every cited method explained in one sentence before use.
+- Figure captions readable without the body text.
+
+## 3. Leading Text rule
+
+Every framework section, every subsection, every paragraph should
+begin with a leading sentence that says what the reader is about
+to read. The leading text is the reader's navigation anchor.
+
+Leading text does three things:
+
+- States the goal of the upcoming content.
+- Previews the structure (if the section or paragraph has
+  internal structure).
+- Connects to what came before.
+
+A paper without leading texts reads as a succession of claims
+without context. Reviewers sense this as disorganisation.
+
+## 4. Running Example rule
+
+The running example established in Introduction Paragraph 1 should
+reappear:
+
+- In the Methodology as a walkthrough of how the method handles
+  it.
+- In the Experiments as a case study or example in an analysis
+  figure.
+- In the Conclusion optionally, as a closing reference.
+
+A running example that appears only in the Introduction signals
+that the author did not structure the narrative around a single
+concrete anchor; reviewers struggle to follow the paper's story.
+
+## 5. Paragraph discipline
+
+Each paragraph:
+
+- Opens with a topic sentence that states the paragraph's point.
+- Contains three to eight sentences; significantly more usually
+  indicates the paragraph is trying to cover two topics.
+- Closes with a sentence that either concludes the point or
+  bridges to the next paragraph.
+- Contains only one topic; do not mix unrelated points in one
+  paragraph.
+
+Common paragraph failures:
+
+- No topic sentence; the point only emerges in the middle.
+- Topic sentence buried; the reader must infer the point.
+- Too long; the paragraph covers two topics that should be split.
+- Too short; a two-sentence paragraph rarely earns its own line
+  break, fold into a neighbour.
+
+## 6. Section-level consistency
+
+Beyond the paragraph level, sections are expected to follow the
+framework laid out in the Introduction:
+
+- Methodology sections mention the module names introduced in
+  the Introduction.
+- Experiments evaluate the claims made in the Contributions.
+- Related Work is consistent with the Limitations cited in the
+  Introduction.
+
+Inconsistency between sections is among the most common review
+findings. Check that every module name in the Introduction appears
+verbatim as a subsection title in the Methodology. Check that
+every contribution cited in the Introduction has a corresponding
+experiment that validates it.
+
+## 7. Failure patterns
+
+| Pattern | Detection | Severity |
+|---|---|---|
+| Broken flowchart (Introduction) | One of the six paragraphs missing | CRITICAL |
+| Orphan contribution | Contribution has no section | CRITICAL |
+| Running example abandoned after Introduction | Search the Methodology and Experiments for the example; not found | MAJOR |
+| Leading text missing | A section or subsection opens with a dense paragraph | MAJOR |
+| Topic sentence absent | Random paragraph sampled; the point is not in the first sentence | MAJOR |
+| Module name mismatch | Methodology subsection titles differ from Introduction module names | MAJOR |
+| Related Work contradicts Limitations | Methods criticised in Introduction appear without critique in Related Work | MAJOR |
+| Paragraph over 10 lines | Length check | MINOR |
+| Paragraph under 2 sentences | Length check | MINOR |

package/dist/skills/pre-submission-reviewer/references/section-guides.md

@@ -0,0 +1,169 @@
+# Per-section writing guides
+
+## Table of contents
+
+1. Abstract
+2. Introduction
+3. Problem Formulation
+4. Framework or Methodology
+5. Experiments
+6. Related Work
+7. Conclusion
+
+## 1. Abstract
+
+Five-sentence formula.
+
+| Sentence | Content |
+|---|---|
+| 1 | What problem does the paper solve? Context plus significance |
+| 2 | Why is it worth solving? Nobody has done it, or existing methods fail |
+| 3 | What are the challenges? Must be concrete; challenges of the problem, not of the method |
+| 4 | How is the problem solved? Method name and the key components, matched to the challenges |
+| 5 | How well does the method perform? Real datasets, concrete numbers, code link if available |
+
+Common failures:
+
+- Too abstract on what and why.
+- Missing challenges sentence.
+- Results sentence without specific numbers.
+- Hype words (revolutionary, groundbreaking) in the first
+  sentence; these read as defensive.
+
+## 2. Introduction
+
+Six-paragraph formula matching the Introduction Flowchart.
+
+| Paragraph | Content |
+|---|---|
+| 1 | The problem; a concrete motivating example |
+| 2 | Existing approaches and their limitations; highly condensed, at most three limitations |
+| 3 | The problem's essence and hard constraints; the paper's goal or key idea |
+| 4 | Key challenges; the challenges of the problem, not the method |
+| 5 | Solution overview; one-to-one mapping with challenges |
+| 6 | Summary of contributions, three or four, each mapped to a section |
+
+Key constraints:
+
+- Attracts the reviewer. Mostly decides acceptance.
+- Highlights novelty and technical depth.
+- States the difference from existing work explicitly.
+- Writes the paper's own ideas; other work belongs in Related
+  Work.
+- Terms are precise; the reader should grasp the paper's core
+  quickly.
+
+## 3. Problem Formulation
+
+Three steps:
+
+1. Describe the problem in prose so the reader understands the
+   scope.
+2. Present the formal definition with notation and equations.
+3. Use a concrete example to anchor understanding.
+
+Key constraint: a paper should solve one problem, not several.
+A strong running example is worth more than additional formal
+machinery.
+
+## 4. Framework or Methodology
+
+Organising principle: overall-to-detail. The section starts with
+an architecture and then drills into components; each component's
+subsection repeats the pattern.
+
+| Part | Content |
+|---|---|
+| Architecture overview | Overall picture; after reading this part, the reader understands the technique at a high level |
+| Workflow walkthrough | Traces inputs through the system end-to-end |
+| Simple components | Described in-line in the Framework section |
+| Complex components | Covered at high level here; full detail deferred to a dedicated subsection or section |
+
+Must-have:
+
+- Novelty and contribution explicitly stated.
+- Overall architecture figure.
+- If a component has no novelty, minimise coverage; long
+  descriptions of known techniques add noise.
+- Later subsections order by novelty: strongest first.
+- Self-contained; well-illustrated; leading text per subsection.
+
+Avoid:
+
+- Explaining why alternative methods were rejected in detail;
+  that belongs in Related Work or an ablation.
+- Prior-work notation fragments mixed with the paper's notation.
+- Symbol drift across subsections; define once and use
+  consistently.
+
+## 5. Experiments
+
+Tense: past.
+
+Setup requirements:
+
+- Experimental goals stated first.
+- At least three datasets.
+- Evaluation metrics named and justified.
+- Baselines selected carefully; obvious baselines must not be
+  omitted. If the paper cites work proving A beats B and C, only A
+  is required, with explanation.
+
+Overall comparison:
+
+- End-to-end comparison against all baselines first.
+- State the metric before analysing results.
+- State the gain, explain the reason, extract findings.
+
+Ablation study:
+
+- Evaluate the contribution of each proposed component.
+- For three components A, B, C: report All, -A, -B, -C.
+- Vary key hyperparameters.
+
+Must-have:
+
+- Real datasets and persuasive baselines.
+- Conclusions stated explicitly. What did the experiments
+  demonstrate? Why?
+
+## 6. Related Work
+
+Position:
+
+- Section 2 if the paper depends on prior frameworks, models, or
+  methods for understanding.
+- Penultimate section if the paper is self-contained. The
+  penultimate position is the preferred default for strong papers.
+
+Do:
+
+- Summarise in the author's own words. No copying of sentences.
+- Fair crediting; do not over-criticise.
+- Focus on high-level summary, not minor details.
+- Self-contained; explain how the paper differs from related
+  work.
+- Group by method category, then state differences. Criticise
+  closest-related work directly; less-related work gets less
+  critique and more acknowledgement.
+- Citations use conference abbreviations (SIGMOD, VLDB, ICDE,
+  TKDE). Pull bibtex from DBLP.
+
+Do not:
+
+- Copy sentences from related work, ever. Plagiarism is a red
+  line.
+
+## 7. Conclusion
+
+Tense: present perfect (we have shown, we have proposed).
+
+Purpose: summarise contributions and significance. Do not duplicate
+the Introduction.
+
+- Introduction addresses readers who have not yet read the paper.
+- Conclusion addresses readers who have finished the paper; they
+  know the technical details.
+
+Close with implications or future directions in one to two
+sentences. Avoid vague claims about "impact".

package/dist/skills/prior-art-search/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: prior-art-search
+description: "Search patent databases and academic literature for prior art relevant to an invention. Use when user says \"现有技术检索\", \"prior art search\", \"专利检索\", \"check patents\", or wants to find relevant prior art."
+argument-hint: [invention-description-or-path]
+allowed-tools: Bash(*), Read, Glob, Grep, WebSearch, WebFetch, Write
+---
+
+# Prior Art Search
+
+Search patents and literature for prior art relevant to: **$ARGUMENTS**
+
+Adapted from `/research-lit` for patent-specific searching.
+
+## Constants
+
+- `MAX_PATENT_RESULTS = 20` — Maximum patent documents to analyze in detail
+- `MAX_PAPER_RESULTS = 15` — Maximum academic papers to analyze in detail
+- `SEARCH_YEARS = 10` — How many years back to search
+- `PATENT_DATABASES = "google-patents, espacenet"` — Patent databases to search
+
+## Inputs
+
+Read the invention description from:
+1. `$ARGUMENTS` if it contains technical details
+2. `patent/INVENTION_BRIEF.md` if it exists
+3. `INVENTION_BRIEF.md` if it exists at project root
+
+## Shared References
+
+Load `../shared-references/prior-art-databases.md` for search strategy templates and IPC/CPC classification guidance.
+
+## Workflow
+
+### Step 1: Extract Search Concepts
+
+From the invention description, identify:
+1. **Core inventive concept**: The primary technical contribution (1-2 sentences)
+2. **Technical problem**: What problem it solves
+3. **Key technical features**: 4-6 specific technical elements that define the invention
+4. **IPC/CPC classes**: Predict relevant classification codes (e.g., G06N, G06F)
+
+### Step 2: Patent Search
+
+For EACH search concept, search via:
+
+**Google Patents** (via WebSearch):
+```
+WebSearch: "site:patents.google.com [keywords]"
+WebSearch: "[keywords] patent"
+```
+- Try primary keywords + technical problem keywords
+- Search in English regardless of target jurisdiction
+- For CN inventions, also search Chinese keywords via WebSearch
+
+**Espacenet** (via WebFetch):
+- WebFetch worldwide.espacenet.com/search results for key queries
+- Search by predicted IPC/CPC classes
+
+**Assignee/Inventor Search**:
+- If known companies/universities work in this area, search their patent portfolios
+- WebSearch: "[assignee name] patent [technical area]"
+
+For each potentially relevant patent found:
+- WebFetch the patent page to extract: title, abstract, representative claims, filing date, assignee, current status
+- Record IPC/CPC classification codes
+
+### Step 3: Academic Literature Search
+
+Search the same concepts in academic databases:
+
+1. **Google Scholar** (via WebSearch): `WebSearch "[keywords] site:scholar.google.com"`
+2. **arXiv** (via `/arxiv` if available, or WebSearch): Search for preprints
+3. **Semantic Scholar** (via `/semantic-scholar` if API key set, or WebSearch)
+
+For each relevant paper found:
+- Extract title, authors, venue, year, key contribution
+
+### Step 4: Classification and Analysis
+
+For each reference found, assess:
+
+1. **Relevance**: How closely does it relate to the invention?
+2. **Overlap Risk**: Does it disclose the same or similar technical solution?
+   - HIGH: Anticipates one or more claim elements
+   - MEDIUM: Discloses a related but different approach
+   - LOW: Same general field, different approach
+3. **Relationship**: Is it anticipating, relevant, or merely background?
+
+Organize results by IPC/CPC classification to see the technical landscape.
+
+### Step 5: Freedom-to-Operate Assessment (Preliminary)
+
+Based on the search results:
+- Identify patents with claims that potentially cover the invention
+- Note any expired patents (public domain)
+- Flag areas where claim scope overlap is significant
+
+**Disclaimer**: This is a preliminary assessment only. A professional freedom-to-operate analysis by a patent attorney is recommended before filing.
+
+### Step 6: Output
+
+Write `patent/PRIOR_ART_REPORT.md` with:
+
+```markdown
+## Prior Art Search Report
+
+### Invention Summary
+[1-2 sentence description of the searched invention]
+
+### Search Strategy
+- Keywords used: [...]
+- IPC/CPC classes searched: [...]
+- Databases searched: Google Patents, Espacenet, Google Scholar, arXiv
+- Date range: [year] to present
+
+### Patent References Found
+
+| # | Patent No. | Title | Date | Assignee | IPC/CPC | Key Teaching | Overlap Risk |
+|---|-----------|-------|------|----------|---------|-------------|-------------|
+| 1 | CN... / US... | [title] | [date] | [assignee] | [codes] | [2-3 sentences] | HIGH/MEDIUM/LOW |
+
+### Non-Patent Literature Found
+
+| # | Reference | Title | Authors/Venue | Year | Key Contribution | Relevance |
+|---|-----------|-------|--------------|------|-----------------|-----------|
+| 1 | [DOI/link] | [title] | [authors] | [year] | [1-2 sentences] | HIGH/MEDIUM/LOW |
+
+### Prior Art Landscape
+[Organized by technical approach or IPC class, not just chronological]
+
+### Freedom-to-Operate Preliminary Assessment
+[Which existing patents might block the invention? What is the risk level?]
+
+### Recommendations
+- Suggested claim scope adjustments based on prior art
+- Areas where novelty appears strongest
+- References to watch during prosecution
+```
+
+## Key Rules
+
+- Never fabricate patent numbers or citations. Mark uncertain references with `[VERIFY]`.
+- Search in English AND the target jurisdiction language (Chinese for CN).
+- Patent prior art includes everything published before the priority date, not just patents.
+- Academic papers are valid prior art for both novelty and inventive step.
+- Include expired patents -- they are public domain but still relevant for novelty.