academic_related_work v1.0.0

name: "academic_related_work" description: "Drafts the Related Work section of an academic paper or thesis: clusters prior work into thematic paragraphs, contrasts each theme honestly with your approach, and enforces citation discipline. Triggers when the user asks to write, rewrite, fix, or review a related-work, literature-review, or state-of-the-art section." metadata: { "includeInPrompt": true }

Academic Related Work

Purpose

Turn a pile of citations into a Related Work section that reads like an argument: prior work, organized by idea, narrowed to a clear research gap, ending exactly where your contribution begins. Use this when the user has (or needs) a bibliography and a description of their own method.

Workflow

1. Collect the raw material. Ask for: the list of papers to cover (title, authors, year, citation key), one or two survey papers that frame the area, and a 3-5 sentence description of the user's own approach plus its claimed difference. If the user supplies papers as bare URLs or author names, verify each against a search before writing anything about it.

1. Build the harvest table. For every paper, extract: (a) which problem variant it solves, (b) its method family, (c) benchmark or dataset and the reported result, (d) its stated limitation. One row per paper, in your working context, not in the output. A row you cannot fill is a paper you have not read well enough; go read it.

1. Cluster into 3-5 themes. Group rows by idea: method family, problem variant, or assumption. Never group chronologically, and never let one paper per paragraph survive to the draft. Aim for 3-8 papers per theme. If a paper fits two themes, place it in the one where it matters most and mention the other only if needed.

1. Order the funnel. Paragraph 1: the broad area, with survey papers carrying the framing. Paragraphs 2-4+: one per theme, progressing from established methods to the closest competitors. Final paragraph: the gap, then your approach. Long-form work (thesis, survey) may add a comparison table; short papers may fold everything into the introduction (flag the trade-off to the user).

1. Write each theme paragraph as synthesis, not a list. The recipe per paragraph: one opening claim about what the theme established; 2-4 grouped citations supporting it; the representative result with its benchmark; the shared strength; the shared limitation that sets up your gap. Every performance claim gets a citation. Never write "Author A found X, Author B found Y."

1. Contrast honestly. For each theme state what it does well before naming its limitation. Cite the closest competitor directly and describe its claims exactly as the paper states them. If a limitation is your own inference, label it as such ("a limitation for this setting is...") instead of attributing it to the paper.

1. Write the gap and landing paragraph. Name the specific limitation your approach addresses, why prior themes cannot solve it, and how your method differs. One paragraph. This is the only place your own work appears; everything before it exists to make this paragraph obvious.

1. Citation discipline pass. Every factual claim must trace to a source. Rules: "state of the art" only when a clear metric and citation back it; group related citations ([1]-[3], [4, 5] style) instead of sprinkling them; do not cite papers you have not checked; do not pad citations to boost a record. Cut or reframe anything you could not verify.

Output Contract

• Markdown, section header ## Related Work.
• Funnel order: broad survey, thematic paragraphs, gap + approach landing.
• Each theme paragraph synthesizes multiple works with citations; no paper-by-paper summaries.
• Every performance or novelty claim carries a benchmark and a citation.
• Length: sized to the venue. A venue-specific norm (one IEEE Transactions style template) runs 1500-2200 words across 10-15 paragraphs; adapt to the target venue and page budget, never pad to a number.
• A worked fictional example lives in references/worked_example.md. It is illustrative only; all its papers are placeholders.

Operating Rules

1. Never invent numbers, dates, quotes, or findings. Unverifiable = cut it or frame it as your inference.
2. Never mischaracterize a cited paper's claims. If you have not read it, you do not summarize it.
3. The user may only want nearby work covered. Ask whether to include adjacent areas (applications, datasets) before going broad; "Computer" is not related work in an ML paper.
4. Match citation style to the venue: numbered or author-year as instructed. Keep keys consistent.
5. Flag conflicts between prior studies when you find them; do not smooth over disagreement.
6. Report the draft's theme map (which papers landed in which theme) alongside the draft so the user can correct misplacements.
7. Style: plain academic register. No em dashes. No promotional phrasing about the user's work.