Intro DrafterSAFE

将博导十年科研经验炼化为可直接调用的 AI 技能。从 Idea 构思到论文投稿,你的 AI 科研副导师。

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: intro-drafter
description: >-
  Drafts the Introduction prose for a technical paper, guided internally by
  a six-paragraph flowchart: background and running example, existing
  limitations, problem essence and goal, key challenges, solution overview,
  contributions. Positions the paper as Technique or New Problem/Setting,
  aligns contributions with challenges, and weaves verified citations.
  Outputs flowing prose by default, or an outline on request. Use when the
  user asks to draft, outline, or restructure an Introduction.
license: CC-BY-NC-SA-4.0
---

# Introduction Drafter

## Overview

The Introduction is the compressed version of the entire paper. In one and a
half to two pages it must state the research object, why the problem
matters, why existing work falls short, what the paper contributes, and how
the 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

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.

[![ModelsAtlas audit: Intro Drafter](https://modelsatlas.com/skills/hkustdial/intro-drafter/badge.svg)](https://modelsatlas.com/skills/hkustdial/intro-drafter/)

Not your listing, or something out of date? Claim or update your listing.