ai-research-writing-skill

AI Research Writing Skill

Core Mandate

Treat paper writing as a claim-evidence-engineering workflow, not prose generation.

Every major claim must be backed by code, results, notes, or verified citations. If evidence is missing, weaken the claim or mark the gap explicitly.

Never invent citations. Fetch BibTeX from arXiv, DOI/Crossref, Semantic Scholar, publisher pages, or official software/documentation sources. If a citation cannot be verified, use an explicit placeholder and tell the user.

When the user asks for a full paper, do not stop at an outline. Produce concrete paper artifacts, then iterate.

For full-paper work, do not stop at plans for figures or citations. Generate or fetch the concrete assets whenever tools and access allow: image files for non-numeric diagrams, deterministic plot/table files for results, references.bib entries for citations, and local paper copies or metadata records for the literature corpus.

Operating Modes

Choose the smallest mode that satisfies the user request.

If the user asks for multiple named skills that this skill subsumes, apply it as the coordinator and load the relevant reference files.

Task State and Audit

For medium or full-paper tasks, create or update durable task-state artifacts in the target paper repo before substantial drafting:

• •project_inventory.md or plan/project-overview.md for scope, target venue, inputs, constraints, and missing evidence.
• •plan/current_task.md or plan/task-packets/<task>.md for scope, files to read, files allowed to edit, required evidence, required artifacts, rejection checks, and validation commands.
• •plan/progress.md for stage, completed artifacts, checks run, remaining risks, and a compact capability-use audit.

Do not turn user process instructions into manuscript text. Requirements such as "make it natural", "fill later", "avoid AI writing", or "replace this" belong in plan/review files, not in paper sections.

Use subagents only when the user's environment explicitly allows delegation and the work can be split into disjoint files or reviews. Record each delegated task's inputs, output path, and review status in plan/progress.md or plan/agent_provenance.md.

Loading Strategy

Do not load the entire references/ tree by default.

1. Start with references/README.md when the needed reference is unclear.
2. For full-paper tasks, load references/workflow.md and references/artifacts.md.
3. Load examples only after choosing a writing pattern; prefer one narrow example file over the whole references/examples/ folder.
4. Keep generated paper artifacts in the user's target paper repo, not in this skill library.

Non-Negotiable Gates

• •Evidence gate: repository files, experiment logs, notes, and verified citations outrank memory.
• •Story gate: no full draft before thesis, gap, contributions, and claims-to-avoid are explicit.
• •Literature gate: no Related Work draft before close papers, baselines, and major lines of work are inventoried and positioned.
• •Claim gate: no unsupported strong claim in Abstract or Introduction.
• •Citation gate: no unverified BibTeX unless clearly marked as a placeholder.
• •Citation asset gate: every cited work must be added to references.bib from an authoritative source, or be recorded as a visible placeholder/blocker. Important related papers should be downloaded or saved locally when access and licensing permit.
• •Figure gate: no generated numeric figure; numbers must come from code, data, tables, or logs.
• •Figure asset gate: after writing a figure plan, actually produce the figure assets when the environment provides the needed tools. For method, teaser, framework, pipeline, architecture, and overview diagrams, invoke built-in image generation and save the generated image as the default figure used in the paper. TikZ/SVG precise schematics are optional backup/reference only (exact labels, terminology alignment, or compile fallback)—not a parallel required deliverable. If image generation is unavailable, record the blocker instead of treating the plan as complete.
• •Reviewer gate: no final draft while high-severity reviewer objections remain unaddressed.
• •Task-state gate: no medium or full-paper task without a scoped task packet, progress update, and acceptance criteria.
• •Completion gate: no "done" claim until required artifacts exist, checks have been run or blockers recorded, and remaining risks are visible.
• •Checklist gate: no submission without limitations, reproducibility, compute/data/code status, and LLM usage status when applicable.
• •Build gate: attempt compilation or record why compilation could not run.
• •Packaging gate: no commit/push without status, citation, TODO, and artifact-size checks.

Evidence Policy

• •Exact numbers must come from source tables, logs, notebooks, or plotting scripts.
• •If a result has missing seeds, uncertainty, dataset details, or fairness assumptions, mark the caveat in the relevant artifact and paper section.
• •Related work citations must come from verified metadata and support the specific sentence where they appear.
• •Close or important related papers should be saved locally when permitted and summarized before they are used for contrast or positioning.
• •Generated diagrams may illustrate a workflow, but they cannot create new scientific evidence.
• •If the user wants a stronger claim than the evidence supports, write the strongest defensible version and name the missing evidence.

Output Discipline

For full-paper work, follow references/artifacts.md. For smaller requests, produce only the relevant subset while preserving claim-evidence discipline.

For long-running tasks, maintain auditable intermediate artifacts such as paper_story.md, claim_evidence_map.md, literature/positioning.md, citation_verification.md, figures/figure_plan.md, and build_check.md.

For medium or larger tasks, finish with a short audit in plan/progress.md or the closest existing progress file:

### Capability-use audit
- Required references/scripts:
- Inputs consumed:
- Inputs not used and why:
- Artifacts produced:
- Verification run:
- Remaining risk:

Response Style

• •For long tasks, report concrete artifacts changed and checks run.
• •For writing tasks, include a compact rationale only when it helps the user revise.
• •For review tasks, lead with the most important risks and file/section references.
• •Preserve the user's scientific intent, but do not preserve unsupported wording.