@research-copilot/plugin 1.1.16 → 1.1.18

package/dist/skills/pixel-art/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: "pixel-art"
+description: "Generate pixel art SVG illustrations for READMEs, docs, or slides. Use when user says \"\u753b\u50cf\u7d20\u56fe\", \"pixel art\", \"make an SVG illustration\", \"README hero image\", or wants a cute visual."
+---
+
+# Pixel Art SVG Generator
+
+Create a pixel art SVG illustration: $ARGUMENTS
+
+## Design Principles
+
+### Pixel Grid
+- Each "pixel" is a `<rect>` with width/height of 7px
+- Grid spacing: 7px (no gaps between pixels)
+- Characters are typically 8-10 pixels wide, 8-12 pixels tall
+- Use `<g transform="translate(x,y)">` to position and reuse character groups
+
+### Color Palette
+Keep it simple — 3-5 colors per character:
+- **Skin**: `#FFDAB9` (light), `#E8967A` / `#D4956A` (blush/shadow)
+- **Eyes**: `#333`
+- **Hair**: `#8B5E3C` (brown), `#2C2C2C` (black), `#FFD700` (blonde), `#C0392B` (red)
+- **Clothes**: use project's brand color (e.g. `#4A9EDA` for blue, `#74AA63` for green)
+- **Shoes/pants**: `#444`
+- **Accessories**: `#555` (glasses frames), `#FFD700` (crown)
+
+### Character Template (7px grid)
+```
+Row 0 (hair top):     4 pixels centered
+Row 1 (hair):         6 pixels wide
+Row 2 (face top):     6 pixels — all skin
+Row 3 (eyes):         6 pixels — skin, eye, skin, skin, eye, skin
+Row 4 (mouth):        6 pixels — skin, skin, mouth, mouth, skin, skin
+Row 5 (body top):     8 pixels — hand, 6 shirt, hand
+Row 6 (body):         6 pixels — all shirt
+Row 7 (legs):         2+2 pixels — with gap in middle
+```
+
+### Scene Composition
+
+#### Chat Dialogue Layout (like our hero image)
+- Two characters on left/right sides, vertically centered
+- Chat bubbles between them, alternating left/right
+- Bubble tails point toward the speaking character
+- Arrows between bubbles show direction of communication
+- Use `orient="auto"` markers for arrow heads
+- Bottom: tagline or decoration
+
+#### Single Character with Label
+- Character centered
+- Label text below
+- Optional: speech bubble above
+
+#### Group Scene
+- Characters spaced evenly
+- Optional: ground line, background elements
+- Keep viewBox tight — no wasted space
+
+### SVG Structure
+```xml
+<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 W H" font-family="monospace">
+  <defs>
+    <!-- Arrow markers if needed -->
+  </defs>
+
+  <rect width="W" height="H" fill="#fafbfc" rx="12"/>  <!-- Background -->
+
+  <!-- Characters via <g transform="translate(...)"> -->
+  <!-- Dialogue bubbles: <rect> + <polygon> tail + <text> -->
+  <!-- Arrows: <line> with marker-end -->
+  <!-- Labels: <text> with text-anchor="middle" -->
+</svg>
+```
+
+### Chat Bubble Recipe
+```xml
+<!-- Blue bubble (left character speaks) -->
+<rect x="110" y="29" width="280" height="26" fill="#e8f4fd" stroke="#4a9eda" stroke-width="1.5" rx="8"/>
+<!-- Tail pointing left toward character -->
+<polygon points="108,41 99,47 108,46" fill="#e8f4fd" stroke="#4a9eda" stroke-width="1.5"/>
+<rect x="107" y="40" width="3" height="7" fill="#e8f4fd"/>  <!-- covers stroke at junction -->
+<text x="123" y="46" font-size="13px">📄 Message here</text>
+
+<!-- Orange bubble (right character responds) -->
+<rect x="490" y="71" width="280" height="26" fill="#fdf2e8" stroke="#da8a4a" stroke-width="1.5" rx="8"/>
+<!-- Tail pointing right toward character -->
+<polygon points="772,83 781,89 772,88" fill="#fdf2e8" stroke="#da8a4a" stroke-width="1.5"/>
+<rect x="770" y="82" width="3" height="7" fill="#fdf2e8"/>
+<text x="503" y="88" font-size="13px">🤔 Response here</text>
+```
+
+### Arrow Recipe
+```xml
+<defs>
+  <marker id="ar" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
+    <polygon points="0 0, 8 3, 0 6" fill="#4a9eda"/>
+  </marker>
+</defs>
+<!-- Right arrow (→): x1 < x2 -->
+<line x1="392" y1="42" x2="465" y2="42" stroke="#4a9eda" stroke-width="2" marker-end="url(#ar)"/>
+<!-- Left arrow (←): x1 > x2 -->
+<line x1="488" y1="84" x2="420" y2="84" stroke="#da8a4a" stroke-width="2" marker-end="url(#ar-o)"/>
+```
+
+## Workflow
+
+### Step 1: Understand the Request
+- What characters/objects to draw?
+- What's the scene? (dialogue, portrait, group, diagram)
+- What colors/brand to match?
+- What size? (compact for badge, wide for README hero)
+
+### Step 2: Generate SVG
+- Write to a temp file or project directory
+- Open with a local preview command for visual inspection
+- Keep viewBox tight — measure actual content bounds
+
+### Step 3: Iterate with User
+- User provides feedback on screenshot
+- Common fixes: overlap, arrow direction, spacing, sizing
+- Use `Edit` for small tweaks, `Write` for major redesigns
+- Typical: 2-4 iterations to get it right
+
+### Step 4: Finalize
+- Ensure no personal info in the SVG
+- Clean up: remove unused defs, tighten viewBox
+- Suggest adding to README: `![Alt text](filename.svg)`
+
+## Capability Rule
+
+If the user expects local preview or interactive visual iteration and the current environment cannot open or preview the generated asset, stop and tell the user what needs to be configured. Do not silently downgrade into a write-only path unless the user explicitly asked for that mode.
+
+## Common Pitfalls
+- **Arrow direction**: `orient="auto"` follows line direction. Line going right→left = arrowhead points left
+- **Bubble overlap**: keep 38-44px vertical spacing between rows
+- **Text overflow**: monospace 13px ≈ 7.8px/char, emoji ≈ 14px. Measure before setting bubble width
+- **Character overlap with bubbles**: keep character x-zone and bubble x-zone separated by ≥10px
+- **viewBox too large**: match viewBox to actual content, add ~10px padding
+- **Tail stroke artifact**: always add a small `<rect>` at the bubble-tail junction to cover the stroke line

package/dist/skills/pre-submission-reviewer/SKILL.md

@@ -0,0 +1,247 @@
+---
+name: pre-submission-reviewer
+description: >-
+  Runs a pre-submission review of a technical paper across five
+  dimensions: macro logic, writing details, English grammar, LaTeX
+  formatting, and figure quality. Uses a reviewer-style severity
+  taxonomy (CRITICAL / MAJOR / MINOR) and flags banned AI-tone
+  vocabulary and em-dash misuse. Use when the user asks to 'review
+  this paper', 'audit before submission', 'check the draft', 'find
+  issues', 'proofread', or within one week of a submission
+  deadline.
+license: CC-BY-4.0
+---
+
+# Pre-Submission Reviewer
+
+## Overview
+
+Three to five days before a submission deadline is the window where
+a careful external review pays off most. This skill takes a full
+paper or key sections and produces a structured review across five
+dimensions, each with severity-tagged findings and concrete
+rewrite suggestions. It enforces the mechanical rules from the
+writing-checklist section (no em-dashes, no banned AI-tone
+vocabulary, leading text per paragraph, topic-sentence discipline,
+citation-format uniformity) and surfaces the patterns that
+non-native English-speaking authors most commonly violate
+(articles, subject-verb agreement, tense consistency, which versus
+that, Chinglish phrasing).
+
+The output is not a rewrite. It is a prioritised list of findings
+with severity tags; the author decides which to fix. CRITICAL items
+should block submission until addressed.
+
+## When to use this skill
+
+- Three to five days before a submission deadline.
+- The user asks to 'review this paper', 'audit before submission',
+  'check the draft', 'find issues', 'proofread'.
+- After a camera-ready revision, before sending the final version.
+- After any major rewrite (rebuttal responses, Section 3 overhaul).
+- When the user suspects AI-tone contamination in a section.
+
+## When NOT to use this skill
+
+- The paper is still being structured. Use `tech-paper-template`,
+  `intro-drafter`, or `benchmark-paper-template` (separate plugin) first.
+- The user wants structural advice rather than review. Use the
+  drafting skills instead.
+
+## Core procedure
+
+### Step 1: Dimension 1 Macro logic review
+
+See: references/logic-and-structure.md for the Logic First rule,
+Self-contained rule, Leading Text rule, and Running Example rule.
+
+Check:
+
+- Introduction flowchart is intact (Background, Limitations, Goal
+  or Key Idea, Challenges, Methodology, Contributions).
+- Contributions map one-to-one with methodology modules and with
+  section numbers.
+- Experiments validate the paper's main claims, not tangential
+  ones.
+- Related Work covers the necessary prior art.
+- Running example is consistent across Introduction, Methodology,
+  Experiments.
+
+Every break in the chain is CRITICAL.
+
+### Step 2: Dimension 2 Writing details review
+
+See: references/logic-and-structure.md for paragraph-level rules.
+
+Check:
+
+- Every paragraph has a topic sentence.
+- Paragraphs transition smoothly; no orphan paragraphs.
+- Paragraphs are not over 10 lines; split if so.
+- No repeated or redundant passages.
+- Abstract covers problem, method, result.
+
+### Step 3: Dimension 3 English grammar review
+
+See: references/grammar-rules.md for the canonical list of errors
+common to non-native English authors, with corrections and
+examples.
+
+Check the usual suspects:
+
+- Article use (a, an, the).
+- Subject-verb agreement (third-person singular).
+- Tense consistency (Related Work past, method present).
+- Passive-voice overuse.
+- Which versus that.
+- Sentence length; split long sentences at "Specifically,".
+- Chinglish patterns.
+
+### Step 4: Dimension 4 LaTeX format review
+
+See: references/latex-rules.md for the canonical list of LaTeX-
+specific issues.
+
+Check:
+
+- Equation numbering contiguous; every numbered equation
+  referenced.
+- Figures and tables have captions; captions are detailed.
+- Citations use the correct command and the non-breaking tilde
+  (for example, `ResNet~\cite{X}`, never `ResNet\cite{X}`).
+- Labels use underscores, not spaces or hyphens.
+- Vector figure format; no raster.
+- Page-limit compliance.
+
+### Step 5: Dimension 5 Figure quality review
+
+See: references/forbidden-patterns.md for chartjunk patterns and
+the full figure-quality checklist.
+
+For each figure:
+
+- Vector format.
+- Font size large enough post-scaling.
+- Colour-blind-safe palette; dual encoding.
+- Self-contained caption with a finding in the first sentence.
+- No chartjunk.
+- Motivated example is concrete and failure-revealing.
+- Solution overview has labels matching section titles.
+
+### Step 6: Banned-vocabulary and em-dash scan
+
+See: references/forbidden-patterns.md for the banned-word list.
+
+Scan the full paper for:
+
+- Em-dashes used as sentence connectors (banned; project rule).
+- AI-tone words: innovative, pioneering, revolutionary paradigm,
+  transformative framework, superior, surpass, excel, remarkable,
+  unprecedented, breakthrough performance, general-purpose, is
+  capable of, notably, yet, yielding, at its essence, encompass,
+  differentiate, reveal, underscore, pave the way for, highlight
+  the potential of, profound challenges, stems from, rigid,
+  impede.
+
+Flag each occurrence with a severity tag. Em-dashes are MAJOR by
+default; banned AI-tone words are MAJOR if they appear three or
+more times.
+
+### Step 7: Section-by-section review
+
+See: references/section-guides.md for the per-section writing
+guides for Abstract, Introduction, Problem Formulation, Framework
+or Method, Experiments, Related Work, and Conclusion.
+
+For each section, check that the section's content matches the
+guide's canonical structure (for example, Abstract's five-sentence
+formula: what, why, challenges, how, results).
+
+### Step 8: Integrity gate
+
+Run the checks in the Integrity gate section below.
+
+### Step 9: Output
+
+Emit the review in the Output format below.
+
+## Severity taxonomy
+
+- **CRITICAL**: blocks submission. Example: contributions do not
+  map to sections; introduction flowchart broken; no real-world
+  running example; raster figure in final draft; missing key
+  baseline; page-limit violation.
+- **MAJOR**: reviewers will flag in first round. Example:
+  topic-sentence absent from 3+ paragraphs; em-dash in 5+ places;
+  banned AI-tone word in 3+ places; Table 1 comparison missing;
+  chart type mismatched with data.
+- **MINOR**: polish. Example: two long sentences that could be
+  split; default Matplotlib styling; single article error.
+
+## Integrity gate
+
+Each bullet is tagged [inspection] (LLM verifies from the paper
+text) or [attestation] (LLM runs the procedure and states it has
+done so; user remains responsible for confirming completeness).
+
+Before emitting the review:
+
+1. **[inspection]** Every finding quotes specific text (sentence,
+   phrase, figure name); no "the Introduction is unclear" without
+   a quoted line.
+2. **[inspection]** Every CRITICAL finding has a concrete fix
+   suggestion, not "rewrite entirely".
+3. **[inspection]** No fabricated quotes: only text actually
+   present in the submitted material.
+4. **[inspection]** Severity assignments follow the taxonomy;
+   nothing is marked CRITICAL for taste reasons.
+5. **[inspection]** Dimension 3 (grammar) findings cite the
+   specific grammar rule from `references/grammar-rules.md`.
+6. **[attestation]** Dimension 6 banned-vocabulary scan is run in
+   full on the entire paper, not sampled. The skill attests the
+   full scan; if the paper is extremely long, the skill states it
+   chunked the input and describes the chunking strategy.
+7. **[inspection]** Final score matches the CRITICAL + MAJOR
+   count; a score of 9 or 10 requires zero CRITICAL and at most
+   two MAJOR items.
+
+If any [inspection] check fails, mark the output as "needs user
+attention". For [attestation] bullets, the skill states the scope
+of its scan and the user confirms completeness.
+
+## Output format
+
+### Summary
+- CRITICAL: <n>
+- MAJOR: <m>
+- MINOR: <k>
+- Top three fixes first: ...
+
+### Dimension 1: Macro logic
+| # | Finding | Severity | Suggested fix |
+|---|---|---|---|
+| 1 | <quoted text> | CRITICAL or MAJOR or MINOR | <fix> |
+
+### Dimension 2: Writing details
+<same table shape>
+
+### Dimension 3: English grammar
+<same table shape, citing grammar-rule ID>
+
+### Dimension 4: LaTeX format
+<same table shape>
+
+### Dimension 5: Figure quality
+<same table shape>
+
+### Banned-vocabulary and em-dash scan
+<list with line references>
+
+### Integrity gate result
+- Gate 1 through 7: <pass or fail>
+
+### Final score (1-10)
+<score>
+
+### Submission recommendation
+- <Ready to submit | Needs 1-2 days more work | Needs major revision before submission>

package/dist/skills/pre-submission-reviewer/references/forbidden-patterns.md

@@ -0,0 +1,163 @@
+# Forbidden patterns
+
+## Table of contents
+
+1. Em-dash misuse
+2. Banned AI-tone vocabulary
+3. Chartjunk patterns
+4. Overclaim patterns
+5. Plagiarism red lines
+6. Detection heuristics
+
+## 1. Em-dash misuse
+
+Em-dashes used as sentence connectors are banned in this
+project's writing conventions. Two common misuse patterns:
+
+### Misuse A: connecting two independent clauses
+
+- Bad: "... closes the research loop, from literature analysis to
+  deployment."
+- Good (using comma plus subordinate clause): "... closes the
+  research loop, covering literature analysis, hypothesis
+  generation, simulation, validation, and deployment."
+
+### Misuse B: inserting a parenthetical
+
+- Bad: "This approach, though simple, is highly effective."
+- Good (using a subordinate clause): "Although simple, this
+  approach is highly effective."
+
+Acceptable em-dash uses are rare in academic writing. When in
+doubt, do not use them. Commas, colons, or periods handle nearly
+every case.
+
+Detection: grep for the Unicode em-dash character. Every
+occurrence in the body is a MAJOR finding unless explicitly in a
+code sample or preserved quotation.
+
+## 2. Banned AI-tone vocabulary
+
+The following vocabulary signals AI-authored or AI-assisted prose
+to experienced reviewers and should be avoided. Seeing three or
+more uses in a paper is a MAJOR finding.
+
+### Innovation hyperbole
+
+innovative, pioneering, revolutionary paradigm, transformative
+framework
+
+### Performance hyperbole
+
+superior, surpass, excel, remarkable, unprecedented, achieves
+SOTA, breakthrough performance
+
+### Contribution-summary markers
+
+general-purpose, is capable of
+
+### Logical connective markers
+
+notably, yet, yielding, at its essence
+
+### Overused verbs
+
+encompass, differentiate, reveal, underscore, surpass, exhibit
+superior capability, exceed, pave the way for, highlight the
+potential of
+
+### Overused phrases
+
+profound challenges (this collocation does not exist in standard
+writing), stems from
+
+### Overused adjectives and verbs
+
+rigid, impede
+
+Replace with neutral technical verbs from the section-guides
+reference: propose, introduce, design, present, show, demonstrate,
+report, observe.
+
+## 3. Chartjunk patterns
+
+Chart elements that add visual noise without information:
+
+- 3D bar charts, 3D pie charts.
+- Drop shadows on bars or points.
+- Gradient fills except where a gradient encodes a continuous
+  variable.
+- Heavy grid lines.
+- Cross-hatching for decoration.
+- Chart titles duplicating the caption.
+- Legend keys with more than six entries (try grouping instead).
+
+Each chartjunk instance is a MINOR or MAJOR finding depending on
+severity.
+
+## 4. Overclaim patterns
+
+Overclaims common in draft papers:
+
+- "Our method is state-of-the-art" without qualification. State
+  state-of-the-art on which benchmark, under which conditions.
+- "Comprehensive experiments" as a contribution. Experiments are
+  expected; what was specifically shown?
+- "Extensive analysis". Name what the analysis found, not that
+  analysis exists.
+- "We solve the problem of X". Solving is a strong claim; usually
+  the paper improves on X rather than solves.
+- "We are the first to". Verify carefully; if the claim is wrong,
+  reviewers will find and quote it.
+
+Each overclaim is a MAJOR finding. Reviewers keep a running
+grudge against papers that overclaim in the Introduction; the
+cost compounds over the review cycle.
+
+## 5. Plagiarism red lines
+
+Never copy sentences from other papers, including the author's
+own prior papers without explicit reuse acknowledgement. This
+applies to:
+
+- Related Work summaries of prior methods.
+- Introduction references to prior work.
+- Method descriptions that resemble baseline papers' own
+  descriptions.
+
+Plagiarism detection is a CRITICAL finding that blocks submission.
+When the paper's Related Work or Introduction paraphrases prior
+work too closely, rewrite in the author's own words.
+
+## 6. Detection heuristics
+
+For the banned-vocabulary scan:
+
+- Case-insensitive substring search for each banned term.
+- Count occurrences per term.
+- Three or more occurrences of any single banned term is MAJOR.
+- Single occurrence is MINOR.
+
+For em-dash scan:
+
+- Search for the Unicode em-dash character.
+- Every occurrence is a finding.
+- Severity is MAJOR if in body; MINOR if in preserved quotations.
+
+For chartjunk scan:
+
+- Cannot be done automatically; the skill relies on the user's
+  figure description or on an uploaded figure.
+
+For overclaim scan:
+
+- Look for unconditional superlatives: "is state-of-the-art", "is
+  superior", "beats all".
+- Flag each occurrence with a request to qualify or substantiate.
+
+For plagiarism:
+
+- Random sentence-level search of the Related Work and
+  Introduction against public texts is not feasible inside the
+  skill. Recommend an external plagiarism checker for final
+  submission.

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

@@ -0,0 +1,135 @@
+# Grammar rules for non-native English authors
+
+## Table of contents
+
+1. Article usage
+2. Subject-verb agreement
+3. Tense consistency
+4. Sentence complexity
+5. Which versus that
+6. Passive voice
+7. Chinglish patterns
+8. Punctuation in quotations
+
+## 1. Article usage
+
+Rule G1: singular countable nouns require an article (a, an, the)
+unless they are generic plurals or proper nouns.
+
+| Bad | Good |
+|---|---|
+| We propose novel method. | We propose a novel method. |
+| in descending order | in a descending order |
+| Our model supports the case changed. | Our model supports the case that changed. |
+
+Quick test: if the noun is countable and singular, and the
+sentence is about a specific instance, the article is required.
+For generic plurals, articles are omitted. For uncountable nouns
+(information, evidence), articles are usually omitted.
+
+## 2. Subject-verb agreement
+
+Rule G2: third-person singular subjects take third-person
+singular verbs.
+
+- it predicts, it proposes, it improves.
+- we propose, we show, we introduce.
+- they demonstrate, they report.
+
+The ICML or VLDB paper (singular) uses the third-person singular
+verb form:
+
+- The method predicts accurately.
+- Not: The method predict accurately.
+
+## 3. Tense consistency
+
+Rule G3: different sections have different default tenses.
+
+- Abstract: present tense for the paper, past tense for
+  experiments.
+- Introduction: present for the paper's claims, past for related
+  work references.
+- Methodology: present tense (the method does X).
+- Experiments: past tense (we ran the experiment, we observed).
+- Related Work: past tense for summarising prior work's
+  contributions.
+- Conclusion: present perfect tense (we have shown, we have
+  proposed).
+
+Mixing tenses within a single sentence or paragraph is a common
+reviewer complaint.
+
+## 4. Sentence complexity
+
+Rule G4: one sentence, one main idea. Two verbs in one sentence
+require a connector. Avoid sentences with two independent clauses
+joined only by a comma (comma splice).
+
+| Bad | Good |
+|---|---|
+| We propose a method has high efficiency. | We propose a method that has high efficiency. |
+| We propose a method has high efficiency. | We propose a high-efficiency method. |
+| We propose a method, it has high efficiency. | We propose a method. It has high efficiency. |
+| We propose a method, it has high efficiency. | We propose a method with high efficiency. |
+
+Long sentences should be split at natural boundaries. Use
+"Specifically," or "In particular," to start the continuation
+sentence rather than stuffing everything into one complex
+sentence.
+
+## 5. Which versus that
+
+Rule G5: use "that" for restrictive clauses (essential to the
+meaning); use "which" for non-restrictive clauses (parenthetical
+and set off by commas).
+
+- Restrictive: "the method that achieves state of the art" (out
+  of a set, the one that achieves).
+- Non-restrictive: "the method, which achieves state of the art,"
+  (an aside).
+
+Non-native authors commonly use "which" in both cases. Correct
+to "that" when the clause is restrictive.
+
+## 6. Passive voice
+
+Rule G6: prefer active voice unless the subject is genuinely not
+important. "The method was evaluated" is acceptable when the
+evaluator's identity does not matter; "We evaluated the method"
+is stronger when it does.
+
+Over-use of passive voice makes prose feel evasive. Audit
+paragraphs for strings of passive constructions and replace the
+most important sentences with active voice.
+
+## 7. Chinglish patterns
+
+Common Chinglish patterns to flag:
+
+- Direct translation of Chinese idioms that do not carry in
+  English.
+- Overuse of "very" (赶很多中文用户会用 "very"; often unnecessary).
+- Use of the same word several times in short succession where
+  a synonym would be clearer.
+- Over-hedged statements ("it may be the case that perhaps the
+  method possibly") when a direct statement is clearer.
+- Translating a Chinese draft with a machine translator. Never do
+  this; the output accumulates un-idiomatic phrasing that
+  reviewers notice immediately. Write in English from the start.
+
+## 8. Punctuation in quotations
+
+Rule G8: in an academic writing context, use logical punctuation
+(punctuation inside quotation marks only if part of the quoted
+material). LLM-generated text often defaults to American typography
+(punctuation always inside); correct this for academic English.
+
+| American (avoid) | Logical (use) |
+|---|---|
+| approach is called "data-centric AI," which emphasises | approach is called "data-centric AI", which emphasises |
+| outputs what it calls "semantic summaries." | outputs what it calls "semantic summaries". |
+
+Also: use backticks and single or double quotation marks per
+LaTeX convention: `` `` `` for open and `'' '` for close, not the
+straight typewriter character.