@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/intro-drafter/references/paper-types.md

@@ -0,0 +1,155 @@
+# Paper-type positioning: Technique versus New Problem/Setting
+
+## Table of contents
+
+1. Why positioning matters
+2. Technique Paper profile
+3. New Problem/Setting Paper profile
+4. Positioning criteria
+5. Worked examples: Alpha-SQL, AFlow, LEAD
+6. Mixed cases
+
+## 1. Why positioning matters
+
+The paper-type positioning decides where the Introduction's weight
+falls. A Technique Paper's narrative spine is the Key Idea; the Goal
+gets a one-sentence bridge. A New Problem/Setting Paper's narrative
+spine is the Goal or Problem Formulation; the Key Idea is subordinate
+to "why this definition is reasonable and feasible".
+
+Mis-positioning is a common Introduction failure. A New Problem paper
+written as a Technique paper underweights its contribution. A
+Technique paper written as a New Problem paper overclaims.
+
+## 2. Technique Paper profile
+
+A Technique Paper's core contribution is a new method or mechanism
+solving an already-defined problem. The Key Idea carries the
+narrative.
+
+Signals:
+
+- The problem is well-established (a named benchmark already exists,
+  prior work is extensive).
+- The contribution is a better way to do something, not a new thing
+  to measure or a new setting to study.
+- Reviewers will compare against the strongest existing method on
+  the same problem.
+- Experiments focus on "our method beats baselines".
+
+Introduction weight distribution:
+
+- Paragraph 1: 150-200 words (running example is essential).
+- Paragraph 2: 150-200 words (specific limitations of prior methods).
+- Paragraph 3: 100-150 words (Goal is a bridge; Key Idea takes the
+  weight).
+- Paragraph 4: 150-200 words (challenges).
+- Paragraph 5: 150-200 words (solution modules).
+- Paragraph 6: 100-150 words (contributions).
+
+## 3. New Problem/Setting Paper profile
+
+A New Problem/Setting Paper's core contribution is defining a problem
+that the community has not yet studied as such, or a new setting
+within a known problem. The Goal or Problem Formulation is the
+contribution.
+
+Signals:
+
+- Prior work exists on adjacent problems but not this specific
+  framing.
+- The contribution is a new way to think about the space, not a new
+  method on an existing problem.
+- Experiments aim to characterise the new problem, not beat a
+  pre-existing leaderboard.
+- The Introduction contains a specific "Our Goal" or "Research
+  Question" paragraph that is load-bearing.
+
+Introduction weight distribution:
+
+- Paragraph 1: 150-200 words.
+- Paragraph 2: 150-200 words (limitations show why existing framings
+  miss this problem).
+- Paragraph 3: 200-250 words (Goal or Problem Formulation is the
+  contribution; Key Idea supports "why this definition is
+  reasonable").
+- Paragraph 4: 100-150 words (challenges).
+- Paragraph 5: 150-200 words (solution modules that realise the
+  setting).
+- Paragraph 6: 100-150 words (C1 is the problem formulation).
+
+## 4. Positioning criteria
+
+Ask the following in order. The first yes determines the type.
+
+1. Does the paper define a problem or setting the community has not
+   studied? If yes, New Problem/Setting.
+2. Is the paper's main contribution a new method on an existing
+   benchmark? If yes, Technique.
+3. Is the paper's main contribution a new benchmark? If yes, use
+   `benchmark-paper-template` (separate plugin) instead.
+4. Does the paper propose a method that is also a problem
+   reformulation? See Mixed cases below.
+
+## 5. Worked examples
+
+### Alpha-SQL (ICML 2025)
+
+Type: Technique Paper.
+
+Rationale: the Text-to-SQL problem is well-established; the paper
+contributes an MCTS-based inference procedure for better SQL
+generation. The Goal is a one-sentence bridge ("we improve SQL
+generation accuracy on complex queries"). Key Idea (MCTS inference-
+time search) carries the narrative.
+
+Introduction paragraph weights match the Technique profile: Paragraph
+3 is short; Paragraphs 4 and 5 carry detail.
+
+### AFlow (ICLR 2025)
+
+Type: Technique Paper with cross-domain framing.
+
+Rationale: the problem of agent-workflow design exists, but has not
+been formulated as a search problem over operator graphs. The paper
+is arguably a mixed case. Its published Introduction leads with Key
+Idea, not Goal, so the archive case-study classifies it as Technique
+with Broader-dimension framing.
+
+If the author had weighted Paragraph 3 more heavily to make
+"workflow-as-a-search-space" the contribution, the paper could have
+been positioned as New Problem. Either framing is defensible. The
+choice affects which reviewers the paper resonates with.
+
+### LEAD (VLDB 2026)
+
+Type: New Problem/Setting Paper.
+
+Rationale: prior work on iterative data selection assumes a full-
+dataset inference per iteration. LEAD redefines the setting as
+"iterative selection without additional inference". The new setting
+is the core contribution; the method (instance-level dynamic
+uncertainty from training loss) supports why the setting is
+feasible.
+
+Introduction paragraph 3 is load-bearing: the Goal and Research
+Question "Can iterative benefits be kept while eliminating
+repeated full-dataset inference?" is the headline contribution.
+
+## 6. Mixed cases
+
+A paper can legitimately contribute both a new method and a new
+problem framing. When this happens:
+
+- Pick the contribution the paper delivers best.
+- State the secondary contribution in Paragraph 6 but do not fight
+  for narrative space in Paragraph 3.
+- Do not try to frame the paper as both simultaneously; the
+  Introduction will lose focus.
+- If both contributions are genuinely equal in strength, consider
+  splitting into two papers or writing a journal version.
+
+A mixed case cue: the author is unsure which framing is stronger. If
+one framing consistently draws clearer reviewer excitement in
+pre-submission discussions, pick that framing. If both framings draw
+equal excitement, split the paper.

package/dist/skills/intro-drafter/references/running-example.md

@@ -0,0 +1,133 @@
+# Running example design
+
+## Table of contents
+
+1. What a running example is
+2. Why it matters
+3. Design principles
+4. Two design patterns
+5. Worked examples
+6. Common failures
+
+## 1. What a running example is
+
+A running example is a specific, concrete scenario that appears in
+the Introduction (typically as Figure 1), in the Problem Formulation
+or Methodology to illustrate the definition and the method's
+operation, and in the Experiments as a case study. It is the same
+example throughout, not different examples per section.
+
+A strong running example turns an abstract research claim into a
+tangible story the reader can follow in 30 seconds.
+
+## 2. Why it matters
+
+Reviewers read 10 to 30 papers per cycle; their attention is finite.
+An Introduction that opens with abstract claims loses the reader's
+interest before the contribution lands. A running example gives the
+reader something concrete to hold on to, and later sections can
+refer back to it instead of reintroducing new examples.
+
+Running examples also help the writer. The discipline of fitting the
+method to a single example exposes vague steps that look fine in
+prose but break in practice.
+
+## 3. Design principles
+
+- **Real**. The example is drawn from real data or a real deployment,
+  not fabricated.
+- **Specific**. The example names concrete entities: tables,
+  queries, datasets, file paths, measurements. Abstractions come
+  later.
+- **Simple yet complete**. The example is small enough to fit on one
+  figure, and complete enough to exhibit the problem's full
+  complexity.
+- **Recurring**. The same example appears in Introduction, Problem
+  Formulation, Methodology (worked through), and Experiments (as a
+  case study). The reader should experience a closed narrative loop.
+- **Failure-revealing**. The example clearly shows where existing
+  methods fail. A generic example that everyone would solve
+  correctly is not useful.
+
+## 4. Two design patterns
+
+### Pattern A: Real scenario plus concrete failure
+
+The example shows a concrete real scenario and then shows what goes
+wrong under the prior method. This is the most versatile pattern.
+
+Template:
+
+1. Describe the scenario concretely (entity names, measurements).
+2. Show what a user expects.
+3. Show what the prior method produces, and name the specific
+   failure (wrong result, missed case, wrong decision).
+4. Foreshadow how the paper's method handles it.
+
+### Pattern B: Side-by-side good versus bad
+
+The example places a correct output next to an incorrect one,
+emphasising the single dimension where current methods break.
+
+Template:
+
+1. Show two outputs for the same input, labelled Correct and
+   Incorrect.
+2. Annotate the single dimension where they differ.
+3. State that prior methods produce the Incorrect output; your paper
+   aims to produce the Correct output.
+
+This pattern works well when the contribution is evaluation-
+oriented (a judge, a scorer, a corrector) rather than
+generation-oriented.
+
+## 5. Worked examples
+
+### Text-to-SQL running example (Pattern A)
+
+Scenario: a user asks "Which products in the last quarter had the
+highest sales growth compared to the quarter before?" on a retail
+database with Orders, Products, and Stores tables.
+
+Expected: a SQL query that joins the three tables, groups by
+product, windows over the two quarters, and computes growth.
+
+Prior method failure: the generated SQL omits the JOIN between
+Orders and Stores, causing the result to include products from
+stores the user did not care about, inflating the output by
+thousands of rows.
+
+Paper's method: introduces schema-level JOIN-reasoning that detects
+the missing JOIN and inserts it. The example reappears in Section 3
+as the walkthrough, and in Section 5 as Case Study 1.
+
+### Visualisation-quality example (Pattern B)
+
+Side-by-side: two charts showing the same data. The Correct chart
+uses a log scale that makes small differences visible and labels the
+axis in meaningful units. The Incorrect chart uses a linear scale
+and unlabelled units, making the data appear uniform.
+
+Prior method: scores both charts similarly on aesthetics; ignores
+the fidelity difference.
+
+Paper's method: decomposes quality into Fidelity and Aesthetics axes
+and scores the log-scale chart higher on Fidelity. Example reappears
+in Section 3's scoring-rubric explanation and in Section 5.
+
+## 6. Common failures
+
+- **Generic running example**: a toy dataset or a textbook query.
+  Reviewers infer the method only works on toys.
+- **Non-failing running example**: the example is specific but any
+  prior method would handle it correctly. The reader cannot see why
+  the paper is needed.
+- **Running example abandoned after Introduction**: appears in
+  Figure 1 and never returns. Reviewers lose the narrative thread.
+- **Multiple running examples**: one per section. Readers get
+  confused about which is canonical.
+- **Running example too complex**: fits only with extensive
+  explanation. The 30-second test fails.
+- **Running example with contrived details**: entities named Entity1,
+  Entity2 rather than real names. Reviewers infer the example is
+  fabricated.

package/dist/skills/intro-drafter/references/worked-examples.md

@@ -0,0 +1,161 @@
+# Worked Introduction outlines
+
+## Table of contents
+
+1. How to read these examples
+2. Example A: Alpha-SQL (ICML 2025), Technique
+3. Example B: AFlow (ICLR 2025), Technique with cross-domain framing
+4. Example C: LEAD (VLDB 2026), New Problem/Setting
+5. What the examples teach
+
+## 1. How to read these examples
+
+Each example below reverse-engineers a published Introduction into
+the six-paragraph outline this skill produces. The outlines are
+faithful to the published papers, with some writing points
+paraphrased. Sources are
+`handbook/06_Case_Studies/6.1`, `6.2`, and
+`6.3`.
+
+The purpose is to show the outline at the level of detail this skill
+should produce when given similar inputs.
+
+## 2. Example A: Alpha-SQL (ICML 2025), Technique
+
+### Type positioning
+
+Technique Paper. Text-to-SQL is a long-established problem with
+active benchmarks (Spider, BIRD). The contribution is a method:
+MCTS-based inference-time search.
+
+Paragraph 3 is a one-sentence bridge.
+
+### Outline
+
+1. **Background and Motivation**. Real-world Text-to-SQL applications
+   in production analytics; running example: a multi-table aggregation
+   query on a retail database. Existing open-source LLM-based SQL
+   generators struggle on complex cases.
+2. **Limitations of existing work**:
+   - L1: prior open-source methods rely on single-pass generation and
+     fail on complex JOIN reasoning.
+   - L2: fine-tuning approaches are expensive and do not generalise
+     across schemas.
+   - L3 is not claimed; the paper uses only two limitations to keep
+     focus.
+3. **Problem essence and Goal**. Hard constraint: open-source
+   deployable without fine-tuning. Goal bridge: "Our goal is to
+   improve complex-query SQL generation on open-source LLMs without
+   fine-tuning."
+4. **Key challenges**:
+   - Ch1: decision-space explosion when enumerating SQL candidates.
+   - Ch2: reward modelling without a trained critic.
+5. **Solution overview**. Alpha-SQL with MCTS-guided inference and
+   self-supervised reward signals. Module A addresses Ch1 via
+   structured search. Module B addresses Ch2 via execution feedback.
+6. **Contributions**:
+   1. MCTS-based inference search for Text-to-SQL (Section 3).
+   2. Self-supervised reward design from execution feedback
+      (Section 4).
+   3. Experiments on BIRD and Spider, showing N-point accuracy gains
+      over strong open-source baselines (Section 5).
+
+## 3. Example B: AFlow (ICLR 2025), Technique with cross-domain framing
+
+### Type positioning
+
+Technique Paper, framed to emphasise Broader-dimension cross-domain
+transplantation (operator search for agent workflows, borrowed from
+neural architecture search).
+
+Paragraph 3 bridges briefly; the Key Idea weight is in Paragraph 4
+and 5.
+
+### Outline
+
+1. **Background and Motivation**. LLM agents for code generation;
+   running example: an agent workflow for HumanEval tasks that fails
+   when operators are mis-composed.
+2. **Limitations of existing work**:
+   - L1: prompt-engineering alone produces brittle workflows.
+   - L2: single-agent architectures do not capture operator
+     composition.
+   - L3: hand-designed workflows do not generalise across task
+     families.
+3. **Problem essence and Goal**. Hard constraint: workflow design
+   must generalise to unseen operators. Goal bridge: "Our goal is
+   to automate workflow design for code-generation agents."
+4. **Key challenges**:
+   - Ch1: search space of operator graphs is combinatorial.
+   - Ch2: evaluation signal for a workflow is discrete and sparse.
+5. **Solution overview**. AFlow with operator-graph search (borrowed
+   from NAS) and structured reward via code execution. Module A
+   addresses Ch1; Module B addresses Ch2.
+6. **Contributions**:
+   1. Formulate agent-workflow design as operator-graph search
+      (Section 2).
+   2. AFlow algorithm with search guided by execution feedback
+      (Section 3).
+   3. Evaluation on HumanEval, MBPP, and adjacent benchmarks showing
+      consistent gains over hand-designed and prompt-engineered
+      workflows (Section 4).
+
+## 4. Example C: LEAD (VLDB 2026), New Problem/Setting
+
+### Type positioning
+
+New Problem/Setting Paper. Paragraph 3 is load-bearing: the
+contribution is the new setting "iterative data selection without
+additional inference".
+
+### Outline
+
+1. **Background and Motivation**. LLM instruction tuning; data
+   quality beats quantity. Running example: a 50k-sample instruction
+   corpus where iterative selection improves tuning quality but
+   incurs full-dataset inference per round.
+2. **Limitations of existing work**:
+   - L1: non-iterative selection does not adapt to model evolution.
+   - L2: iterative methods require expensive full-dataset inference
+     per round.
+3. **Problem essence and Goal**. Hard constraint: no additional
+   inference budget on top of the existing fine-tuning loop.
+   Research question as the core contribution: "Can iterative
+   selection benefits be preserved while eliminating repeated
+   full-dataset inference?" Key Idea: use the training loss already
+   computed inside the fine-tuning loop as a zero-overhead utility
+   signal.
+4. **Key challenges**:
+   - Ch1: extract a reliable utility signal from noisy training-loss
+     trajectories.
+   - Ch2: integrate the selection signal into the training loop
+     without disturbing convergence.
+5. **Solution overview**. LEAD framework with Instance-level Dynamic
+   Uncertainty (IDU) as the utility signal; selection runs inline
+   with training. Module A addresses Ch1 via statistical
+   denoising; Module B addresses Ch2 via deferred selection.
+6. **Contributions**:
+   1. Formulation of iterative data selection without additional
+      inference as a new problem setting (Section 2).
+   2. Instance-level Dynamic Uncertainty signal and its theoretical
+      analysis (Sections 3, 4).
+   3. LEAD framework design (Section 3).
+   4. Extensive experiments on multiple instruction-tuning
+      benchmarks, showing matched-or-better quality at an order-of-
+      magnitude lower cost (Section 5).
+
+## 5. What the examples teach
+
+- Alpha-SQL shows a tight Technique Paper: three contributions, two
+  limitations, two challenges. Focus wins.
+- AFlow shows a Technique Paper with cross-domain framing: three
+  contributions, three limitations, two challenges. The Broader-
+  dimension framing earns the ICLR slot without changing type.
+- LEAD shows a New Problem Paper: Paragraph 3 is load-bearing; the
+  contributions include the problem setting itself as C1; the
+  framework and method are C2-C4.
+- All three have a one-to-one mapping between challenges and
+  modules; none has more than three challenges. None has vague
+  phrases as contributions.
+- None reuses prior work in C1 without crediting prior limitations
+  in Paragraph 2.

package/dist/skills/invention-structuring/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: invention-structuring
+description: "Structure a raw invention idea into a formal invention disclosure. Use when user says \"构建发明\", \"structure invention\", \"发明构建\", \"invention disclosure\", or wants to formalize a rough idea into a patent-ready structure."
+argument-hint: [invention-description-or-brief-path]
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob
+---
+
+# Invention Structuring
+
+Structure the invention into a formal disclosure based on: **$ARGUMENTS**
+
+Adapted from the refinement pattern in `/research-refine` for patent invention decomposition.
+
+## Constants
+
+- `REVIEWER_MODEL = gpt-5.5` — External reviewer for invention decomposition validation
+- `MAX_REFINEMENT_ROUNDS = 3` — Maximum structuring iterations
+
+## Inputs
+
+1. Invention description from `$ARGUMENTS`
+2. `patent/INVENTION_BRIEF.md` if exists
+3. `patent/PRIOR_ART_REPORT.md` — prior art landscape
+4. `patent/NOVELTY_ASSESSMENT.md` — novelty analysis
+
+## Shared References
+
+Load `../shared-references/patent-writing-principles.md` for the Problem-Solution-Advantage framework and claimable subject matter guidelines.
+
+## Workflow
+
+### Step 1: Problem-Solution-Advantage Framework
+
+Structure the invention using the universal patent framework:
+
+**Technical Problem (要解决的技术问题)**:
+- Derived from prior art deficiencies identified in NOVELTY_ASSESSMENT.md
+- Must be a specific, technical problem (not a commercial or social problem)
+- Statement format: "The technical problem to be solved is how to [specific technical objective] given [specific technical constraint]."
+
+**Technical Solution (技术方案)**:
+- The invention's specific technical contribution
+- Focus on the mechanism, not the result
+- Must be described at a level that matches the intended claim scope
+- Identify which features are known vs. inventive
+
+**Advantages (有益效果)**:
+- Measurable or quantifiable improvements over prior art
+- Must result from the inventive features, not just good engineering
+- Include specific technical effects if known (e.g., "reduces processing time by 40%")
+
+### Step 2: Invention Decomposition
+
+Break the invention into three layers:
+
+**Core Inventive Concept (核心发明构思)**:
+- The minimal set of features that make the invention patentable
+- This maps to the independent claim scope
+- Test: if you remove this feature, the invention is no longer novel
+
+**Supporting Features (支撑性特征)**:
+- Features that make the invention work well in practice
+- These become dependent claim material
+- They narrow the scope but add practical value
+
+**Optional Features (可选特征)**:
+- Implementation details, preferred parameters, alternatives
+- These become embodiment material
+- They support broader claim interpretation
+
+### Step 3: Claimable Subject Matter Identification
+
+For the core inventive concept, determine what categories of claims to draft:
+
+| Category | Applicability | Content |
+|----------|-------------|---------|
+| Method/process | If invention involves steps | Process flow, algorithm, workflow |
+| System/apparatus | If invention involves components | Hardware structure, modules, connections |
+| Product | If invention is a physical device | Shape, structure, composition |
+| Computer-readable medium | If software invention (US) | Stored instructions, non-transitory medium |
+| Product-by-process | If structure is hard to define | Product defined by how it is made |
+
+### Step 4: Drawing Plan
+
+Plan what figures are needed to support the claims and specification:
+
+| Figure | Type | Shows | Supports Claim Elements |
+|--------|------|-------|------------------------|
+| FIG. 1 | Block diagram | System architecture | System claim components |
+| FIG. 2 | Flowchart | Method steps | Method claim steps |
+| FIG. 3 | Sequence diagram | Interaction between components | Specific implementation details |
+
+If user has provided figures, reference them here. If figures are missing, note what is needed.
+
+### Step 5: Dependency Mapping
+
+Map feature dependencies to plan the claim hierarchy:
+
+```
+Independent Claim 1 (method, broadest scope)
+├── Core inventive feature A
+├── Core inventive feature B
+└── Known feature C (for context)
+
+Dependent Claim 2 → narrows feature A with specific implementation
+Dependent Claim 3 → narrows feature B with specific parameters
+Dependent Claim 4 → depends on 2, adds optional feature D
+Dependent Claim 5 → alternative implementation of feature A
+```
+
+### Step 6: Cross-Model Validation
+
+Call `REVIEWER_MODEL` via a dedicated Codex reviewer agent at xhigh reasoning:
+
+```text
+spawn_agent:
+  model: gpt-5.5
+  reasoning_effort: xhigh
+  message: |
+    You are a patent attorney reviewing an invention disclosure.
+    Evaluate the structuring choices:
+
+    INVENTION: [Problem-Solution-Advantage summary]
+    DECOMPOSITION: [Core/Supporting/Optional features]
+    CLAIM PLAN: [intended claim categories and hierarchy]
+
+    Please assess:
+    1. Is the Problem-Solution-Advantage framework correctly applied?
+    2. Is the core inventive concept correctly identified? Are there features that should be core but are listed as supporting (or vice versa)?
+    3. Are the planned claim categories sufficient to protect the invention?
+    4. Is the drawing plan adequate for enablement?
+    5. Are there any claimable aspects being missed?
+```
+
+### Step 7: Output
+
+Write `patent/INVENTION_DISCLOSURE.md`:
+
+```markdown
+## Invention Disclosure
+
+### Title
+[invention title]
+
+### Technical Problem
+[formal problem statement]
+
+### Technical Solution
+[formal solution description]
+
+### Advantages
+[measurable advantages]
+
+### Feature Decomposition
+
+#### Core Inventive Concept
+[features that define independent claim scope]
+
+#### Supporting Features
+[features for dependent claims]
+
+#### Optional Features
+[features for embodiments]
+
+### Claimable Subject Matter
+[method, system, product, medium claims planned]
+
+### Drawing Plan
+[figures needed, what each shows]
+
+### Dependency Map
+[claim hierarchy plan]
+
+### Inventor Information
+[names, contributions]
+
+### Target Jurisdiction
+[CN/US/EP/ALL]
+```
+
+## Key Rules
+
+- The Problem must come from prior art deficiencies, not from commercial needs.
+- The Solution must describe the technical mechanism, not just the result.
+- The core inventive concept must be the minimum set of features for patentability.
+- Supporting features should be independently valuable -- each should provide a meaningful technical benefit even if other supporting features are removed.
+- Never invent embodiments that do not correspond to the actual invention or user-provided materials.
+- If reviewer delegation is unavailable in the current Codex host, stop and ask the user to enable Codex agent support before continuing.