@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/feishu-notify/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: "feishu-notify"
+description: "Send notifications to Feishu/Lark. Internal utility used by other skills, or manually via /feishu-notify. Use when user says \"发飞书\", \"notify feishu\", or other skills need to send status updates."
+---
+
+# Feishu/Lark Notification
+
+Send a notification: **$ARGUMENTS**
+
+## Overview
+
+This skill provides Feishu/Lark integration for ARIS. It is designed as an **internal utility** — other skills call it at key events (experiment done, review scored, checkpoint waiting). It can also be invoked manually.
+
+**Zero-impact guarantee**: If no `feishu.json` config exists, this skill does nothing and returns silently. All existing workflows are completely unaffected.
+
+## Configuration
+
+The skill reads `~/.codex/feishu.json`. If this file does not exist, **all Feishu functionality is disabled** — skills behave exactly as before.
+
+### Config Format
+
+```json
+{
+  "mode": "push",
+  "webhook_url": "https://open.feishu.cn/open-apis/bot/v2/hook/YOUR_WEBHOOK_ID",
+  "interactive": {
+    "bridge_url": "http://localhost:5000",
+    "timeout_seconds": 300
+  }
+}
+```
+
+### Modes
+
+| Mode | `"mode"` value | What it does | Requires |
+|------|----------------|--------------|----------|
+| **Off** | `"off"` or file absent | Nothing. Pure CLI as-is | Nothing |
+| **Push only** | `"push"` | Send webhook notifications at key events. Mobile push, no reply | Feishu bot webhook URL |
+| **Interactive** | `"interactive"` | Full bidirectional. Approve/reject from Feishu, reply to checkpoints | [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) running |
+
+## Workflow
+
+### Step 1: Read Config
+
+```bash
+cat ~/.codex/feishu.json 2>/dev/null
+```
+
+- **File not found** → return silently, do nothing
+- **`"mode": "off"`** → return silently, do nothing
+- **`"mode": "push"`** → proceed to Step 2 (push)
+- **`"mode": "interactive"`** → proceed to Step 3 (interactive)
+
+### Step 2: Push Notification (webhook)
+
+Send a rich card to the Feishu webhook:
+
+```bash
+curl -s -X POST "$WEBHOOK_URL" \
+  -H "Content-Type: application/json" \
+  -d '{
+    "msg_type": "interactive",
+    "card": {
+      "header": {
+        "title": {"tag": "plain_text", "content": "TITLE"},
+        "template": "COLOR"
+      },
+      "elements": [
+        {"tag": "markdown", "content": "BODY"}
+      ]
+    }
+  }'
+```
+
+**Card templates by event type:**
+
+| Event | Title | Color | Body |
+|-------|-------|-------|------|
+| `experiment_done` | Experiment Complete | `green` | Results table, delta vs baseline |
+| `review_scored` | Review Round N: X/10 | `blue` (≥6) / `orange` (<6) | Score, verdict, top 3 weaknesses |
+| `checkpoint` | Checkpoint: Waiting for Input | `yellow` | Question, options, context |
+| `error` | Error: [type] | `red` | Error message, what failed |
+| `pipeline_done` | Pipeline Complete | `purple` | Final summary, deliverables |
+| `custom` | Custom | `blue` | Free-form message from $ARGUMENTS |
+
+**Return immediately after curl** — push mode never waits for a response.
+
+### Step 3: Interactive Notification (bidirectional)
+
+Interactive mode uses [feishu-claude-code](https://github.com/joewongjc/feishu-claude-code) as a bridge:
+
+1. **Send message** to the bridge:
+   ```bash
+   curl -s -X POST "$BRIDGE_URL/send" \
+     -H "Content-Type: application/json" \
+     -d '{"type": "EVENT_TYPE", "title": "TITLE", "body": "BODY", "options": ["approve", "reject", "custom"]}'
+   ```
+
+2. **Wait for reply** (with timeout):
+   ```bash
+   curl -s "$BRIDGE_URL/poll?timeout=$TIMEOUT_SECONDS"
+   ```
+   Returns: `{"reply": "approve"}` or `{"reply": "reject"}` or `{"reply": "user typed message"}` or `{"timeout": true}`
+
+3. **On timeout**: Fall back to `AUTO_PROCEED` behavior (proceed with default option).
+
+4. **Return the user's reply** to the calling skill so it can act on it.
+
+### Step 4: Verify Delivery
+
+- **Push mode**: Check curl exit code. If non-zero, log warning but do NOT block the workflow.
+- **Interactive mode**: If bridge is unreachable, fall back to push mode (if webhook configured) or skip silently.
+
+## Helper Function (for other skills)
+
+Other skills should use this pattern to send notifications:
+
+```markdown
+### Feishu Notification (if configured)
+
+Check if `~/.codex/feishu.json` exists and mode is not "off":
+- If **push** mode: send webhook notification with event summary
+- If **interactive** mode: send notification and wait for user reply
+- If **off** or file absent: skip entirely (no-op)
+```
+
+**This check is always guarded.** If the config file doesn't exist, the skill skips the notification block entirely — zero overhead, zero side effects.
+
+## Event Catalog
+
+Skills send these events at these moments:
+
+| Skill | Event | When |
+|-------|-------|------|
+| `/auto-review-loop` | `review_scored` | After each round's review score |
+| `/auto-review-loop` | `pipeline_done` | Loop complete (positive or max rounds) |
+| `/auto-paper-improvement-loop` | `review_scored` | After each round's review score |
+| `/auto-paper-improvement-loop` | `pipeline_done` | All rounds complete |
+| `/run-experiment` | `experiment_done` | Screen session finishes |
+| `/idea-discovery` | `checkpoint` | Between phases (if interactive) |
+| `/idea-discovery` | `pipeline_done` | Final report ready |
+| `/monitor-experiment` | `experiment_done` | Results collected |
+| `/research-pipeline` | `checkpoint` | Between workflow stages |
+| `/research-pipeline` | `pipeline_done` | Full pipeline complete |
+
+## Key Rules
+
+- **NEVER block a workflow** because Feishu is unreachable. Always fail open.
+- **NEVER require Feishu config** — all skills must work without it.
+- **Config file absent = mode off.** No error, no warning, no log.
+- **Push mode is fire-and-forget.** Send curl, check exit code, move on.
+- **Interactive timeout = auto-proceed.** Don't hang forever waiting for a reply.
+- **Respect `AUTO_PROCEED`**: In interactive mode, if the user doesn't reply within timeout, use the same auto-proceed logic as the calling skill.
+- **No secrets in notifications.** Never include API keys, tokens, or passwords in Feishu messages.
+

package/dist/skills/figure-description/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: figure-description
+description: "Process user-provided patent figures and generate formal drawing descriptions. Use when user says \"附图处理\", \"figure description\", \"附图说明\", \"drawings description\", or wants to describe patent figures with reference numerals."
+argument-hint: [figure-directory-or-figure-list]
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch
+---
+
+# Figure Description for Patents
+
+Process patent figures and generate drawing descriptions based on: **$ARGUMENTS**
+
+Unlike `/paper-figure` which generates data plots, this skill processes user-provided technical diagrams and assigns reference numerals.
+
+## Constants
+
+- `FIGURE_DIR = "patent/figures/"` — Output directory for figure descriptions
+- `REFERENCE_NUMERAL_PREFIX = 100` — Starting numeral for first figure's components
+- `NUMERAL_SERIES = 100` — Each figure uses a separate 100-series (Fig 1: 100-199, Fig 2: 200-299, etc.)
+
+## Inputs
+
+1. User-provided figures (PNG, JPG, SVG, PDF) — search for them in the project directory
+2. `patent/INVENTION_DISCLOSURE.md` — for understanding what components to identify
+3. `patent/CLAIMS.md` — for mapping numerals to claim elements
+
+## Workflow
+
+### Step 1: Discover Figures
+
+1. Search the project directory for figure files:
+   - Check `patent/figures/`, `figures/`, root directory
+   - Look for PNG, JPG, SVG, PDF files
+   - Check INVENTION_BRIEF.md or INVENTION_DISCLOSURE.md for figure references
+2. List all discovered figures with their paths
+3. If figures are missing that claims require, note them as `[MISSING: description needed]`
+
+### Step 2: Analyze Each Figure
+
+For each figure found:
+
+1. **Read the image** using the Read tool (supports image files)
+2. **Identify components**: What labeled or visually distinct components are shown?
+3. **Identify connections**: How do components relate to each other?
+4. **Identify flow**: If it's a flowchart or sequence, what is the step order?
+
+### Step 3: Assign Reference Numerals
+
+For each figure, assign numerals using the series convention:
+
+| Figure | Numeral Range |
+|--------|-------------|
+| FIG. 1 | 100-199 |
+| FIG. 2 | 200-299 |
+| FIG. 3 | 300-399 |
+
+For each identified component:
+- Assign the next available numeral in the series
+- Cross-reference to the claim elements it supports
+- Note if a component appears in multiple figures (use same numeral across figures)
+
+### Step 4: Generate Drawing Descriptions
+
+Write formal drawing descriptions (附图说明):
+
+**For CN jurisdiction (Chinese)**:
+```
+图1是[发明名称]的系统结构示意图；
+图2是[发明名称]的方法流程图；
+图3是[具体组件]的详细结构示意图；
+```
+
+**For US/EP jurisdiction (English)**:
+```
+FIG. 1 is a block diagram illustrating the system architecture according to one embodiment;
+FIG. 2 is a flowchart illustrating the method steps according to one embodiment;
+FIG. 3 is a detailed view of the processing module of FIG. 1;
+```
+
+### Step 5: Generate Reference Numeral Index
+
+Create a complete mapping:
+
+```markdown
+## Reference Numeral Index
+
+| Numeral | Component Name | Figure(s) | Claim Element |
+|---------|---------------|-----------|---------------|
+| 100 | System | FIG. 1 | Claim X preamble |
+| 102 | Processor | FIG. 1 | Claim X, element 1 |
+| 104 | Memory | FIG. 1 | Claim X, element 2 |
+| 106 | Communication bus | FIG. 1 | Claim X, element 3 |
+| 200 | Method | FIG. 2 | Claim 1 preamble |
+| 202 | Receiving step | FIG. 2 | Claim 1, step 1 |
+| 204 | Processing step | FIG. 2 | Claim 1, step 2 |
+```
+
+### Step 6: Cross-Reference to Claims
+
+Verify that every claim element has at least one reference numeral:
+
+| Claim Element | Figure | Numeral | Status |
+|---------------|--------|---------|--------|
+| [element] | [which fig] | [numeral] | Covered / [MISSING] |
+
+If any claim element has no corresponding figure or numeral, flag it:
+- `[MISSING FIGURE: Need a diagram showing {element description}]`
+- `[MISSING NUMERAL: Component {name} in figure {X} needs a numeral]`
+
+### Step 7: Output
+
+Write `patent/figures/figure_descriptions.md`:
+```markdown
+## Figure Descriptions
+
+### FIG. 1 — [Description]
+[Formal one-paragraph description with all reference numerals]
+
+### FIG. 2 — [Description]
+[Formal one-paragraph description with all reference numerals]
+...
+```
+
+Write `patent/figures/numeral_index.md`:
+```markdown
+## Reference Numeral Index
+
+[Complete table of all numerals, components, figures, and claim mappings]
+```
+
+## Key Rules
+
+- Every component in every figure must have a reference numeral.
+- Every reference numeral must be explained in the specification.
+- Numeral series must be consistent: 100-series for FIG. 1, 200-series for FIG. 2.
+- If the same component appears in multiple figures, use the SAME numeral.
+- Do NOT modify user-provided figures -- only describe them.
+- Flag missing figures that the claims require but the user has not provided.
+- Drawing descriptions are one sentence each, in a consistent format.

package/dist/skills/figure-designer/SKILL.md

@@ -0,0 +1,207 @@
+---
+name: figure-designer
+description: >-
+  Advises on the design of the three core figures in a technical paper:
+  the Motivated Example (Figure 1), the Solution Overview
+  (Methodology), and the Experimental Results figures. Recommends the
+  right design paradigm, layout, labelling, and tool for each figure
+  type, then runs a quality-control audit. Use when the user asks to
+  'design a figure', 'draw Figure 1', 'plot experiment results',
+  'choose the right chart type', 'which figure tool to use', or
+  'figure looks unprofessional'.
+license: CC-BY-4.0
+---
+
+# Figure Designer
+
+## Overview
+
+A top-venue paper typically carries six to eight figures, with three
+carrying almost all the storytelling weight: the Motivated Example
+(Figure 1, on page 1 or the top of page 2), the Solution Overview
+(inside the Methodology section), and the Experimental Results
+figures (inside the Experiments section). Reviewers scan these three
+in under a minute to decide whether the paper is worth reading in
+detail; weak figures sink otherwise-strong papers.
+
+This skill takes the user's intent (what they want to communicate)
+plus context (research area, method name, target venue) and returns
+the recommended paradigm, a layout sketch, labelling guidance,
+tool suggestion, and a quality-control audit against a universal
+rule set (vector format, font size, colour-blind-safe encoding,
+self-contained caption, honest axis ranges).
+
+## When to use this skill
+
+- Before drawing any figure in a paper.
+- The user asks to 'design a figure', 'draw Figure 1', 'plot
+  experiment results', 'choose the right chart type'.
+- The user has drawn a figure and wants a design audit.
+- The user is unsure which figure type or paradigm to choose.
+- Preparing camera-ready figures before submission.
+
+## When NOT to use this skill
+
+- The user only wants generic plotting help (bar chart, line chart)
+  outside a paper. Regular assistance suffices.
+- The paper is not yet structured; use `intro-drafter` or
+  `tech-paper-template` first to decide what figures the paper
+  needs.
+- The user wants a review of an already-finished paper. Use
+  `pre-submission-reviewer`.
+
+## Core procedure
+
+### Step 1: Figure-type identification
+
+Decide which of the three core types the figure is. If the user's
+request does not match any, either it is a supporting figure (use
+the experimental-results guidance as a base) or it does not belong
+in the paper.
+
+If the mode is `figure-audit` and the user has provided an image
+path, load the image with the Read tool **before** proceeding to
+Step 2. Vision-based inspection enables the universal rule audit
+in Step 6 to check font legibility, colour palette, raster-vs-
+vector tells, and chartjunk directly rather than relying on user
+description. If no image is provided, continue in text-only mode
+and mark vision-only rules (font size, raster detection, colour
+palette) as "user must verify" in the final audit report.
+
+### Step 2: Paradigm recommendation
+
+See: references/motivated-example.md, references/solution-overview.md,
+or references/experimental-results.md depending on figure type.
+
+Each figure type has two to three canonical paradigms. Pick the one
+that fits the user's storytelling need, and explain why the other
+paradigms fit less well.
+
+### Step 3: Layout sketch
+
+Produce a text description of the layout: panel positions, element
+placement, arrows, colour assignments. The goal is that the user
+could draw the first draft from the sketch alone.
+
+### Step 4: Labelling and annotation guidance
+
+- Name every visible element concretely (no "Module A", "X", "Y").
+- Annotate critical points (failure highlight, success highlight,
+  comparison emphasis).
+- Specify font sizes and colour palette. Default colour palette:
+  ColorBrewer Qualitative or Viridis for sequential.
+
+### Step 5: Tool suggestion
+
+See: references/tools.md for the tool matrix and the decision
+heuristic.
+
+Default recommendations:
+
+- Motivated Example and Solution Overview: PowerPoint (draft),
+  Figma (polish).
+- Experimental Results: Matplotlib or Seaborn in a reusable
+  `plot_utils.py` script.
+- LaTeX-integrated figures: TikZ or PGFPlots.
+
+### Step 6: Universal rule audit
+
+See: references/design-rules.md for the full universal rule set.
+
+Verify every proposed or existing figure against:
+
+- Vector format (PDF, EPS, SVG) for export.
+- Font size at least 8pt post-scaling.
+- Small canvas (not large canvas with small fonts).
+- Colour-blind-safe palette; no colour-only encoding.
+- Self-contained caption whose first sentence states the core
+  finding.
+- Honest axis ranges.
+- No 3D effects, no chartjunk.
+
+Flag every violation with severity.
+
+### Step 7: Integrity gate
+
+Run the checks in the Integrity gate section below.
+
+### Step 8: Output
+
+Emit the full design in the Output format below.
+
+## Integrity gate
+
+Bullets tagged [inspection] are checked by the LLM from its own
+output. Bullets tagged [user-verify] require the user to confirm
+because the check depends on either the drawn figure or knowledge
+the skill does not have (paper context, prior Introduction).
+
+Before returning the design:
+
+1. **[inspection]** Paradigm matches figure type (motivated example
+   is not a pipeline; overview is not a bar chart).
+2. **[inspection]** Layout sketch is concrete enough that the user
+   could draw from it.
+3. **[inspection]** Labels are real entity names, not placeholders.
+4. **[inspection]** Tool suggestion matches the figure's complexity
+   (not Matplotlib for a multi-icon motivated example, not
+   PowerPoint for a 20-method bar chart).
+5. **[inspection] when image provided, [user-verify] text-only**
+   Universal rule audit has been run; no CRITICAL violation is
+   left unaddressed. Vision-only rules (raster-vs-vector, font
+   size, colour palette) are only checkable when the user supplies
+   an image.
+6. **[user-verify]** For motivated examples, the example is the
+   same running example referenced by the Introduction (no new
+   example introduced in Figure 1). The skill does not see the
+   Introduction; the user confirms.
+7. **[inspection]** For experimental results, the chart type
+   matches the data type (time-series uses line, multi-method
+   comparison uses grouped bar, trade-off uses scatter).
+
+If any [inspection] check fails, mark the design as "needs user
+attention". For [user-verify] items, surface them to the user as
+items they must confirm before submission.
+
+## Output format
+
+### 1. Figure type
+- Type: <motivated-example or solution-overview or experimental-results>
+- Reason: <one sentence>
+
+### 2. Paradigm recommendation
+- Paradigm: <name>
+- Why this paradigm: <rationale>
+- Alternatives considered and rejected: <list>
+
+### 3. Layout sketch
+- Canvas: <size>
+- Panels: <list with positions and contents>
+- Arrows and connections: <list>
+- Colour assignment: <mapping>
+
+### 4. Labelling and annotations
+- Element names: <list>
+- Critical highlights: <list>
+- Font sizes: <target>
+- Colour palette: <name>
+
+### 5. Tool suggestion
+- Primary: <tool>
+- Alternative: <tool>
+- Reason: <rationale>
+
+### 6. Universal rule audit
+- [ ] Vector format: <pass or fail>
+- [ ] Font size: <pass or fail>
+- [ ] Colour-blind safe: <pass or fail>
+- [ ] Self-contained caption: <pass or fail>
+- [ ] Honest axis range (if applicable): <pass or fail>
+- [ ] No chartjunk: <pass or fail>
+
+### 7. Integrity gate result
+- Gate 1-7: <pass or fail>
+
+### 8. Severity summary
+- <n> CRITICAL, <m> MAJOR, <k> MINOR
+- Top three actions first: ...

package/dist/skills/figure-designer/references/design-rules.md

@@ -0,0 +1,99 @@
+# Universal figure design rules
+
+## Table of contents
+
+1. Format rules
+2. Typography rules
+3. Colour rules
+4. Caption rules
+5. Axis rules
+6. Decoration rules
+
+## 1. Format rules
+
+- **Vector format only**. Export figures as PDF, EPS, or SVG.
+  Never insert PNG or JPG into a LaTeX paper; they pixelate when
+  the reader zooms in. Raster is the "amateur" tell reviewers
+  notice first.
+- **PDF is the default**. It travels well across LaTeX distros and
+  journals.
+- **Avoid embedded bitmap inside vector**. A PDF generated from
+  matplotlib with `format='pdf'` is preferable to a PDF that
+  wraps a screenshot.
+- **Compatibility**. If the target conference requires EPS, export
+  in EPS directly; do not convert PDF to EPS via intermediate
+  raster.
+
+## 2. Typography rules
+
+- **Font size at least 8pt post-scaling**. The figure will be
+  scaled down when inserted into a two-column paper; design with
+  the final inserted size in mind.
+- **Canvas small, fonts proportional**. In Matplotlib, set the
+  figure to approximately 150 by 100 points rather than a large
+  canvas with small fonts. Big canvases with tiny fonts are a
+  common mistake.
+- **Match paper font family**. If the paper uses Times-like serif
+  text, avoid sans-serif figure labels.
+- **Bold sparingly**. Bold the series or data point the figure is
+  arguing for; do not bold every label.
+
+## 3. Colour rules
+
+- **Colour-blind safe**. Roughly 8 percent of men and 0.5 percent
+  of women have colour-vision deficiencies. Use palettes designed
+  for colour-blind readers. ColorBrewer qualitative palettes are
+  a safe default.
+- **Dual encoding**. Do not rely on colour alone to distinguish
+  series. Colour plus line style or colour plus marker shape
+  ensures the figure works in black and white.
+- **Limit palette size**. Above six distinct colours, humans lose
+  track. If the figure compares seven methods, group into two
+  tiers (Ours in a highlight colour, others in neutral grey).
+- **Contrast for the key item**. If Ours dominates, use a bold
+  contrasting colour against grey baselines. If Ours does not
+  dominate, do not artificially highlight it.
+
+## 4. Caption rules
+
+- **Self-contained**. A reader looking only at the figure and its
+  caption should understand what the figure shows and what it
+  claims.
+- **First sentence states the finding**, not just the setup.
+  Example to avoid: "Figure 5: Results on BIRD." Example to use:
+  "Figure 5: Our method consistently outperforms all baselines on
+  BIRD across model sizes, with the largest gains on complex
+  multi-table queries."
+- **Define abbreviations** used inside the figure, in the caption
+  or in a figure legend.
+- **Reasonable length**. Two to five sentences. Extremely long
+  captions indicate the figure is trying to do too much.
+
+## 5. Axis rules
+
+- **Label all axes**. Axis name and unit.
+- **Honest Y axis minimum**. Do not start at zero if differences
+  are in the top quintile; do not start just below the lowest
+  value if differences are small.
+- **Log scales labelled**. If a log scale is used, mark it.
+- **Ticks at meaningful intervals**. Do not use Matplotlib default
+  ticks if they produce cluttered or uninformative intervals.
+- **Error bars when possible**. If the experiment was run multiple
+  times, show the variance. Error bars build trust.
+
+## 6. Decoration rules
+
+- **No 3D**. Never use 3D bar charts, 3D pie charts, or 3D scatter
+  unless the data is genuinely three-dimensional.
+- **No drop shadows** on bars or points.
+- **No gradient fills** unless the gradient encodes a continuous
+  variable.
+- **Minimal grid**. Subtle grey grid lines, not dark heavy lines.
+- **No cross-hatching** for decoration; use it only if colour
+  alternatives are inadequate.
+- **No chart title when the caption serves the same role**. In
+  academic figures, the caption is the title.
+
+Every violation adds noise and reduces credibility. Reviewers may
+not articulate the reason for their discomfort, but chartjunk
+signals amateurism.