@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/intro-drafter/SKILL.md

@@ -0,0 +1,250 @@
+---
+name: intro-drafter
+description: >-
+  Drafts a 6-paragraph Introduction outline for a technical paper from a
+  structured Flowchart: background and running example, existing
+  limitations, problem essence and goal, key challenges, solution
+  overview, contributions. Positions the paper as Technique or New
+  Problem/Setting and aligns contributions with challenges. Use when
+  the user asks to 'draft the Introduction', 'outline the
+  Introduction', 'intro logic needs clarifying', 'help structure the
+  paper story', or before writing any Introduction prose.
+license: CC-BY-4.0
+---
+
+# Introduction Drafter
+
+## Overview
+
+The Introduction is the compressed version of the entire paper. In one
+and a half to two pages it must state the research object, why the
+problem matters, why existing work falls short, what the paper
+contributes, and how the contribution maps to section numbers.
+Reviewers decide whether to keep reading by the time they finish the
+Introduction, so the logical throughline has to be airtight.
+
+This skill takes a small set of inputs (research area, limitations,
+hard constraints, key idea, challenges, solution overview) and
+produces a six-paragraph outline with an explicit purpose and writing
+points for every paragraph, plus a positioning as Technique Paper or
+New Problem/Setting Paper. It enforces the rule that contributions
+align one-to-one with challenges, and that every claim has a section
+to deliver it.
+
+## When to use this skill
+
+- Before writing any Introduction prose.
+- The user has finished planning but the Intro story feels fragmented.
+- The user has a partial Intro and wants to restructure.
+- The user asks to 'draft the Introduction', 'outline the
+  Introduction', 'intro logic needs clarifying', or 'help structure
+  the paper story'.
+- The paper's contributions are clear, but the storyline connecting
+  them is not.
+- `idea-evaluator` has returned Strong Accept and the next step is
+  drafting.
+
+## When NOT to use this skill
+
+- The paper's core idea is not yet stable. Use `idea-evaluator` first.
+- The paper is a benchmark paper. Use `benchmark-paper-template` (separate plugin)
+  instead; the flowchart differs.
+- The user wants to polish Introduction prose that is already
+  structured. Use `pre-submission-reviewer` instead.
+- The user wants to evaluate whether the Introduction is ready for
+  submission. Use `pre-submission-reviewer`.
+
+## Core procedure
+
+### Step 1: Paper-type positioning
+
+See: references/paper-types.md for the Technique versus New
+Problem/Setting distinction, positioning criteria, and worked
+examples from Alpha-SQL, AFlow, and LEAD.
+
+Decide which type the paper is:
+
+- **Technique Paper**: main contribution is a new method or mechanism
+  solving an existing problem. Narrative axis is Key Idea / Mechanism.
+  Goal gets one sentence in passing.
+- **New Problem/Setting Paper**: main contribution is a new problem
+  formulation. Narrative axis is Goal / Problem Formulation. Key
+  Idea supports "why this definition is reasonable".
+
+The positioning decides how much weight Paragraph 3 carries: in
+Technique papers it is a short bridge; in New Problem papers it is a
+load-bearing paragraph.
+
+### Step 2: Paragraph-by-paragraph outline
+
+See: references/flowchart.md for each paragraph's canonical purpose,
+writing points, and common failures.
+
+For each of the six paragraphs, return a mini-section containing:
+
+- **Purpose**: one sentence.
+- **Writing points**: three to five bullets derived from the user's
+  inputs, each actionable.
+- **Gaps**: what the user's inputs do not yet cover for this
+  paragraph. Tag each with severity (CRITICAL, MAJOR, MINOR).
+
+Paragraphs:
+
+1. Background and Motivation. Running example. Why the problem
+   matters in the real world.
+2. Limitations of existing work. At most three, each framed as
+   "prior work X does not handle Y".
+3. Problem essence and Our Goal. Hard constraints explicit. In
+   Technique papers this is a bridge; in New Problem/Setting papers
+   this is the contribution itself.
+4. Key challenges. At most three, each explaining why naive
+   extension of prior work fails.
+5. Solution overview. Each module addresses a challenge. Expect a
+   one-to-one mapping between Paragraph 4 challenges and Paragraph 5
+   modules.
+6. Contributions. Three or four numbered bullets. Each maps to a
+   section reference.
+
+### Step 3: Running example design
+
+See: references/running-example.md for the design principles (real,
+specific, simple-yet-complete, recurring throughout), two design
+patterns (concrete-failure versus good-versus-bad), and worked
+examples.
+
+If the user's inputs do not yet include a running example, propose
+two or three candidate examples and ask the user to pick. Record the
+chosen example in Paragraph 1 and make sure Paragraph 5 references
+it ("the Methodology section applies DynaGraph's hotspot detector to
+the running example from Section 1").
+
+### Step 4: Contribution alignment check
+
+See: references/contribution-patterns.md for strong-versus-weak
+contribution patterns, anti-patterns, and the canonical mapping to
+section numbers.
+
+For each contribution bullet, verify:
+
+- Maps to a challenge in Paragraph 4, a module in Paragraph 5, or a
+  specific experiment result.
+- Specific, not vague ("comprehensive evaluation" is not a
+  contribution).
+- Cites the section number that delivers it.
+
+### Step 5: Flowchart consistency check
+
+Verify the six paragraphs form a single logical throughline:
+
+- Paragraph 1's running example is referenced in Paragraph 5 or a
+  case study forecast.
+- Paragraph 2's limitations motivate Paragraph 4's challenges.
+- Paragraph 3's goal aligns with Paragraph 6's contribution 1.
+- Paragraph 4's challenges map one-to-one with Paragraph 5's modules.
+- Paragraph 5's modules appear in Paragraph 6's contribution 2 or 3.
+
+Any break in the chain is a CRITICAL gap.
+
+### Step 6: Integrity gate
+
+Before emitting the outline, run the checks in the Integrity gate
+section below.
+
+### Step 7: Output the outline
+
+Emit the outline in the Output format below. For `interactive` mode,
+do not emit; converse one paragraph at a time.
+
+## Integrity gate
+
+All seven bullets are **[inspection]** class: the LLM verifies each
+directly from its own output (counting, pattern-matching, or
+comparing sections). No user-side attestation required.
+
+Before returning the outline:
+
+1. **[inspection]** Running example named in Paragraph 1 reappears
+   in Paragraph 5 or 6 (or the Case Study forecast).
+2. **[inspection]** Limitations (Paragraph 2) are at most three and
+   each is specific to a named prior work or a named capability.
+3. **[inspection]** Challenges (Paragraph 4) are at most three and
+   each explains why a naive extension of prior work fails.
+4. **[inspection]** Challenge-to-module mapping is one-to-one, not
+   one-to-many or many-to-one.
+5. **[inspection]** Contributions (Paragraph 6) are three or four
+   and each maps to a section number.
+6. **[inspection]** No contribution is vague language ("extensive
+   experiments", "thorough analysis" on their own).
+7. **[inspection]** Paper-type positioning from Step 1 is reflected
+   in Paragraph 3's weight.
+
+If any check fails, mark the paragraph as "needs user attention"
+and do not claim the outline is complete.
+
+## Output format
+
+### 0. Type positioning
+- Type: <Technique Paper or New Problem/Setting Paper>
+- Rationale: <one sentence>
+- Implication: <how Paragraph 3 weight adjusts>
+
+### 1. Paragraph 1: Background and Motivation
+- Purpose: <...>
+- Running example: <...>
+- Writing points:
+  1. ...
+  2. ...
+- Gaps: <list with severity>
+
+### 2. Paragraph 2: Limitations (at most 3)
+- Purpose: <...>
+- Writing points:
+  - Limitation 1: ...
+  - Limitation 2: ...
+  - Limitation 3: ... (if applicable)
+- Gaps: <list with severity>
+
+### 3. Paragraph 3: Problem Essence and Our Goal
+- Purpose: <...>
+- Hard constraints: <...>
+- Goal sentence candidate: "<...>"
+- Writing points: <list>
+- Gaps: <list with severity>
+
+### 4. Paragraph 4: Key Challenges (at most 3)
+- Purpose: <...>
+- Writing points:
+  - Challenge 1: ... why naive fails
+  - Challenge 2: ...
+  - Challenge 3: ...
+- Gaps: <list with severity>
+
+### 5. Paragraph 5: Solution Overview
+- Purpose: <...>
+- Challenge to module mapping:
+  - Challenge 1 -> Module A
+  - Challenge 2 -> Module B
+  - Challenge 3 -> Module C
+- Writing points: <list>
+- Gaps: <list with severity>
+
+### 6. Paragraph 6: Contributions
+1. <contribution 1> (Section <X>)
+2. <contribution 2> (Section <Y>)
+3. <contribution 3> (Section <Z>)
+4. <contribution 4 if applicable> (Section <W>)
+- Gaps: <list with severity>
+
+### 7. Flowchart consistency
+- Running-example loop: <pass or fail>
+- Limitations-challenges link: <pass or fail>
+- Goal-contribution1 link: <pass or fail>
+- Challenge-module mapping: <pass or fail>
+- Contribution-section mapping: <pass or fail>
+
+### 8. Integrity gate result
+- Gate 1-7: <pass or fail>
+
+### 9. Severity summary
+- <n> CRITICAL, <m> MAJOR, <k> MINOR
+- Top three actions first: ...

package/dist/skills/intro-drafter/references/contribution-patterns.md

@@ -0,0 +1,116 @@
+# Contribution-paragraph patterns
+
+## Table of contents
+
+1. Canonical structure
+2. Strong contribution phrasing
+3. Weak contribution phrasing
+4. Anti-patterns
+5. Section-number mapping
+6. Pre-submission contribution audit
+
+## 1. Canonical structure
+
+A typical Introduction Paragraph 6 contains three or four numbered
+contributions:
+
+- **C1**: Problem formulation or setting (only for New Problem/Setting
+  Papers) or a system or framework design (for Technique Papers).
+- **C2**: One or two key technical contributions. These are the
+  specific algorithms, data structures, or theoretical results the
+  paper introduces.
+- **C3**: Empirical evaluation with specific highlights.
+- **C4** (optional): A secondary contribution such as an open-source
+  release, a specialised model, or a cross-domain transfer result.
+
+Each contribution should be:
+
+- One to two sentences long.
+- Specific enough that removing it changes the paper's claim.
+- Mapped to a section number or set of section numbers.
+
+## 2. Strong contribution phrasing
+
+Strong contributions name the specific mechanism or result, cite a
+section, and are defensible against a reviewer who asks "where in
+the paper do you deliver this?".
+
+Examples:
+
+- "We propose `<framework name>`, the first system to do X under
+  constraint Y, described in Section 3."
+- "We introduce `<algorithm name>`, which reduces Z from O(n^2) to
+  O(n log n), with proofs in Section 4."
+- "We evaluate on `<benchmark>` against 12 baselines and show <gain>
+  point gains on <metric>, with fine-grained analysis in Section 5."
+- "We release `<dataset name>`, the first dataset to contain
+  <property>, available at <url>. See Section 6."
+
+## 3. Weak contribution phrasing
+
+Weak contributions are vague, unfalsifiable, or are expected work
+that should not count as a contribution.
+
+Examples of weak phrasing to avoid:
+
+- "Extensive experiments demonstrate the effectiveness of our
+  method." (Expected; not a contribution.)
+- "We provide a comprehensive analysis." (Vague; describes every
+  paper ever written.)
+- "Our approach is state-of-the-art." (Claim, not contribution.)
+- "We improve on prior work." (By how much, on what?)
+- "We propose a new method." (Which? What does it do?)
+
+## 4. Anti-patterns
+
+- **Padded contribution count**: using four contributions when the
+  paper only has three. The last slot is a vague phrase. Cut it.
+- **Overlapping contributions**: contribution 2 and contribution 3
+  describe the same mechanism from different angles. Merge them.
+- **Contribution-section mismatch**: contribution cites Section 5 but
+  Section 5 does not deliver it. Reviewers will quote this in major
+  revisions.
+- **Promise-and-forget**: contribution promises a specific result
+  (say, "10x speedup") that the experiments section does not
+  support.
+- **Retrofit**: contributions written after the experiments succeeded
+  that cherry-pick only what worked. Discipline: write contributions
+  before running experiments.
+- **Marketing-style inflation**: "revolutionary", "paradigm-shifting",
+  "breakthrough" as adjectives. Cut these; let the evidence speak.
+
+## 5. Section-number mapping
+
+Every contribution references at least one section. Typical mapping:
+
+- C1 (problem formulation or framework design) -> Section 2 or 3.
+- C2 (key technical contribution) -> Section 3 or 4.
+- C3 (empirical evaluation) -> Section 5.
+- C4 (optional: dataset, release, cross-domain transfer) -> Section 6
+  or appendix.
+
+The mapping is explicit in the Introduction, for example
+"(Section 3.2)" or "(Sections 4-5)". If a contribution does not map
+to a section, either the section is missing or the contribution is
+overreach; fix accordingly.
+
+## 6. Pre-submission contribution audit
+
+Before submitting, run this quick audit on the Contributions
+paragraph.
+
+- [ ] Contribution count is 3 or 4.
+- [ ] Each contribution fits one to two sentences.
+- [ ] Each contribution names a specific mechanism, result, or
+  artefact.
+- [ ] Each contribution cites a section.
+- [ ] No contribution uses only vague phrases.
+- [ ] Every challenge from Paragraph 4 is addressed by a
+  contribution.
+- [ ] Every claim in a contribution is delivered by the cited
+  section.
+- [ ] No contribution overclaims beyond what the paper's experiments
+  show.
+
+Failing any item is a MAJOR gap. Missing section-mapping for even
+one contribution is CRITICAL.

package/dist/skills/intro-drafter/references/flowchart.md

@@ -0,0 +1,204 @@
+# The six-paragraph Introduction flowchart
+
+## Table of contents
+
+1. Chain of reasoning
+2. Paragraph 1: Background and Motivation
+3. Paragraph 2: Limitations of existing work
+4. Paragraph 3: Problem essence and Our Goal
+5. Paragraph 4: Key challenges
+6. Paragraph 5: Solution overview
+7. Paragraph 6: Contributions
+8. Pitfalls at each stage
+
+## 1. Chain of reasoning
+
+```
+Background + Running Example
+   -> Limitations (at most 3)
+      -> Problem Essence + Our Goal
+         -> Key Challenges (at most 3)
+            -> Solution Overview (one module per challenge)
+               -> Contributions (3 to 4, each mapped to a section)
+```
+
+Every arrow must hold. If any arrow breaks, the Introduction reads as
+a list of disjointed claims rather than a single argument. Reviewers
+notice this and score down.
+
+## 2. Paragraph 1: Background and Motivation
+
+### Purpose
+
+Introduce the research object, motivate why the problem matters in
+the real world, and ground the rest of the paper in a concrete
+running example.
+
+### Writing points
+
+- Open with the task, not the technique. The reader should care
+  about the problem before hearing about the solution.
+- Include a specific running example, ideally with an accompanying
+  figure (Figure 1). The example should be self-contained and show
+  the problem's complexity in under 30 seconds of reading.
+- Cite three to five recent real applications or deployments as
+  evidence of importance.
+- One paragraph, approximately 150-200 words.
+
+### Common failures
+
+- Opening with a technique ("we introduce X for Y").
+- Generic motivation ("deep learning is important").
+- No running example; the paper never becomes tangible.
+
+## 3. Paragraph 2: Limitations of existing work
+
+### Purpose
+
+Identify what prior work does not address, in at most three
+limitations.
+
+### Writing points
+
+- Each limitation is framed as "prior work X does not handle Y".
+- Each limitation is specific enough that a reader can name the
+  capability that is missing.
+- Limitations motivate the challenges in Paragraph 4. There should
+  be a visible link: each challenge addresses a limitation.
+- Two limitations is acceptable; do not pad to three artificially.
+- One paragraph, approximately 150-200 words.
+
+### Common failures
+
+- Vague limitations ("existing work is insufficient").
+- Too many limitations; after three, the paper loses focus.
+- Limitations that have nothing to do with the challenges in
+  Paragraph 4; the reader cannot see why they were raised.
+
+## 4. Paragraph 3: Problem essence and Our Goal
+
+### Purpose
+
+Characterise the problem's intrinsic properties and hard constraints,
+then state the research goal or key idea.
+
+### Writing points
+
+- Hard constraints are explicit: scale, dynamicity, heterogeneity,
+  end-to-end latency, correctness, or consistency requirements.
+- For a Technique Paper, the Goal is a one-sentence bridge: "Our
+  goal is to handle Y with better accuracy." Key Idea carries the
+  weight.
+- For a New Problem / Setting Paper, the Goal is the paper's core
+  contribution: "Our goal is to handle Y under constraint Z, a
+  setting that has not been studied." Key Idea supports "why this
+  definition is reasonable".
+- If a Research Question is better than a Goal, state it as a
+  question.
+- One paragraph, approximately 100-150 words for Technique papers,
+  200-250 words for New Problem papers.
+
+### Common failures
+
+- Skipping hard constraints; Paragraph 4 challenges then have no
+  grounding.
+- Stating the goal as a list of sub-goals; reviewers lose focus.
+- For New Problem papers, underweighting this paragraph as if it
+  were a Technique Paper.
+
+## 5. Paragraph 4: Key challenges
+
+### Purpose
+
+Enumerate the two or three obstacles that prevent a naive extension
+of prior work from solving the problem.
+
+### Writing points
+
+- Each challenge is one sentence naming the obstacle plus one to
+  two sentences explaining why naive methods fail.
+- Challenges address the limitations from Paragraph 2 or the hard
+  constraints from Paragraph 3.
+- Common challenge categories:
+  - Search-space explosion.
+  - Efficiency or latency ceilings.
+  - End-to-end closed-loop difficulty.
+  - Theoretical or engineering conflict.
+- At most three challenges. Four or more signals scope issues.
+- One paragraph, approximately 150-200 words.
+
+### Common failures
+
+- Vague challenge statements ("it is hard").
+- Challenges that do not map to modules in Paragraph 5.
+- Pre-announcing solutions inside challenge statements.
+
+## 6. Paragraph 5: Solution overview
+
+### Purpose
+
+Present the paper's methodology at a high level, with a one-to-one
+mapping between the challenges in Paragraph 4 and the modules or
+components introduced here.
+
+### Writing points
+
+- Start with a one-sentence topic sentence naming the solution
+  framework.
+- For each challenge, name the module that addresses it.
+- Explicit one-to-one mapping; if a module addresses two challenges,
+  say so.
+- Methodology section numbers are forward-referenced in parentheses.
+- One paragraph, approximately 150-200 words.
+
+### Common failures
+
+- Over-detail that belongs in Section 3 (Methodology).
+- No explicit mapping; reviewers must infer which module handles
+  which challenge.
+- Module count mismatches challenge count without explanation.
+
+## 7. Paragraph 6: Contributions
+
+### Purpose
+
+Summarise the paper's contributions in three or four numbered bullets,
+each mapped to a section or set of sections.
+
+### Writing points
+
+- Canonical structure:
+  - C1: Problem definition or problem-setting contribution (if the
+    paper is a New Problem / Setting Paper).
+  - C2: System or framework design, or a specific methodological
+    innovation.
+  - C3: One or two key technical contributions (specific algorithms,
+    theoretical results, or data structures).
+  - C4: Comprehensive experimental evaluation with specific
+    highlights (not vague claims).
+- Each contribution cites a section: "(Section 3.2)" or "(Sections
+  4-5)".
+- No single contribution is a vague phrase like "extensive
+  experiments".
+- One paragraph or a numbered list; approximately 100-150 words.
+
+### Common failures
+
+- Vague phrases as contributions.
+- Contributions that the paper does not actually deliver.
+- More than four contributions; focus erodes.
+
+## 8. Pitfalls at each stage
+
+- **Stage 1 pitfall**: running example is an abstraction (graph, LLM,
+  system); not tangible enough.
+- **Stage 2 pitfall**: limitations list is longer than three or
+  padded.
+- **Stage 3 pitfall**: goal is unclear; reader cannot say in one
+  sentence what the paper tries to do.
+- **Stage 4 pitfall**: more challenges than modules, or challenges
+  invented to justify modules rather than derived from the problem.
+- **Stage 5 pitfall**: module names do not appear in Paragraph 6's
+  contributions, so the reader loses track.
+- **Stage 6 pitfall**: contributions include items the paper does not
+  deliver; in major revisions, reviewers quote these.