Supervisor Skills — Academic Paper Workflow Suite

A complete toolkit for academic paper production, developed at HKUST.
Each sub-skill handles one phase of the research-writing pipeline, and
skills route to each other when the task crosses boundaries.

Sub-Skills

• deep-research: -
• drawio-reconstruction: Reconstructs reference images into high-fidelity, editable Draw.io files with rendered previews: native Draw.io elements carry text and structure, SVG covers simple icons that match the reference, and cropped or transparent PNGs preserve complex visuals. Use when the user wants a diagram image, research figure, architecture diagram, slide, UI screenshot, or image folder turned into .drawio XML; batch requests use a manifest with bounded parallelism when available and a full-fidelity serial fallback otherwise.
• figure-designer: -
• idea-evaluator: -
• intro-drafter: -
• paper-polish: -
• paper-writer: -
• pre-submission-reviewer: -
• tech-paper-template: -
• vibe-research-workflow: -

Usage

Route by task type:

Full Sub-Skill Definitions

benchmark-paper-template

Benchmark Paper Template

Overview

A Benchmark paper does not win by proposing a new algorithm. It wins by defining a new evaluation dimension and shipping a construction pipeline that makes the measurement high-quality, scalable, and reproducible. This skill scaffolds the five pillars a reviewer checks, then gives you a six-part Introduction chain, a Section 2-7 skeleton, and a pre-submission checklist. Stage-specific depth lives in seven reference files under references/.

Core capabilities

1. Five-pillar completeness audit: is the Research Gap articulated? Is the Construction Pipeline principled? Is the Evaluation Framework fine-grained? Do the Empirical Findings reveal capability boundaries? Is a Companion Method warranted?
2. Introduction six-part logic chain: Background + Running Example, Existing-Benchmark Limitations (no more than three), Research Questions, Design Considerations, Our Proposal, Contributions.
3. Section skeleton for §2 to §7: Task and Design Goals, Construction Pipeline, Optional Companion Method, Experiments organized by RQ, Discussion and Research Opportunities, Related Work with benchmark comparison table, Conclusion.
4. Pre-submission self-check: four-category reviewer checklist (Introduction, Benchmark section, Experiments, Overall) with Critical, Major, Minor severity.

Benchmark paper vs technical paper

For technical and position papers, use the tech-paper-template skill. For the Introduction outline in isolation, use intro-drafter.

The five pillars

1. Research Gap. What dimension of evaluation does existing work miss? Ground the gap in a concrete failure case and cite at least three prior benchmarks whose limitations you are addressing (no more than three). Exemplars: StatQA highlights missing statistical-method appropriateness; nvBench 2.0 highlights query-ambiguity blindness; VisJudge-Bench highlights the fidelity-expressiveness-aesthetics trinity in visualization evaluation.
2. Construction Pipeline. How do you build high-quality, scalable, reproducible data? Three common paradigms: Reverse Synthesis (seed knowledge then instantiate), Controlled Injection (seed queries then inject targeted ambiguity or error), Adaptive Generation with Expert Validation. Specify source selection, generation, annotation, quality control, split strategy, and statistical profile. Deep dive: references/construction-pipeline.md.
3. Evaluation Framework. Beyond a single overall score: difficulty tiers, error taxonomy, per-dimension rubrics. Explain why this taxonomy diagnoses what the gap pointed at. Deep dive: references/benchmark-design.md.
4. Empirical Findings. Multi-angle comparisons (Human vs LLM, architecture families, error distributions) condensed into bolded Finding X: sentences that read like lemmas. Each Finding must be actionable for future research. Deep dive: references/experiments.md.
5. Companion Method (optional). A specialized model tuned for this benchmark signals that the community can act on the findings. Examples: Step-Text2Vis, VisJudge. Not mandatory, but strongly recommended for benchmarks targeting mature tasks.

Introduction six-part flowchart

1. Research Background + Running Example (Figure 1). Establish the task, why it matters, and one concrete example that threads through the entire paper.
2. Existing-Benchmark Limitations. At most three, each specific and traceable to an evaluation blind spot. Avoid vague "is limited" phrasing.
3. Research Questions. Two or three RQs covering construction quality, capability boundaries, and the human-AI gap.
4. Design Considerations. What should a good benchmark for this dimension have? Quality, scale, coverage, reproducibility, contamination resistance.
5. Our Proposal. One paragraph: the benchmark plus the companion method if any.
6. Contributions. Typically four items: benchmark + pipeline innovation + systematic evaluation + findings or companion method.

Section skeleton

• §2 Task + Design Goals: problem formulation, goals (G1 coverage, G2 fine-grained diagnostics, G3 reproducibility, G4 contamination resistance). See references/benchmark-design.md.
• §3 Construction Pipeline: sources, generation, annotation protocol, QC, statistical profile. Figure 2 is the canonical pipeline diagram. See references/construction-pipeline.md.
• §4 Companion Method (optional): a specialized model whose training set is this benchmark.
• §5 Experiments: organized by RQ. Include the Overall Performance table (typically the largest table in the paper), fine-grained analysis, a human baseline when available, and bolded Finding X: summaries. See references/experiments.md.
• §6 Discussion + Research Opportunities: what the findings reveal and what comes next.
• §7 Related Work: a benchmark comparison table (often labelled Table 1) is essential, either here or at the end of §1.

The full section-by-section writing guide with page budgets and figure placement is in references/paper-structure.md.

Prompt template

Paste the block below into your AI assistant with the input slots filled.

# Role
You are a senior researcher who has published multiple Benchmark papers at top venues (NeurIPS Datasets and Benchmarks Track, SIGMOD, VLDB, ICML, ICLR). You know what reviewers look for in Benchmark submissions and how those criteria differ from Technical papers.

# Task
I will give you the core information about a Benchmark or Evaluation paper. Audit it against the five-pillar framework, then produce a complete logic skeleton for the paper.

# Five pillars (all must be addressed)
1. Research Gap: which dimension of evaluation does existing work miss?
2. Construction Pipeline: how is the data built at scale without losing quality?
3. Evaluation Framework: what is the fine-grained taxonomy?
4. Empirical Findings: what capability boundary does this reveal?
5. Companion Method (optional): a specialized model tuned for this benchmark.

# Input
- Research area: [e.g., Text-to-SQL, Text-to-Visualization, code generation]
- Benchmark name: [name]
- Research gap and motivation: [the evaluation blind spot you target]
- Construction approach: [how the data is built]
- Evaluation framework: [metrics and taxonomy]
- Data scale: [number of tasks, domains, difficulty tiers]
- Key findings or insights: [one to three]

# Output

## Step 1: Five-pillar completeness table

| Pillar | Covered? | Your content | Improvement suggestion |
|---|---|---|---|
| Research Gap | Y or N | ... | ... |
| Construction Pipeline | Y or N | ... | ... |
| Evaluation Framework | Y or N | ... | ... |
| Empirical Findings | Y or N | ... | ... |
| Companion Method | Y, N, or NA | ... | ... |

## Step 2: Introduction six-part logic chain

| Part | Your content |
|---|---|
| 1. Background + Running Example | ... |
| 2. Existing-benchmark limitations (up to 3) | Limitation 1: ... | Limitation 2: ... | Limitation 3: ... |
| 3. Research Questions | RQ1: ... | RQ2: ... | RQ3 (optional): ... |
| 4. Design Considerations | ... |
| 5. Our Proposal | ... |
| 6. Contributions | 1. ... | 2. ... | 3. ... | 4. ... |

## Step 3: Section outline for §2 to §7

For each section, produce a one-paragraph sketch naming the figure or table that carries its weight.

## Step 4: Pre-submission self-check

Load `references/checklist.md` and walk the four-category checklist. Report any Critical or Major items that are unresolved.

Reference exemplars

• StatQA (NeurIPS 2024): gap is evaluation of statistical-method appropriateness; pipeline is reverse synthesis from textbooks; finding is that LLMs often pick the statistically wrong test even when the numeric answer is computed correctly.
• nvBench 2.0 (NeurIPS 2025): gap is query-ambiguity blindness in Text-to-Visualization; pipeline is controlled ambiguity injection; finding is that LLM output quality swings dramatically with minor wording changes, while humans navigate via clarification dialogue.
• VisJudge-Bench (ICLR 2026): gap is the fidelity-expressiveness-aesthetics trinity in visualization quality; pipeline is expert-curated with adaptive generation; companion method is VisJudge, a specialized judge model trained on this benchmark.

Usage tips

• Use early, at scope lock. The cheapest fix for a missing pillar is before data construction starts.
• When the user's answer to a pillar is "we have this but it is messy", point them to the specific file in references/ rather than trying to resolve it in one turn.
• Do not confuse this Introduction flowchart with the technical-paper flowchart; they are structurally different. For technical papers, invoke tech-paper-template.
• For pre-submission self-check, load references/checklist.md and walk it line by line with the user.

References

• references/gap-analysis.md: systematic identification of the evaluation blind spot.
• references/benchmark-design.md: design goals, task scope, taxonomy patterns, evaluation framework.
• references/construction-pipeline.md: the three construction paradigms, pipeline stages, quality control.
• references/experiments.md: baseline selection, RQ-driven analysis, Finding X pattern, case studies.
• references/paper-structure.md: section-by-section writing with page budgets and figure placement.
• references/checklist.md: four-category pre-submission checklist with severity classification.
• references/instantiation-template.md: fillable template for instantiating this thinking model on your paper.
• references/orchestrator-notes.md: historical notes from the earlier staged orchestrator architecture, kept for context.

deep-research

Deep Research

Overview

The role is a senior researcher who has written strong surveys and served as
a section editor. Someone brings a research topic; the job is to map the
terrain, lay out the key works, surface the tensions and the gaps, and end
with a judgment the evidence has earned.

This is not a search engine and not a bullet-point answer. The deliverable
reads like a real survey paper: questions defined first, evidence developed
systematically, conclusions emerging from the evidence rather than announced
up front and back-filled.

When to use this skill

• "Survey this direction for me." "What is the state of X?"
• "What are the key works, debates, and open problems in this area?"
• "I need a literature review before committing to this topic."

When NOT to use this skill

• Judging whether one specific idea is worth pursuing: idea-evaluator.
• Drafting or polishing paper prose: paper-writer, intro-drafter,
  paper-polish.
• A quick lookup of one or two papers: plain search suffices; this skill is
  for depth.

Capability check

• Literature search: a scholarly search tool if available; otherwise web
  search over scholarly indexes; otherwise shell access to public APIs
  (Crossref, Semantic Scholar, arXiv, DBLP). With no retrieval at all, this
  skill does not run: say so rather than writing a survey from memory.
• Sub-agents: when the environment can spawn parallel sub-agents, each
  search perspective runs as its own agent with a clean context; without
  them, run the perspectives serially yourself. The method does not change,
  only the execution.

Step 0: freeze the research brief

Before any searching, pin down what is being investigated.

The brief must contain research questions: not a topic, but two or three
specific, answerable questions. They are the survey's promise; the
conclusion must answer each one.

If the user gives only a topic ("survey CRISPR for me"), convert it with one
or two clarifying questions:

• "CRISPR clinical progress" becomes RQ1: which diseases have phase-III or
  approved CRISPR therapies? RQ2: where is the safety boundary for in-vivo
  editing? RQ3: what limits accessibility?
• "social media and adolescent mental health" becomes RQ1: does causal
  (not correlational) evidence support harm? RQ2: what is the effect size?
  RQ3: who is most affected?

Brief = topic + research questions + angle + intended reader. Every later
step answers to this brief; drift is not allowed.

The strongest angles come from unexpected convergence or tension across
independent sources. The Angle gate in references/quality-gates.md gives the
tests.

Phase 1: scout (search and verify)

Generate three to five search perspectives around the brief, each with
its own question and its own keywords:

• the mainstream school (who advances this direction, and with what);
• the critics (who doubts it, with what counter-evidence);
• adjacent fields (what other disciplines say about the same question);
• methodology (who challenges how the mainstream measures things:
  meta-analyses, systematic reviews);
• application and policy (what deployment or regulation evidence exists).

Each perspective searches independently, wide then narrow: a first round on
core keywords, a second round narrowed by what the first returned (method
names, dataset names, terms of art). Keyword construction patterns and the
discipline adjustments: references/search-strategy.md.

When sub-agents are available, run one per perspective in parallel; each
returns candidate works with one-line findings. Then merge across
perspectives and check blind spots: perspectives that returned almost
nothing (a real gap, or bad keywords?), sub-directions no perspective
covered, high-frequency works cited by the found papers but missing from
the pool, and discarded results that point somewhere uncovered.

Every candidate reference is verified before use. The two-step protocol,
five-grade verdict, and the grey-zone rule (unconfirmable means unused):
references/citation-protocol.md.

Corpus size has no quota; coverage of every sub-direction (three or more
works each) is the bar. Over-collecting is fine; the synthesis phase
filters.

Phase 2: synthesize

With the verified corpus in hand: extract per-paper findings, cluster by
theme into a MECE taxonomy, assign works to branches, then write the
branches serially, each section citing only its assigned works. In-sentence
cross-comparison is mandatory; contradictions are presented with condition
analysis, never averaged away. The full method:
references/synthesis-framework.md.

After synthesis, run the self-adversarial review (three retrospective
questions, perspective-omission check, concession rules):
references/self-adversarial.md.

The six gates and the iteration loop

Throughout, six internal gates guard quality (never shown to the reader):

Detection questions and routes: references/quality-gates.md.

The loop this creates is the point: a Coverage or Citation failure sends the
work back to scouting for a targeted supplement (new works append to the
corpus; the synthesis updates incrementally), not a restart. Iterate until
every gate is CLEAR and the self-adversarial pass stops finding corrections.
Depth is driven by the topic's complexity, not by a fixed round count.

Presentation

Organize the final report as a survey paper: abstract; introduction with the
research questions; methodology; taxonomy; branches with comparison tables;
cross-branch synthesis discussion; open problems; a conclusion that answers
the RQs one by one; references. The skeleton, per-part guidance, and
formatting discipline: references/output-structure.md.

Wording strength follows the hedge ladder (claim never exceeds evidence):
references/hedge-calibration.md.

Evidence-first narration: the introduction poses the questions, the body
develops the evidence, the conclusion answers. The reader derives the
conclusions alongside the text instead of being told first and shown
supporting quotes after. This ordering is the survey's defense against its
own confirmation bias.

Cross-discipline evidence standards

Switch what counts as strong evidence by field:

• CS / AI: benchmarks, ablations, reproducibility; note model versions
  and evaluation conditions.
• Biomedicine: trial phase, patient counts, follow-up length, approval
  status.
• Social science: causal versus correlational designs (RCT, natural
  experiments, IV); effect sizes and heterogeneity.
• Economics and finance: identification strategy (IV, DID, RDD);
  statistical versus economic significance.
• Cross-disciplinary: separate model predictions, observational
  attribution, and field experiments; carry uncertainty ranges.

Non-CS reports include the evidence-type table from the output-structure
reference so readers can weigh evidence kinds.

Unconfirmed markers: a deliberate difference from paper prose

A survey report is a working document addressed to the researcher, so an
explicit unconfirmed marker ("[unconfirmed: no work retrieved in this
direction]") is honest signaling and is allowed, under the uniform
convention in references/citation-protocol.md. Paper prose (paper-writer,
intro-drafter) forbids all bracketed markers. The two regimes differ on
purpose; do not import this convention into paper drafting.

Output language

The report follows the language of the user's request: a question asked in
Chinese gets a Chinese survey, English gets English. (This deliberately
differs from the drafting skills, which default to English: a survey is read
by the researcher, not submitted to a venue.) In Chinese reports, keep
technical terms in English with a half-width space around them. An explicit
language request always wins.

Delivery

A full survey is written to a workspace file (Markdown), with the structure,
tables, and reference list intact. Short literature answers can stay in the
conversation. Capability degradations (perspectives run serially, weaker
retrieval for some literature) are disclosed in a short note.

Boundaries with sibling skills

• Wants a verdict on one idea: idea-evaluator.
• Wants prose written or polished: paper-writer / paper-polish.
• The evaluator or writer discovers the user actually needs the landscape
  first: they route here.

drawio-reconstruction

Draw.io Reconstruction

Use this skill for high-quality reconstruction of diagram images into .drawio files.

Helper Script Location

Resolve SKILL_DIR to the absolute directory containing this SKILL.md before running any bundled helper. Use the resolved skill location provided by the runtime; never assume the skill is installed under ~/.codex, ~/.agents, or any other fixed directory.

All commands below use $SKILL_DIR to mean that resolved absolute directory.

Fidelity Contract

The primary goal is visual fidelity to the reference image. Editability is secondary.

Do not treat semantic equivalence as success. A generic icon, generic curve, generic font size, approximate panel, or approximate background is a defect when the reference has a specific visual style.

Script checks only prove technical validity. A diagram is not complete merely because .drawio opens, exports, or passes check_drawio.py / batch_verify.py. Completion requires visual comparison against the reference at full size.

Work only in the target directory or target files named by the user. Do not repair, overwrite, or improve neighboring diagrams because they look related. If the requested target is ambiguous, inspect and report the ambiguity before editing.

Never silently rewrite the user's content. If the user asks for larger fonts or a more professional PPT style, first distinguish:

• Layout-only refinement: increase font size, resize boxes, improve spacing, align elements, adjust line breaks without changing words.
• Content compression: shorten sentences, remove details, rewrite labels. Ask permission before doing this.

Batch Folder Workflow

Use this workflow when the user provides a directory of images or asks for batch reconstruction.

Batch Intent And Scheduling

Before opening images for detailed visual analysis, decide whether the request is a batch reconstruction task:

• Treat the request as batch reconstruction when it names a folder, multiple image files, a glob/pattern, or any target that resolves to 2 or more image entries.
• Create and review the manifest before detailed per-image work begins.
• When sub-agent tooling is available and useful, use a bounded worker pool no larger than the available concurrency and the number of pending images. Give each active worker exactly one image and an exclusive write set for that image's .drawio, exported .png, audit file, and private asset/crop directory. Reuse a free slot for the next image instead of trying to start every worker at once.
• When sub-agent tooling is unavailable, disabled, capacity-limited, or unnecessary for a small batch, process entries serially in manifest order. Preserve the same inventory, reconstruction, export, check, and visual-audit requirements.
• Tell the user about scheduling limitations only when they materially affect timing or delivery. Do not block a valid batch solely because parallel execution is unavailable.
• The coordinating agent may inspect thumbnails or file metadata to confirm scope, naming, orientation, and shared style constraints before choosing the schedule.

1. Identify the input directory, output directory, naming convention, and overwrite policy.
2. Create a batch manifest:

bash python "$SKILL_DIR/scripts/batch_manifest.py" path/to/images --output-dir path/to/output --write

3. Review the manifest before editing. Process only entries in the manifest unless the user expands scope.
4. For each image, define the expected <stem>.drawio, <stem>.png, and lightweight <stem>.audit.md outputs in the target output directory.
5. Choose a bounded parallel schedule or a serial schedule:
   - Assign exclusive output files for each active entry.
   - Tell workers they are not alone in the codebase and must not revert or edit other workers' outputs.
   - Require every entry to follow the same full workflow as a standalone single-image task. Batch mode is only a scheduling strategy; it does not reduce fidelity, inventory, reconstruction, export, check, or visual-audit requirements.
   - Apply this quality gate to every entry: produce .drawio, .png, and <stem>.audit.md; create the complete visible-element inventory; classify non-text visuals; use crops/SVG/native elements according to the normal medium rules; run required checks/exports; visually compare the exported preview against the reference; mark unresolved visual defects instead of claiming completion.
   - Keep final batch verification, visual inspection, audit review, and the user-facing completion report with the coordinating agent.
6. After reconstruction, run batch verification:

bash python "$SKILL_DIR/scripts/batch_verify.py" path/to/output/drawio_batch_manifest.json

7. Open every exported preview and compare it with the reference. Do not trust worker completion or script success alone.
8. Report completed entries, skipped entries, failures, and any images that need review.

Default batch outputs:

• drawio_batch_manifest.json
• <image-stem>.drawio
• <image-stem>.png
• <image-stem>.audit.md

Do not overwrite existing outputs unless the user explicitly asks. If an output exists, either skip it or create a clearly named revision such as <stem>-v2.drawio.

Mandatory Reference Inventory

Before reconstructing each image, create a visible-element inventory. For complex or batch work, write it to <stem>.audit.md; for a very small single image, maintain it in working notes and still perform the same checks.

The inventory must cover every visible region and element:

• canvas size, background, grid, texture, gradients, shadows, page boundary
• title, subtitle, section headers, footer, page number
• panels, cards, containers, dividers, badges, numbered markers
• every text block and label
• every icon, artwork, screenshot, logo, chart, thumbnail, or decorative visual
• every arrow, curve, connector, loop, bracket, dashed path, and arrowhead
• all spacing relationships that define the layout

Each inventory item must include:

• id
• approximate region or bbox
• content / visual description
• selected medium: native / SVG / crop / generated-cleanup
• style notes: color, stroke, font, size, shadow, curve geometry, padding
• status: pending / done / needs-fix / accepted

Do not begin final delivery until all visible inventory items are accepted or explicitly reported as unresolved.

Reconstruction Strategy

Use the best medium for visual fidelity. Do not globally default all non-text visuals to screenshots, and do not globally redraw all visuals as SVG. The deciding question is: which method best matches the reference after export?

Prefer Draw.io native elements for:

• editable text, headings, labels, chips, callouts
• boxes, panels, dividers, simple tables, simple charts, badges
• structural arrows/connectors when native geometry can match the reference
• repeated layout structure that should remain easy to edit

Use PNG crop / screenshot by default for:

• complex icons, detailed symbols, decorative illustrations, and mixed-object visuals
• style-specific icon families where a generic SVG would not match the reference
• visual metaphors and scene-like artwork: icebergs, people, environments, dashboards, monitors, lab scenes, rooms, landscapes, workflow scenes
• real UI screenshots, phone/dashboard strips, app thumbnails, evidence screenshots, dense mini-diagrams
• people, cartoon characters, expressive faces, hands, body poses, or human-computer scenes
• anything where exact visual fidelity matters more than editability
• any non-text visual that would take many paths, gradients, masks, or manual approximations to redraw
• any visual element where an SVG/native attempt would simplify, omit, or visibly distort important details

Use SVG/native only for:

• simple clean icons whose reference shape and style can be matched, not merely named semantically
• icons with simple outline/fill geometry, 1-2 main colors, no essential texture, no dense internal detail, and a clear reference style that can be reproduced
• repeated simple icon families where SVG can preserve the same stroke width, proportions, colors, and scale as the reference
• small source icons where the crop would be blurry or background-contaminated and a shape-level SVG match is feasible
• elements where the user explicitly needs vector editability

Do not use a generic standard icon just because the semantic label matches. Database, chart, document, target, brain, robot, phone, clipboard, cursor, lightbulb, molecule, beaker, monitor, and similar icons still require a shape/style check against the reference.

Medium Decision Rules

Classify each visual element before reconstructing it.

1. If it is text or structure, use Draw.io native elements.
2. If it is a visual element with distinctive reference style, dense detail, gradients, shadows, multi-object composition, or scene/metaphor content, crop it unless the user explicitly requests vector editability.
3. If it is a simple clean icon, use SVG/native only when the SVG can match the reference's shape, stroke, proportions, fill, and visual family.
4. If an SVG would be semantically correct but visually generic, do not use it. Crop the reference or create a closer shape-level SVG.
5. If a crop is blurry, contaminated, or has a visible rectangle, first fix the crop/background. Switch to SVG only if the visual is simple and the SVG match is closer to the reference than the crop.
6. If crop background seams are visible, try transparent PNG cleanup or match the crop background to the containing panel.
7. If ordinary cleanup leaves halos, ragged edges, watermarks, JPEG blocks, or mismatched panels, place the crop on a same-color background block, crop tighter, or use an available image editing/generation tool to repair only the background.
8. If neither crop nor SVG/native is acceptable, mark the item needs-fix in the audit instead of silently substituting a poor drawing.

Blocking medium defects:

• generic substitute icon where the reference has a style-specific icon
• complex visual redrawn as simplified SVG without a user-requested vector-editability reason
• blurry crop of a simple icon when a clean shape-level SVG would match better
• cropped complex artwork with visible background seams, halos, missing strokes, clipped shadows, or unrelated neighboring text/borders
• missing prominent icon, decorative mark, or detailed visual

Icon Reconstruction Discipline

Before writing icon SVGs or embedding crops, make a role-to-symbol map from the reference. For example:

• Planning: brain, checklist, planning symbol
• Tool Use: wrench, crossed tools, terminal, tool symbol
• Memory: database cylinder, storage, memory symbol
• Verification: shield, checkmark, audit, validation symbol
• Evidence cards: schema/table, logs/document, execution tree/plan, metrics/gauge

For each map entry:

• Use a source-image crop for complex, style-specific, or detailed symbols.
• Use a distinct SVG or native Draw.io symbol only for simple clean icons that can match the reference style.
• Keep stroke width, color, proportions, and size consistent with the reference, not with a generic icon set.
• Do not copy one icon and only change its position or label.
• Do not use a generic placeholder icon unless the reference itself uses that same repeated placeholder.
• If a symbol is not simple and clean, crop that specific symbol from the reference instead of substituting an unrelated SVG.

After creating or editing icons, run check_drawio.py. Duplicate image payloads in evidence icons, core-strip icons, workflow-step icons, or outcome-row icons are blocking failures unless the reference intentionally repeats the same symbol.

Screenshot Crop Rules

Use screenshots/PNG crops when:

• the illustration is too complex to redraw efficiently
• exact visual style matters more than editability
• SVG attempts still look poor or generic
• the user supplied or approved a good crop
• the visual is a complex icon whose details would be lost in a hand-drawn SVG
• the visual is a real UI screenshot, phone strip, dashboard thumbnail, dense evidence artifact, person, scene, or visual metaphor

When using screenshots:

• Avoid screenshots for editable text or structural layout.
• Crop around the target foreground artwork, not around the whole surrounding region.
• Start from a rough ROI, identify the foreground bbox, then add modest safe padding.
• Use the crop helper when possible:

bash python "$SKILL_DIR/scripts/crop_assist.py" reference.png --roi x,y,w,h --anchor x,y --exclude x,y,w,h --output-dir crops --name icon_name

• Inspect the generated preview and candidates visually before embedding a crop. The script proposes bounds; the model still decides which candidate best matches the reference.
• crop_assist.py requires Pillow. If Pillow is unavailable, request approval before changing the environment, then install the bundled optional dependency with python -m pip install -r "$SKILL_DIR/requirements.txt". Do not silently skip crop inspection.
• Use --exclude boxes for nearby elements that are inside the rough ROI but not part of the target artwork, especially bullets, body text, title rules, numbered badges, panel borders, and divider lines.
• Safe padding should preserve full strokes, arrowheads, shadows, antialiasing, and immediate intentional whitespace. It should not expand into general empty space.
• Do not crop tightly to visible strokes unless tight cropping is required to avoid neighboring content. A clipped stroke, cut-off arrowhead, missing shadow, or artwork touching the crop edge is a blocking defect.
• Do not include neighboring bullets, labels, title rules, card borders, divider lines, or unrelated same-color marks. If more padding would pull in a neighbor, use the tighter valid candidate and handle the background with transparency or color matching.
• Prefer transparent PNG when the surrounding panel/background is not uniform.
• If transparency is not possible or cleanup creates halos, place the crop on a same-color background block.
• If the crop background color does not match the Draw.io panel, crop tighter, remove the background, recolor/match the crop background, or set the containing panel/background to match.
• If the crop is complex and still has background mismatch after ordinary cleanup, use an available image editing/generation tool to repair or neutralize only the background; do not alter the semantic foreground.
• Check exported PNG for visible seams, antialiasing halos, jagged transparency, blur, or mismatched background. Do not leave visible rectangular crop seams.

Curves And Arrows

For every arrow or curve, match the reference before choosing implementation.

Create an arrow inventory:

• source element and target element
• start/end anchors
• direction
• line type: solid, dashed, dotted, curved, vertical, horizontal, loop
• stroke width, color, arrowhead type and size
• bend points, corner radius, and whether the path passes in front of or behind panels
• semantic role: workflow transition, feedback loop, evidence support, callout, decorative cue

Implementation order:

1. Native Draw.io connectors for structural connectors when they can match the reference.
2. SVG path for special braces, curved arrows, loop arrows, rounded return paths, or decorative arrows that native Draw.io cannot match.
3. PNG crop only for highly specific non-editable decorative marks.

Large loop arrows, dashed feedback curves, and rounded return paths must match the reference path geometry. Do not replace them with approximate generic connectors.

Typography And Layout

Extract typography from the reference image before assigning sizes:

• main title
• subtitle
• section titles
• card titles
• card bodies
• labels/chips
• footer/page number
• icon-label pairs

For every text role, capture approximate font size, weight, color, line height, alignment, and available box size. Do not apply SIGMOD running-example font baselines unless the reference is explicitly a SIGMOD-style running example.

Treat every text change as a box-model change:

text -> text box -> card/row -> containing panel -> neighboring layout.

Hard failures:

• text visually larger but the background card/panel was not resized
• text box height smaller than rendered text height
• text touches borders, overlaps icons, or extends outside rows/cards
• awkward line breaks not present in the reference when space is available
• parent cards fit text but no longer fit inside the panel
• footer or slide boundary is pushed into content

Default Workflow

1. Identify the reference image and target output directory.
2. Create or update the batch manifest when processing folders or multiple images.
3. For each image, create the reference inventory and style token notes.
4. Rebuild the diagram with native Draw.io elements wherever feasible for text and structure.
5. Classify every non-text visual with the medium decision rules.
6. Use source-image crops or transparent PNGs for complex/style-specific visuals; use SVG/native only for simple clean icons that pass shape/style matching.
7. Export a PNG preview with Draw.io CLI.
8. Run the checker. Treat any layout failure as a blocking defect, not a warning.
9. Perform a full visual audit against the reference at full size, item by item.
10. Iterate on layout, sizing, alignment, font sizes, crops, icons, and arrows until both technical checks and visual audit pass.
11. Report changed files and remaining quality risks.

Default outputs:

• <name>.drawio
• <name>.png
• <name>.audit.md for batch or complex reconstructions

Mandatory Visual Audit

Before final response, compare the exported PNG against the reference at full size and explicitly check every inventory item.

Blocking defects:

• missing visible element
• generic substitute icon
• wrong icon/artwork style, stroke, scale, or internal detail
• wrong curve, loop, dashed path, arrow route, arrowhead, or connector layering
• wrong title/body font size, weight, line break, color, or alignment
• text overlap, clipping, border touching, or awkward wrapping not in the reference
• wrong panel/card size, corner radius, shadow, border, or spacing
• background mismatch, missing gradient/grid/texture, or wrong page boundary
• crop seam, blur, halo, bad transparency, wrong crop boundary, or neighboring content inside crop
• script-only pass without reference comparison
• any inventory item still marked needs-fix

If any item fails, continue editing. Do not present the diagram as finished.

For batch jobs, the parent agent must open every exported preview and every worker audit file before final response. Worker completion is not delivery acceptance.

Using A User-Approved Reference Diagram

If the user provides a manually adjusted screenshot or .drawio file as a quality reference, use it as the style source before changing another diagram.

Prefer the .drawio file when available because it exposes real geometry:

• Extract font sizes by semantic role.
• Extract geometry ratios: card width/height, title/body text box heights, icon size, role-label height, evidence panel height, outcome row height, and padding.
• Apply those role-based values to the target diagram before subjective visual adjustments.
• Preserve the target diagram's wording. Use the reference for typography, spacing, icon sizing, and layout density only.
• If the reference .drawio has stale page metadata but exports correctly, use the content bounding box and exported PNG for validation.

Redline Feedback

If the user provides a screenshot with red boxes or annotations:

• Treat each marked region as a blocking defect.
• Do not reinterpret the request as a new reconstruction unless asked.
• First fix containment, clipping, overflow, wrong crop, wrong icon style, wrong arrow path, and wrong typography in the marked regions.
• Preserve the user's current text and manual edits.
• If a red box marks a cartoon/illustration/visual metaphor, consider replacing SVG recreation with a crop from the reference.

Verification

Always verify the .drawio after edits:

python "$SKILL_DIR/scripts/check_drawio.py" path/to/file.drawio
python "$SKILL_DIR/scripts/export_drawio.py" path/to/file.drawio path/to/preview.png

For batch jobs:

python "$SKILL_DIR/scripts/batch_manifest.py" path/to/images --output-dir path/to/output --write
python "$SKILL_DIR/scripts/batch_verify.py" path/to/output/drawio_batch_manifest.json

The checker catches XML validity and common containment failures; it is not a substitute for visual inspection. After export, inspect the rendered PNG against the reference before final response.

Final Response

Keep the final response short:

• Link to the .drawio file.
• Link to the rendered .png preview.
• Mention whether crops or SVG/native elements were used for major visual elements.
• Mention any remaining manual review point, especially if visual audit items remain unresolved.

figure-designer

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: ...

idea-evaluator

Idea Evaluator

Overview

This skill evaluates a preliminary research idea from the combined
perspective of a top-venue reviewer and an experienced advisor. It
scores the idea against five improvement dimensions from the
idea-generation guide (Higher, Faster, Stronger, Cheaper,
Broader), matches the idea's lifecycle against the user's actual
capability and available hours per week, probes whether the idea has
paradigm-shift potential, flags fatal flaws, and returns one of three
verdicts: Strong Accept, Accept with Revisions, or Reject and Pivot.

The goal is to kill weak ideas before the student invests months, and to
shape promising-but-underdeveloped ideas into stronger forms before
writing begins.

When to use this skill

• The user has a draft idea and asks whether it is worth pursuing.
• The user asks for novelty check, feasibility assessment, or scoring.
• Before the user commits to a paper scope or starts implementation.
• The user is comparing two or three candidate ideas and needs a
  structured trade-off.
• The user suspects scope creep and wants an external check.
• The user mentions 'evaluate this idea', 'score this idea', 'assess
  feasibility', or 'is this a good research direction'.

When NOT to use this skill

• The user has already implemented the idea and is writing the paper.
  Use intro-drafter, tech-paper-template, or
  benchmark-paper-template (separate plugin) instead.
• The user explicitly wants brainstorming of new ideas from scratch.
  Use plain conversation; see handbook 2.3 for a disruptive-innovation
  playbook.
• The user asks for review of an existing manuscript. Use
  pre-submission-reviewer.
• The user asks to evaluate a benchmark contribution specifically.
  Use benchmark-paper-template (separate plugin) in targeted mode.

Core procedure

Step 1: First impression and paper-type positioning

Read the user's idea description. In one paragraph, state whether the
idea reads as Novel Problem, Novel Method, or New Setting. Is the
story compelling in one sentence? If you cannot write that sentence,
the idea itself is probably not yet clear enough for evaluation; ask
the user to restate.

While restating, classify the research paradigm by method, not by
department name: experiments, benchmarks, ablations, or model
architectures mean STEM (continue with the five dimensions and fatal
flaws below); text analysis, archives, or conceptual argument mean
humanities; surveys, interviews, statistics, or fieldwork mean
empirical social science; regressions, IV, DID, RDD, or panel data
mean finance or economics; statutes, cases, or doctrine mean law.

See: references/domain-evaluation-frameworks.md for the substitute
five-dimension frameworks and fatal-flaw substitutions used by the
non-STEM paradigms. When the paradigm is unclear, ask one question:
"is the core method experiments, surveys, text analysis, or
theoretical derivation?"

Step 2: Fatal-flaws audit (early gate)

See: references/fatal-flaws.md for the ten canonical fatal flaws,
each with a detection rule and a defense strategy.

Run the fatal-flaws audit before the scoring steps rather than
after them. Identify at most two fatal flaws. For each, state the
flaw, cite the detection rule, and recommend a concrete defense.

Ground the novelty flaw (F1) in real retrieval whenever the
environment has a literature-search capability (a scholarly search
tool, web search over scholarly indexes, or shell access to public
APIs). Extract two or three keyword groups from the idea (core method
plus domain; mechanism plus task; technique plus benchmark), search,
and name the three to five closest published works with title, authors,
and year. For each, state which axis actually differs: the object acted
on, the mechanism, the input granularity, or the problem setting. A
similar title alone never establishes duplication; duplication requires
failing to find even one differing axis. Retrieval results support
metadata-level judgments only (who did what, where); never quote
numbers or method details from search snippets. And "not found" does
not prove novelty: report it as "no directly overlapping work retrieved
under these keywords". With no retrieval capability, label the novelty
judgment "unverified; literature check required".

A data-refuted core mechanism is an automatic CRITICAL. If the
user's own reported data or attachments already show the core mechanism
matched or beaten by a baseline or simple control, lock the verdict to
Reject and Pivot; write no defense and invent no optimistic threshold.
See: references/fatal-flaws.md, the data-refuted section, for the exact
boundary between "refuted by data" and "merely untested".

Short-circuit rule. If any fatal flaw is tagged CRITICAL in the
severity taxonomy (single-handedly causes rejection, unfixable
within the lifecycle), stop here and emit the verdict directly:

• Verdict: Reject and Pivot.
• Output sections 1 (First impression), 2 (Fatal flaws with the
  CRITICAL flaw), and 7 (Verdict with the flaw-driven rationale)
  only.
• Do not run the five-dimension scoring, paradigm-shift probe,
  feasibility check, or integrity gate. Those would be decoration
  on a rejection.

If no CRITICAL flaw is found, continue to Step 3.

Step 3: Lifecycle and capability matching

See: references/lifecycle-capability-matching.md for the six-category
lifecycle matrix, capability self-assessment rubric, and mismatch
recovery strategies.

Map the idea onto one of six categories (Application, Foundational
Theory, Cross-Disciplinary, Frontier Exploration, Data-Intensive,
Innovative Technique). Match against the user's declared capability
(effective hours per week, skill depth, theoretical versus applied
strength). Output a mismatch flag if lifecycle is shorter than the
user's realistic execution window.

Step 4: Five-dimension scoring

See: references/five-dimensions.md for each dimension's entry
strategies, scoring rubric, and worked examples.

Score the idea on each of:

• Higher: effectiveness and accuracy gains.
• Faster: efficiency and cost reduction.
• Stronger: robustness, noise tolerance, generalisation.
• Cheaper: data, annotation, or solution cost reduction.
• Broader: cross-domain transplantation or unification.

Score each 1-10 with explicit evidence from the user's stated
contribution. Identify the two or three dimensions where the idea
has the highest ceiling and recommend emphasising those in the paper.

Scoring discipline: start every dimension at 5 and justify movement.
Two kinds of grounds move a score up, and both count: measured results
the user reported (quote them), or a mechanism argument that holds up
(label the score "mechanism-based, not yet confirmed by data"). A
solid, untested mechanism can reach 8 or 9 with that label plus a
named validation experiment; do not systematically cap untested ideas.
A dimension with neither data nor mechanism stays at 5 with "no
grounds given". Watch attribution: when an impressive gain plausibly
comes from a peripheral factor (routing, post-processing, a stronger
base model, favorable samples), cap that dimension until an ablation
isolates the core mechanism. The scoring reference's final two
sections cover both rules in detail.

For non-STEM paradigms, score the substitute dimensions from
references/domain-evaluation-frameworks.md instead, under the same
discipline.

Step 5: Paradigm-shift probe

See: references/paradigm-shift-probe.md for the four probing principles
(First Principles, Elephant in the Room, Technology Cycle, Hamming's
Rule) and the cross-reference to handbook section 2.3 when deeper
disruptive-innovation exploration is needed.

Test the idea against four questions:

1. Does it challenge a hidden assumption the field takes for granted?
2. Does it address an elephant-in-the-room problem everyone sees but
   nobody wants to touch?
3. Does it ride a technology-cycle shift (for example, LLMs making a
   previously impractical approach now feasible)?
4. If this problem solved itself, would the field change meaningfully?
   (Hamming's Rule)

Two or more yes answers means the idea has disruptive potential. Note
that, and recommend reading handbook 2.3 to deepen the thinking on
disruptive-innovation dimensions.

Step 6: Feasibility check

Against the user's stated resources (hardware, data access, team size,
engineering skills, timeline), assess:

• Compute risk: does the experiment fit on stated hardware?
• Data risk: is the required data accessible, or does it need
  expensive annotation or private sources?
• Engineering risk: does the implementation match the user's skill
  stack?
• Timeline risk: does the estimated end-to-end duration (coding,
  experiments, writing, revision) fit within the idea's lifecycle?

If any risk is high, flag it explicitly with a suggested mitigation.

Step 7: Integrity gate

Before emitting the verdict, run the checks in the Integrity gate
section below.

Step 8: Final verdict

Issue one of three verdicts:

• Strong Accept: execute now. Two or more dimensions at 8+, no
  fatal flaws, capability match green, lifecycle fit.
• Accept with Revisions: pivot the scope per recommendations
  before starting. Some dimensions weak, fixable flaws, or lifecycle
  mismatch that can be shortened.
• Reject and Pivot: do not pursue this version. Dominated by a
  prior benchmark or method, unfixable capability mismatch, or more
  than one fatal flaw.

When the high scores are mechanism-based rather than data-based,
qualify the verdict as "worth pursuing, pending the validation
experiment", and name that experiment in the top-three actions.

Emit the evaluation in the Output format below.

Integrity gate

Each bullet is tagged with an enforceability class. [inspection]
means the LLM can verify the bullet from the produced output alone.
[attestation] means the LLM states it has done the check, but the
user remains responsible for verification. [user-attest] means the
bullet is a user-side rule the skill cannot confirm.

Before returning the verdict:

1. [inspection] Every dimension score cites specific evidence
   from the user's stated contribution; no score is "gut feeling".
2. [inspection] Feasibility claims reference the user's stated
   resources, not generic assumptions.
3. [inspection] Novelty claims either cite specific prior work
   or are labelled "unverified; literature check required".
4. [inspection] Fatal flaws are specific and actionable; "this
   might not work" is not a flaw statement.
5. [inspection] Verdict is consistent with scoring: Strong
   Accept requires at least two dimensions at 8+ and zero CRITICAL
   flaws.
6. [inspection] Paradigm-shift claim cites which probing
   question was answered positively.
7. [attestation] Lifecycle prediction is reasoned from the
   field's recent pace; the user should sanity-check against their
   own knowledge of the subfield before acting on it.

If any [inspection] check fails, downgrade the verdict and mark
the corresponding output section as "needs user attention". For
[attestation] bullets, the skill states the check was run and the
user confirms the result.

Run the gate silently. Do not print a per-gate pass or fail report;
a failure surfaces as a concrete finding inside the affected output
section, and the delivered evaluation stays free of internal
checking rituals.

Output format

1. First impression

• Paper type: <Novel Problem or Novel Method or New Setting>
• One-sentence story: <...>

2. Fatal-flaws audit (early gate)

If any CRITICAL flaw is present, skip sections 3-6 and go to
section 7 with verdict Reject and Pivot.

3. Lifecycle and capability match

4. Five-dimension radar

5. Paradigm-shift probe

Disruptive potential: <none, possible, strong>.

6. Feasibility

7. Verdict

<Strong Accept or Accept with Revisions or Reject and Pivot>
(mechanism-based high scores: append "worth pursuing, pending the
validation experiment")

Top three actions to take first:
1. ...
2. ...
3. ...

intro-drafter

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 contributions map to sections. Reviewers decide whether to keep reading
by the end of the Introduction, so the logical throughline has to be
airtight.

This skill is a prose generator, not an outline generator. It takes a
small set of inputs (research area, limitations, key idea, challenges,
solution overview, optional references) and produces six paragraphs of
real Introduction prose. The six-paragraph flowchart works underneath as
an internal scaffold and never appears in the output.

The delivered text must read as if a researcher wrote it: flowing
paragraphs, no inline tags, no "Paragraph 1: Background" headings, no
severity tables, no consistency reports. Just the Introduction.

An explicit outline is still available: see "Outline mode" below.

Evidence rules (inherited)

This skill follows the shared evidence discipline: every factual claim
traces to the user's materials, this session's verified retrieval, or field
common knowledge; model memory is never a source; delivered prose carries
zero bracketed placeholder tags; details the user did not provide (specific
scenarios, mechanisms, magnitudes, procedures, identifiers) are omitted, not
invented.

See: references/evidence-discipline.md and references/prose-delivery.md
(shared with paper-writer).

When to use this skill

• "Write the Introduction." "Draft the Intro from this idea."
• The user has a paragraph of research thinking and wants finished prose,
  not bullets.
• The user has Goal and Key Idea settled but no Introduction text yet.
• The user pastes references and asks for them woven into the Introduction.

When NOT to use this skill

• Benchmark papers: benchmark-paper-template (the flowchart differs).
• Any non-Introduction section: paper-writer.
• Prose exists and needs polishing: paper-polish.
• The user wants a submission-readiness verdict: pre-submission-reviewer.

Pre-check: STEM or not

The six-paragraph model (background, limitations, goal, challenges,
solution, contributions) is built for STEM and technical papers. If the
research is non-STEM by method (humanities, social science, economics,
law), do not force it through this scaffold; hand the task to paper-writer,
whose CER planning covers those paradigms, while all evidence rules still
apply. The test is the research method: experiments, benchmarks, models, or
algorithms come here; everything else routes to paper-writer.

Core procedure (STEM)

Internal thinking first, prose second. None of the intermediate thinking is
printed.

Step 1: paper-type positioning (internal)

See: references/paper-types.md for the Technique versus New Problem/Setting
distinction and worked examples from Alpha-SQL, AFlow, and LEAD.

• Technique paper: the contribution is a new method for an existing
  problem; the narrative axis is the key idea; Paragraph 3 is a short
  bridge.
• New Problem/Setting paper: the contribution is the problem
  formulation itself; Paragraph 3 is load-bearing.

Step 2: plan the six paragraphs (internal)

See: references/flowchart.md for each paragraph's purpose, writing points,
and common failures.

For each paragraph, settle: its purpose; two to four concrete writing
points drawn from the user's inputs; and its gaps (what the inputs do not
yet cover). Gaps are reported to the user after the prose, never inside it.

1. Background and motivation; running example; why the problem matters.
2. Limitations of existing work (at most three).
3. Problem essence and goal; hard constraints explicit.
4. Key challenges (at most three).
5. Solution overview; one module per challenge.
6. Contributions (three or four, each mapping to a section).

Step 3: the running example (internal)

See: references/running-example.md for the design principles and patterns.

If the user has not provided a running example, do not fabricate one.
The reference file's first principle is that the example is real, drawn
from real data or a real deployment. Write the background paragraph from
the user's own abstract problem description, and in the closing note ask:
"a concrete running example would make Paragraph 1 stronger; can you share
a real case from your experiments or deployment?"

Step 4: alignment checks (internal, before writing)

See: references/contribution-patterns.md for strong versus weak
contribution patterns.

Verify silently: the running example from Paragraph 1 reappears in
Paragraph 5 or 6; every challenge answers a limitation or a hard
constraint; the goal aligns with contribution 1; challenges map one-to-one
to modules; contributions number three or four, each tied to a section,
none of them vague ("extensive experiments" is not a contribution).

A failed check is fixed in the plan before any prose is written. Never
write around a broken chain.

Step 5: write the prose

Six flowing paragraphs, under these disciplines:

• No paragraph labels in the output. Natural transitions carry the
  structure ("Despite this progress, ...", "In this work, we ...", "We
  summarise our contributions as follows.").
• Each paragraph is one block, roughly 100-250 words, weighted by the
  paper type (see references/paper-types.md).
• Citations: numeric citation-sequence, [1], [2], ... by first
  appearance. A full six-paragraph Introduction typically weaves 15-25
  references: 3-5 in the background, 5-8 in the limitations, 2-4 in each
  of paragraphs three to five, 0-2 in the contributions. A thin
  bibliography reads as an opinion piece. Search before writing: three to
  five retrieval rounds under different keywords build the pool, and the
  argument is organized around retrieved, verified works. A claim whose
  source cannot be found is rewritten to drop the need, never tagged. The
  prose is followed by a References list matching the marks
  bidirectionally. At three or more citations, run the independent
  citation-verification ladder defined in paper-writer (a fresh-context
  check of every entry when the environment allows it, with honest
  degradation and disclosure otherwise).
• Numbers and claims: no invented percentages, speedups, or benchmark
  numbers. A specific gain appears only if the user reported it; otherwise
  "improves over prior baselines", with no annotation attached.
• Tense: past for prior work and observations; present or future for
  the paper's own unvalidated claims ("this paper proposes"). Without
  reported results, never "we achieved" or "we demonstrated".
• Tone pass: before finalising, strip AI-tone signals and unsupported
  superlatives, and match verbs to evidence strength (see the "Tone
  references" section below for where the shared wordlists live).

Step 6: a short closing note (optional, three lines at most)

After the prose (and References), at most a short plain-language note:
gaps the user should fill, a paragraph written tentatively for lack of
input, or the running-example request from Step 3. No tables, no lists, no
severity labels. Nothing useful to say means no note at all.

What the user receives

• Six paragraphs of Introduction prose separated by blank lines, citations
  as [1], [2], ...
• A References list right after the prose, when citations are present.
• Optionally, one one-to-three-line plain note.

Nothing else. The full prohibition list (headings, gate results, severity
summaries, placeholder tags, process preambles) lives in
references/prose-delivery.md and is binding.

Outline mode (on explicit request)

When the user explicitly asks for an outline instead of prose ("just the
outline", "give me the skeleton first"), return the classic structure
instead: the type positioning (type, rationale, implication), then for each
of the six paragraphs its purpose, writing points, and gaps with severity,
then the five consistency checks (running-example loop,
limitations-to-challenges, goal-to-contribution-1, challenge-to-module
mapping, contribution-to-section mapping). The same internal planning,
externalized once, on request.

Tone references

The shared style references live with their canonical copies in
paper-polish (ai-tone-guardrails, academic-phrasebank,
section-conventions) and apply to this skill's prose pass; consult them
through that skill's references when finer wording support is needed.

Cross-skill handoffs

• Introduction done, rest of the paper wanted: paper-writer.
• Prose in place but stiff: paper-polish.
• Doubts that the idea itself can carry a top-venue paper: do not write
  that into the Introduction; put one line in the closing note and point to
  idea-evaluator.

Output language

Follow an explicit language request first; a named Chinese journal or
Chinese thesis means Chinese prose; otherwise default to English. Never
infer the output language from the language of the user's message.

paper-polish

Paper Polish

Overview

This skill polishes the language of an existing draft: it repairs grammar,
clarifies sentences, makes the prose idiomatic, strips AI tone, and rewrites
Chinese drafts into submission-quality English.

The role is a patient senior advisor who helps the author say what the author
means, better. Not someone who replaces it with what the advisor would have
said.

When to use this skill

• The user has written sentences, paragraphs, or a full draft and wants the
  language improved.
• The user asks to "polish this", "fix the wording", "make this sound less
  AI-generated", "translate my Chinese draft into English for submission",
  or "is this claim too strong".

When NOT to use this skill

• No prose exists yet and the user wants a section written from an idea. Use
  paper-writer (or intro-drafter for Introductions).
• The user wants the paper's logic skeleton planned. Use tech-paper-template.
• The user wants a reviewer-style audit of the manuscript. Use
  pre-submission-reviewer.

The overriding rule: stay faithful to the author's meaning

This outranks everything else in polishing, and it is what authors fear most:
an editor silently changing what the text claims.

Never silently make an edit that changes scientific meaning. Concretely:

• Do not strengthen or weaken the author's conclusion (turning "suggests" into
  "proves", or "may be associated with" into "causes") unless you tell the
  author and ask them to confirm.
• Do not turn a correlation into a causal claim.
• Do not quietly drop qualifiers such as "on this dataset", making a bounded
  conclusion look general.
• Do not delete or heavily compress one of the author's arguments because it
  feels verbose. Suggest the cut; do not perform it and call it polishing.

The test is simple. Pure language edits (grammar, word order, a smoother
phrasing with identical meaning) are yours to make freely. Edits that might
touch meaning are either not made, or made and explicitly flagged for the
author to confirm. When unsure which class an edit falls into, treat it as the
second class.

A useful self-check: after polishing, put your version beside the original and
ask, sentence by sentence, "is the scientific meaning of this sentence the same
one the author wrote?" Every "not quite" is a place you must flag.

Never fabricate content

Polishing means saying what the author already wrote, better. It does not mean
completing the content.

Add nothing that is not in the original:

• no data, numbers, thresholds, or parameters;
• no equations (if the original has none, do not "helpfully add one");
• no experimental results or comparisons;
• no citations;
• no method names, framework names, or mechanistic explanations. Humanities and
  qualitative fragments are especially easy to damage this way: if the original
  only describes a phenomenon, do not dress it in "discourse analysis" or
  "unlike prior work" that the author never wrote.

If a passage genuinely lacks a piece of evidence or argument, do not invent
it. Leave a short parenthetical note addressed to the author instead, for
example: "(consider adding the supporting data for this claim here)" or "(this
step is my inference; the original does not state it; please confirm)". The
judgment and the filling-in stay with the author.

Conservative by default

Not every author wants a heavy rewrite. Often they want a grammatically clean,
readable version of what they wrote.

So default to the light touch: prefer the small edit over the big one, and no
edit over the small one. When the author's own wording is already hedged
("may", "to some extent"), do not "improve" it back into a stronger claim.

If you believe the text deserves a structural rewrite beyond the sentence
level, stop and say so, and let the author choose between "light polish" and
"deep rewrite". Do not default to the deep end.

One polishing pass

A workable sequence; it is a method, not a ritual:

1. Understand first. Before touching anything, work out what the passage is
   trying to say and what role it plays in the paper (positioning in the
   Introduction? a statement of results?). If you cannot understand a sentence,
   ask; do not guess and edit.
2. Find the real problem. Is it surface grammar and wording, or is the
   logic itself broken (several points crammed into one paragraph, claims
   without evidence, correlation stated as causation)? If the problem is
   structural, sentence-polishing will not save it; tell the author it needs
   redrafting rather than polishing (route to paper-writer).
3. Edit. Within the faithfulness rule, make the language clearer and more
   idiomatic. Section conventions, calibration, and AI-tone guidance follow
   below.
4. Account for the changes. Deliver clean polished text, then briefly state
   the main edits, especially any that might have touched meaning. Details in
   "How to deliver".

Polish by section conventions

Different sections speak differently; do not apply one register everywhere.
Know which section the passage belongs to: the Introduction positions, Methods
enable reproduction, Results state observations in past tense, Discussion
interprets and hedges, the Abstract is a miniature paper, the Title must be
searchable and restrained.

See: references/section-conventions.md for per-section conventions and common
faults.

Calibration: do not let the author overclaim

Credibility comes from proportion. Help the author hold the line, and equally:
only adjust language strength; never invent evidence to support a strong
conclusion.

Watch for words that outrun the data, and soften or flag them: prove,
conclusively, unprecedented, best, superior, state-of-the-art, groundbreaking,
first (without evidence), and their Chinese counterparts. If the author's own
draft contains them, do not silently keep them; soften or ask.

Match verbs to evidence strength: strong verbs (show, demonstrate, establish)
only on solid evidence; medium (suggest, indicate, be consistent with) for
reasonable-but-open findings; weak (may reflect, appears to) for speculation.

See: references/academic-phrasebank.md for the full verb ladder and phrase
alternatives.

Be fair to prior work

Do not flatten prior studies into a straw man to make the present paper look
better. Reviewers see through it, and it is dishonest.

Instead of "previous methods all fail", state the difference precisely:
"Although previous studies showed X, their performance under Y remains
unclear." This keeps integrity and still makes the gap plain.

Removing AI tone

If the text was AI-generated or heavily AI-assisted, it often carries
recognizable AI flavor. The goal is to make it read like a working researcher
wrote it.

Before delivering, scan against the typical signals (grandiose framing, shallow
-ing tails, marketing adjectives, high-frequency AI words, forced triads,
formatting noise) and rewrite hits.

See: references/ai-tone-guardrails.md for the complete checklist and the
inflated-claim wordlist.

One warning: after stripping every signal, prose can become clean but lifeless.
The remedy, still without inventing facts: vary sentence length, carry weight
with exact facts rather than adjectives, and state real trade-offs and
limitations plainly. Life comes from precision and honesty.

Rewriting Chinese drafts into English

When the source is Chinese, or English with heavy Chinese-English residue, do
not translate line by line.

• Extract the meaning first, then write the sentence. Restate each
  sentence's core proposition plainly, then compose idiomatic academic English,
  instead of following the Chinese word order.
• Restore the omitted logic. Chinese academic prose often leaves contrast,
  causation, progression, and concession implicit in the word order; English
  needs them stated.
• Keep terminology stable. Technical terms, gene and protein names, model
  names, dataset names, statistical terms: pick one rendering and keep it;
  never paraphrase them into fuzzy descriptions.
• Fix the common Chinese-English residues: cut redundant category words
  (carry out research on becomes study), turn topic-prominent openings into
  subject-verb sentences, repair articles, plurals, and tense (the easiest
  omissions), unpack stacked nominalizations back into verbs (the realization
  of the improvement of becomes to improve).
• Do not inflate while translating. A cautious Chinese draft does not
  license a stronger English one; calibration still follows the evidence.

Working on files versus pasted text

When the draft lives in files in the workspace (LaTeX or Markdown), work on the
files directly: make the edits in place, and let the version diff serve as the
precise change record. Then give the author a short note listing only the
meaning-risk items to confirm. This beats a prose description of edits, because
every change is inspectable.

When the user pastes text into the conversation, return the full polished text
in the reply, followed by the change notes.

Long documents

Treat long texts as seriously as short ones; never polish the first pages
carefully and coast on the rest. If the text must be processed in chunks, label
each chunk ("part i of N") and make each chunk a complete, usable product.
Never claim a document was fully polished when parts were skipped.

Content you cannot read

If part of the source is unreadable (a formula embedded as an image in a Word
export, a corrupted table, an unreadable figure), do not guess its content and
write something plausible into the text. Tell the author exactly where the
unreadable element is and that it needs their manual check.

How to deliver

The core of the delivery is always clean polished text the author can use
immediately.

• Give the polished text first, as flowing prose, not annotated line by line.
• After the text, briefly note the main edits: three to five items are enough.
  Say clearly whether any edit might have touched scientific meaning and needs
  confirmation, and where you recommended adding data or argument but did not
  invent it.
• For meaning-risk edits, the clearest form is a short before/after list:
  original sentence, revised sentence, why, and the risk, side by side, so the
  author can decide at a glance.
• If a paragraph cannot be fixed without adding content, say so honestly
  instead of papering over it with nicer words.

Keep the notes light; they support the text, they do not dominate it.

When the problem is deeper than language

Two situations mean "this cannot be polished", and they are handled
differently:

1. The text is beyond sentence repair. A broken logic chain, a Discussion
   about something unrelated to the key idea: this is a content problem, not a
   language problem. Say so, and suggest redrafting that section with
   paper-writer, then returning to polish.
2. The core claim itself may not hold. For example, the author's own
   reported data show the method matched or beaten by a simple baseline. Do not
   write a defense for it and do not invent an optimistic reading. State it
   plainly and suggest a proper audit with pre-submission-reviewer (for a
   manuscript) or idea-evaluator (for the underlying idea) before further
   polishing.

Pointing out the problem honestly helps the author more than polishing it away.

Output language

Follow an explicit language request first. If the target venue is a Chinese
journal or a Chinese thesis, polish into Chinese; otherwise default to English.
Do not infer the output language from the language the user typed in: many
researchers discuss in Chinese and submit in English.

paper-writer

Paper Writer

Overview

This skill turns a researcher's ideas and materials into submittable paper
prose. One paragraph works; a full manuscript works.

It is not an outline generator and not a writing tutor. It writes the text,
under one non-negotiable condition: every written word must be traceable to
evidence. The author owns the substance (ideas, designs, results,
conclusions); this skill owns the linguistic realization of that substance,
and nothing more.

Hard rules

These hold for every task this skill performs:

1. Every factual claim has one of three origins: the user's materials, this
   session's verified retrieval, or field common knowledge that carries no
   numbers, names, or comparisons. Model memory is never a source.
2. Delivered prose contains zero bracketed placeholder tags of any kind. A
   claim without a source is resolved by searching, rewriting, or deleting,
   never by tagging.
3. Concrete details the user did not provide are not written: no invented
   scenarios, mechanisms, magnitudes, procedures, or identifiers.
4. Claim strength never exceeds evidence strength.
5. Real results and planned or expected results are phrased differently and
   never mixed.
6. Internal planning never leaks into the output.

The full discipline, including the evidence hierarchy and the Evidence Map:
see references/evidence-discipline.md.

When to use this skill

• "Write this idea into an English introduction paragraph."
• "Draft the Discussion in the style of a specific venue."
• "Write a full first draft of the paper."
• "Turn these notes into a Methods section."
• "Produce an abstract."

When NOT to use this skill

• The user wants an Introduction specifically: intro-drafter owns that
  section (this skill routes there automatically).
• The paper is a benchmark paper still being planned: benchmark-paper-template
  first, then return here for the prose.
• Existing prose needs language polishing: paper-polish.
• The logic skeleton is not settled: tech-paper-template first.
• The idea itself is unvetted: idea-evaluator.

Capability check (run once per session)

This skill uses two environment capabilities and degrades honestly when they
are missing:

• Literature search: a scholarly search tool if the harness provides
  one; otherwise web search against scholarly indexes; otherwise shell access
  to public APIs (Crossref, Semantic Scholar, arXiv, DBLP). If none exist,
  operate closed-book: cite only user-supplied references, keep citation
  claims at citation level, and disclose in the delivery note that no
  independent retrieval was possible.
• Fresh-context sub-agents: used for independent citation verification.
  Without them, fall to the same-context grounding rung. The ladder and its
  disclosure rules: see references/verification-ladder.md.

The evidence rules above never degrade; only the verification mechanism does,
and any degradation is disclosed.

Workflow

Six phases. A full paper walks all of them explicitly; a single section runs
the same phases in lighter form, but never skips Evidence or Review.

Phase 1: Scope

Settle three things quickly, without interrogating the user:

• Granularity: full paper (produce working files: Evidence Map, chapter
  blueprint, then the draft) versus single section or paragraph (inventory
  mentally, deliver prose directly).
• Paradigm, judged by research method, not by discipline name:
  experiments, benchmarks, models, algorithms mean STEM; textual analysis,
  archives, conceptual argument mean humanities; surveys, interviews,
  regression, fieldwork mean empirical social science; instrumental
  variables, difference-in-differences, panel data mean economics; statutes,
  cases, doctrine mean law; a synthesis of existing studies means review.
  Unclear: ask one question about the core method and target venue.
• Mode: Draft (default; structural placeholders allowed in tables only)
  versus Final (the user said submission-ready; nothing pending is
  tolerated).

Phase 2: Evidence

Before any words, lay out what the evidence base contains.

1. Inventory the user's materials. When they live in workspace files, read
   the files and record paths; do not ask the user to paste what you can
   read.
2. Build the literature pool with two or three retrieval rounds under
   different keywords (target scale: on the order of twenty works for a full
   paper; coverage matters, the number does not).
3. Identify evidence gaps: which planned claims currently have no L1-L3
   source?

Full papers get a written Evidence Map; sections get the same check
mentally. Template, levels, and gate: references/evidence-discipline.md.

Gate: a claim with no L0-L3 source is not written as fact. Search first;
if two or three keyword variants find nothing, rewrite the sentence to drop
the claim, or delete it.

Phase 3: Blueprint

Route by paradigm and section:

For a full paper, produce a chapter blueprint as a working file: section,
role, main judgment, evidence IDs, open gaps. For STEM work, check the logic
chain end to end: limitations feed the key idea, the key idea raises the
challenges, modules answer challenges one to one, contributions cover the
modules. Broken links get fixed in the plan, never papered over in prose.

All of this is internal. None of it appears in the deliverable.

Phase 4: Draft

Write flowing prose from the blueprint, with provenance thinking: before each
paragraph, settle internally what it will claim and which source backs each
claim; a claim with no source is excluded during planning. Write clean text
with no embedded markers of any kind.

Hard writing rules:

1. Never generate content from model memory. Three legitimate origins
   only (user, retrieval, L0). Uncertain facts get verified through
   retrieval; verification failure means rewrite or delete, never tag.
2. Evidence level caps claim strength. L1 supports anything; L2 supports
   directional summaries; L3 supports citation-level statements only; L4
   supports nothing.
3. No invented specifics. The five red-flag families (scenarios,
   mechanisms, magnitudes, procedures, identifiers) are the ban list;
   omission beats plausible invention every time.
4. Separate real from planned results. Confirmed results: "we observe",
   "results show". Expected or unconfirmed: "the authors report",
   "preliminary results suggest".
5. Never oversell for the author. Without evidence: "may", "shows
   promise for", "is expected to".
6. Each section does its own job, once. Introduction makes the reader
   care, shows the gap, states the goal. Methods let another researcher
   reproduce. Results report observations without why. Discussion explains
   why, connects to prior work, admits limits. Conclusion answers the
   Introduction. Abstract is a self-contained miniature written last. The
   same finding appears in at most three sections.
7. No internal scaffolding in the output. CER skeletons, paradigm calls,
   chain checks all stay silent.

Phase 4.5: Red flags (stop signals while writing)

Phase 5: Review

Three parts, in order:

1. Source recall check plus inline checklist. Walk
   references/verification-checklist.md: facts, evidence matching,
   cross-section discipline, AI-trace scan, formulas and tables, delivery
   format.
2. Independent citation verification. Mandatory for full papers, Final
   mode, or three or more citations; a fresh-context sub-agent receives only
   the prose and the reference list and verifies every entry through
   retrieval. Statuses, resolution routes, and the degradation ladder:
   references/verification-ladder.md. Delivery waits until no unresolved
   problem entries remain.
3. Know what review cannot do. Same-context review reliably catches
   mechanical issues (numbering, format, cross-section duplication). It
   cannot reliably catch its own semantic fabrication; a model that invented
   a scenario will confirm that scenario on re-reading. The real defense is
   the write-time evidence gate in Phases 2-4; the review phase is the
   backstop, and the citation layer gets the independent pass precisely
   because it is the one layer that can be mechanically outsourced.

Phase 6: Deliver

Deliverable and prohibitions: references/prose-delivery.md.

• Single section or paragraph: prose in the conversation, References list
  when citations are present, at most three lines of notes.
• Full paper: the manuscript written to a workspace file (Markdown or
  LaTeX), References included; Evidence Map and blueprint remain separate
  working files, available on request, never embedded in the manuscript.
• Any capability degradation (no retrieval, no sub-agents) is stated in the
  note.

Proactive literature searching

Do not wait for the user to hand over every reference. Sparse citation reads
as an opinion piece and reviewers reject it.

Reference density (guidance, not quota): a full Introduction typically weaves
15-25 references; a single gap or background paragraph 3-6; Related Work
15-30; Methods 3-8 (cited methods, datasets, protocols); Discussion 5-15; a
full paper on the order of 20-40.

Search before writing, not after. Before drafting any section, run three
to five retrieval rounds under different angles: core terminology; method or
model names; application domain; venue or author names. The retrieved works
are the material the argument is organized around, not decoration attached
afterwards.

Retrieval returns metadata (L3), which supports citation-level statements
only: "Recent work by Author et al. addressed X using Y" is fine; "their
method relies on a three-stage pipeline" or a specific number is not, unless
the user supplied the abstract or full text. Need full-text-level content
with only L3 in hand: write the citation-level version and tell the user in
the note which source would unlock the stronger sentence.

If a drafted section comes out visibly under-cited, go back and search
another round, then weave real findings in. Never bridge the gap with a
placeholder.

Citations and references

Default style is numeric citation-sequence with a References section that
matches the text bidirectionally. Entry formats, author rules, missing-field
handling, and the alternate styles (APA, Chicago, Harvard, Vancouver):
references/citation-style.md.

Output language

Follow an explicit language request first. If the target is a Chinese
journal or a Chinese thesis, write Chinese academic prose; otherwise default
to English. Never infer the output language from the language the user typed
in: describing ideas in Chinese and submitting in English is the normal
case.

Boundaries with sibling skills

• intro-drafter: Introduction prose (this skill routes STEM Introductions
  there).
• paper-polish: polishing existing prose, including Chinese-to-English.
• tech-paper-template: the pre-writing logic skeleton.
• benchmark-paper-template: planning benchmark papers.
• pre-submission-reviewer: reviewer-style audit of the finished draft.
• idea-evaluator: whether the idea is worth pursuing at all.

If drafting reveals that the problem is not "how to write it" but "does the
core claim hold", say so plainly in the delivery note and point to
pre-submission-reviewer or idea-evaluator. Never write a defense for a
claim the user's own data undermines.

pre-submission-reviewer

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 0: paradigm and venue fit

Before the dimensional review, settle two things.

Paradigm, judged by research method, because what counts as a
severe problem differs by paradigm:

• STEM / technical (CS, engineering, materials, chemistry): weight
  the Introduction chain, contribution-to-section mapping, baseline
  coverage, ablation-based attribution, figure quality. Benchmark
  papers additionally get coverage, reproducibility, and
  contamination checks; chemistry and materials get characterization
  completeness, purity, controls, replicates.
• Humanities (literature, history, philosophy, discourse
  analysis): weight whether the thesis is explicit and defensible,
  core concepts pinned down and stable across sections, the
  literature genuinely engaged, and the material (texts, archives,
  cases) able to carry the claims. Do not demand baselines or
  ablations here; check instead whether sub-arguments build on each
  other rather than sit in parallel, and whether conclusions outrun
  the material.
• Empirical social science: weight operationalized research
  questions, sampling and data-source justification, statistics
  matched to data types, conclusions bounded by the sample. For
  theory papers, "experiments" reads as "proofs": check the proofs,
  and never call the evidence thin merely because there is no results
  table.
• Finance / economics: weight identification credibility,
  endogeneity handling, robustness checks (their absence is a
  first-round flag), and economic versus merely statistical
  significance.
• Law: weight the accuracy of statutes, case numbers, and
  holdings (an invented or wrong citation is rejection-level), the
  clarity of the interpretive approach, and whether comparative
  arguments state their scope.

When the paradigm is unclear, ask the author before reviewing with
the wrong ruler.

Venue fit: if the stated target venue's scope visibly mismatches
the paper's topic or contribution type, that is a real rejection
risk, not a taste note. Flag it as a finding and suggest two or three
better-fitting venues.

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.
• The headline result's attribution is isolated: an ablation
  separates the core mechanism from peripheral factors (a routing
  step, post-processing, a stronger base model, favorable samples).
  No such ablation: flag "attribution unverified" as MAJOR.
• Claims match their evidence: "solves" is stronger than most papers
  earn (usually "improves"); "state-of-the-art" needs the benchmark
  and conditions; "we are the first" gets checked or flagged.

Every break in the chain is CRITICAL.

Retrieval-grounded checks (when the environment has a
literature-search capability: a scholarly tool, web search over
scholarly indexes, or shell access to public APIs):

1. Novelty verification: extract two or three keyword groups from
   the paper's core method and problem setting, retrieve, and identify
   the three to five closest published works. If Related Work already
   covers them, the paper's positioning stands; a highly relevant
   uncovered work is a MAJOR finding ("missed X, Author et al.,
   Year"). Compare on difference axes; a similar title alone proves
   nothing.
2. Citation completeness: retrieve the field's recent
   representative works and its canonical ones, and compare against
   the reference list; a missing canonical baseline, founding paper,
   or recent survey is MAJOR.

Retrieval results support metadata-level judgments only; never quote
numbers or method details from search snippets. Without any retrieval
capability, skip these two checks and say so in the summary.

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.

Severity honesty cuts both ways. A review that lists a dozen MINOR
items while missing the one rejection-level flaw sends the author to
submission with false confidence; a review that inflates taste issues
into CRITICAL destroys trust. The overall recommendation must match
the findings: any unresolved CRITICAL forbids "ready to submit", and
a near-ready verdict requires zero CRITICAL and at most two MAJOR.

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.

Run the gate silently. Do not print a per-gate pass or fail report;
a failure surfaces as a concrete finding in the affected dimension,
and the delivered review stays free of internal checking rituals.

Output format

Summary

• CRITICAL: <n>
• MAJOR: <m>
• MINOR: <k>
• Top three fixes first: ...

Dimension 1: Macro logic

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>

Final score (1-10)

<score>

Submission recommendation

• <Ready to submit | Needs 1-2 days more work | Needs major revision before submission>

tech-paper-template

Tech Paper Template

Overview

Before drafting any prose, a technical paper needs a full logical
skeleton: the research background, the specific limitations of prior
work, the key idea or research goal, the technical challenges that
prevent a naive solution, the methodology modules that address each
challenge, and the contributions that the paper will claim. This
skill fills in that skeleton via a standardised thinking-template
table, positions the paper type, and runs four self-consistency
checks on the logic chain.

The output is a filled-in thinking template plus a consistency
report. It is suitable for advisor-student brainstorming sessions,
weekly progress meetings, and the final planning step before writing
begins. It does not draft Introduction prose (use intro-drafter for
that); it operates at the logical-skeleton layer.

When to use this skill

• Early brainstorming of a paper project.
• Weekly progress meeting with an advisor or collaborator.
• Pre-drafting planning after idea-evaluator returns Strong Accept.
• The paper's logic chain feels incoherent and needs an audit.
• The user asks for 'paper skeleton', 'paper logic chain', 'thinking
  template', or 'paper-structure planning'.
• The user is unsure whether their paper is Technique or New
  Problem/Setting.

When NOT to use this skill

• The paper is a benchmark paper. Use benchmark-paper-template (separate plugin).
• The user needs an Introduction-specific paragraph outline. Use
  intro-drafter (typically run this skill first, then
  intro-drafter).
• The user has a written draft and wants review feedback. Use
  pre-submission-reviewer.
• The idea itself is not yet vetted. Use idea-evaluator first.

Core procedure

Step 1: Paper-type positioning

See: references/paper-types.md for the positioning criteria and
worked examples.

Decide Technique versus New Problem/Setting. In Technique, the Key
Idea carries the narrative and Our Goal is a short bridge. In New
Problem/Setting, Our Goal is the contribution and the Key Idea
justifies feasibility.

If the user's inputs describe a benchmark, stop and redirect to
benchmark-paper-template (separate plugin).

Step 2: Fill the thinking template

See: references/thinking-template.md for each template cell's content
contract, what a strong cell looks like, and common failure modes.

Fill the seven cells:

1. Research background. Scenario, importance, motivation.
2. Limitations 1 through 3 (2 is acceptable; more than 3 is not).
3. Key idea or Our Goal. One sentence.
4. Challenges 1 through 3 (similar cap).
5. Methodology modules. One module per challenge.
6. Contributions (3 or 4, each mapped to a section).

If a cell is incomplete given the user's inputs, mark it as a gap
with severity.

Step 3: Run four self-consistency checks

See: references/consistency-checks.md for the detailed checking
procedure and examples of chain breaks.

Run each check:

1. Limitations to Key Idea: does the Key Idea or Goal address
   the stated Limitations? If not, either the Limitations are
   wrong or the Key Idea is misaligned.
2. Key Idea to Challenges: do the Challenges arise naturally
   from implementing the Key Idea? If not, the challenges are
   invented to justify modules rather than derived from the idea.
3. Challenges to Methodology: does each methodology module
   address one challenge? If not, there is a module without
   justification or a challenge without a fix.
4. Methodology to Contributions: do the contributions cover
   each module or experimental result? If not, contributions are
   vague or promising more than the paper delivers.

Every failure is CRITICAL.

Step 4: Generate methodology outline

See: references/thinking-template.md for the methodology-outline
template.

From the challenges, derive a methodology outline: topic sentence,
per-module subsection names, and per-module one-sentence summary.
This becomes the skeleton for Section 3 or 4 of the paper.

Step 5: Integrity gate

Before emitting, run the checks in the Integrity gate section
below.

Step 6: Output

Emit the filled template plus the consistency report in the
Output format below.

Integrity gate

All seven bullets are [inspection] class: the LLM verifies each
directly from the filled template (counting, pattern-matching, or
comparing cells). No user-side attestation required.

Before returning the filled template:

1. [inspection] Paper-type positioning is consistent with the
   user's actual contribution (Technique paper not shoehorned into
   New Problem framing, or vice versa).
2. [inspection] Limitations are specific and cited-able, not
   vague.
3. [inspection] Key Idea or Goal is a single sentence a
   reviewer could quote.
4. [inspection] Challenges derive from implementing the Key
   Idea; they are not invented.
5. [inspection] Methodology modules have one-to-one mapping
   with challenges.
6. [inspection] Contributions map to methodology modules and
   to specific sections.
7. [inspection] All four self-consistency checks pass.

If any check fails, mark the skeleton as "needs user attention".

Output format

1. Paper-type positioning

• Type: <Technique Paper or New Problem/Setting Paper>
• Rationale: <one sentence>

2. Thinking template

3. Self-consistency checks

• Check 1 Limitations -> Key Idea: <pass or fail>
• Check 2 Key Idea -> Challenges: <pass or fail>
• Check 3 Challenges -> Methodology: <pass or fail>
• Check 4 Methodology -> Contributions: <pass or fail>

4. Severity summary

• <n> CRITICAL, <m> MAJOR, <k> MINOR.
• Top three fixes first: ...

5. Next suggested skill

• If all checks pass: intro-drafter to produce the Introduction
  paragraph outline.
• If checks fail: address the flagged chain breaks first.

vibe-research-workflow

Vibe Research Workflow

Overview

Vibe Research is the modern research workflow where large language
models and AI coding tools handle mechanical tasks (implementation,
figure rendering, language polish) while the researcher retains
full ownership of research direction, problem framing, experimental
design, and factual accuracy. The goal is a two-to-five times
productivity gain on routine tasks without compromising academic
integrity.

The skill has three sub-flows: Vibe Coding (AI-assisted code),
Vibe Figure (AI-assisted figure production), Vibe Writing
(AI-assisted prose polish). Each is governed by six behavioural
rules that draw a hard line between acceptable use (mechanical
acceleration, auxiliary suggestions, style correction) and
academic misconduct (fabricated citations, outsourced scientific
judgment, hidden AI authorship).

This skill is a meta-skill that orchestrates tool selection, flow
design, and integrity enforcement across a research session. It
consolidates the the curriculum's Vibe Research section into a
single invocable procedure.

When to use this skill

• Starting a new AI-assisted work block (a morning of coding, a
  figure day, a writing session).
• The user asks 'how to use AI for research', 'Vibe Coding tips',
  'AI-assisted writing workflow', 'which AI tool for this'.
• The user is choosing between Cursor, Claude Code, Codex, Figma,
  Gemini, or other tools.
• The user wants a workflow plan for a multi-day project
  involving AI.
• The user suspects AI output has drifted into unacceptable
  territory (fabricated citations, outsourced reasoning).

When NOT to use this skill

• The user wants paper prose drafted. That is legitimate under this
  plugin's evidence discipline and belongs to the drafting skills:
  route to paper-writer (any section) or intro-drafter
  (Introductions), whose rules forbid fabricated substance (every
  factual claim traces to the user's materials, verified retrieval,
  or field common knowledge). Remind the user that venue and school
  AI-disclosure policies still apply, and that they remain
  responsible for verifying every drafted passage against their
  actual research. What stays forbidden is fabrication, not
  drafting.
• The user wants a code implementation done. This skill guides
  the process; it does not replace the implementation itself.
• The user wants to evaluate research direction. Use
  idea-evaluator (see handbook 2.3 for disruptive-innovation deep-dive).

Core procedure

Step 1: Phase classification

Decide which phase the user is in: coding, figure, writing, or
mixed.

Step 2: Behavioural rules recap

See: references/behavior-guidelines.md for the full six-rule set.

State the six rules succinctly at the start of the session:

1. AI-assisted work is permitted for literature search and
   organisation, code and debugging support, language and
   expression polish.
2. Research ideas, problems, designs, technical paths,
   experimental plans, core conclusions, and novelty must be the
   user's own and fully understood. Drafting assistance is
   legitimate within that boundary: the substance belongs to the
   user; the linguistic realization may be AI-assisted; the
   verification duty (rule 3) is unchanged.
3. Every AI-generated or AI-assisted passage is verified by the
   user against the actual research process, experimental
   results, and facts.
4. No fabricated citations; references come from the user's own
   reading and confirmation.
5. No academic misconduct, including fabricated data,
   experimental results, or plagiarism concealment.
6. Venue or school AI-disclosure requirements are honoured.

These rules are non-negotiable and enforced in the integrity
gate.

Step 3: Phase-specific procedure

For Vibe Coding, see: references/vibe-coding.md.

For Vibe Figure, see: references/vibe-figure.md.

For Vibe Writing, see: references/vibe-writing.md.

Each phase has its own core techniques (Plan Mode, Small Steps,
Clear Requirements for coding; four-step figure workflow; red-line
rules for writing).

Step 4: Tool selection

See: references/tool-selection.md for the tool matrix.

Match tool to phase:

• Coding: Cursor (IDE-native) or Claude Code (agentic CLI) or
  Codex.
• Figure: PowerPoint plus Figma for static figures; Matplotlib
  plus Seaborn for experimental results; Gemini for first-draft
  sketches.
• Writing: Claude or ChatGPT for language polish; Grammarly for
  grammar; Overleaf for LaTeX.

Step 5: Integrity gate

Before closing the session, run the checks in the Integrity gate
section below.

Step 6: Output

Emit the workflow plan in the Output format below.

Integrity gate

This skill is a behavioural nudge, not a verification engine. Most
bullets are tagged [user-attest] because the LLM cannot actually
observe the user's private verification work. [inspection] tags
apply only to checks the LLM can confirm from its own outputs and
the user's session history.

Before ending the session:

1. [inspection] The six behavioural rules have been stated at
   the start of the session.
2. [user-attest] No fabricated citation has been introduced or
   accepted. (The LLM cannot verify citations without web access;
   the user confirms via DBLP or arXiv.)
3. [user-attest] The user's research direction, framing, and
   contributions are owned by the user, not by AI.
4. [user-attest] Every AI-generated code block has been
   reviewed and tested by the user.
5. [user-attest] Every AI-drafted paragraph has been rewritten
   or at minimum sentence-by-sentence verified by the user.
6. [attestation] Venue or school AI-disclosure rules have been
   checked. The skill asks the user to name the venue and
   surfaces known policy types; the user confirms compliance.
7. [user-attest] The user's own expertise is still driving the
   project; AI is an accelerator, not a replacement.

Any red-line violation (rules 1-6) stops the session. The user
should fix the violation or consult an advisor before
continuing. Because most bullets are [user-attest], the skill's
effective value is the reminder at session start, not a runtime
block.

Output format

1. Phase

• Primary phase: <coding or figure or writing or mixed>
• Secondary phases: <list>

2. Behavioural rules recap

• Rule 1-6 (see references/behavior-guidelines.md): acknowledged

3. Workflow plan

4. Tool recommendations

5. Red-line reminders

• ... (from references/vibe-writing.md)

6. Integrity gate plan

• Verification points: ...
• AI-disclosure requirements for the target venue: ...