better-paper-digest

name	better-paper-digest
description	Use when the user wants a research paper, preprint, or technical article analyzed through a strict first-principles structure rather than a generic summary. Trigger especially when they ask for problem framing, core insight, novelty, limitations, motivation, research logic, or a deeper paper digest that separates inspiration from implementation.

Better Paper Digest

Overview

Turn a paper into a rigorous research digest that reconstructs its logic: what problem exists, why prior methods fail, what triggered the authors' idea, what they actually changed, where the novelty lies, and what future work follows.

When to Use

Use this skill when the user wants:

• a structured paper digest rather than a casual summary
• explicit separation between problem, challenge, insight, novelty, limitations, and motivation
• a rigorous breakdown of a technical paper for research discussion or literature review

Do not use this skill for:

• simple abstract summaries
• citation formatting tasks
• extracting only bibliographic metadata
• broad multi-paper literature reviews unless each paper is handled in this exact format

Required Output Contract

Always answer in Markdown. Do not use LaTeX. Write formulas in plain text. No conversational pleasantries or filler openings.

Always produce exactly these six top-level sections in this order:

1. ## Task
2. ## Challenge
3. ## Insight
4. ## Novelty
5. ## Potential Flaws & Extensions
6. ## Motivation

## Insight must contain exactly these two subsections — no others:

• ### Trigger of the insight
• ### Core insights

## Potential Flaws & Extensions must contain exactly these three subsections — no others:

• ### Context limitations
• ### Failure modes and hard edge cases
• ### Best next research question

## Novelty must use only arrow-format bullets. No prose paragraphs.

## Motivation must be a numbered chain only. No prose paragraphs.

Anti-Patterns

The following are explicitly forbidden. If you notice yourself doing any of these, rewrite before continuing.

• Do not write "This paper argues..." as an opening move — state the problem directly.
• Do not collapse insight, novelty, and motivation into a single narrative.
• Do not summarize section-by-section as a reviewer would.
• Do not treat review or perspective papers as exempt from the six-part structure.
• If the paper is a review, map each section to the paper's framing contribution, not to a fictional algorithm.
• Do not write Novelty as prose. Arrow bullets only.
• Do not write Motivation as prose. Numbered chain only.

Common Failure Mode

The default failure mode is to produce a polished research summary that sounds insightful but does not separate:

• problem vs challenge
• trigger vs core insight
• insight vs novelty
• author claim vs your interpretation

If you notice this drift, rewrite before finalizing.

Reading Strategy

Before writing, identify what kind of paper this is:

• Methods paper: reconstruct the technical mechanism and experimental logic.
• Benchmark, systems, review, or perspective paper: reinterpret the six sections at the level of the paper's actual contribution. Do not force a fake algorithmic story.
• Speculative or opinionated paper: distinguish clearly between author claim, evidence provided, and your inference.

Prefer evidence from:

1. title and abstract
2. introduction and contributions
3. method / framework / taxonomy sections
4. experiments, discussion, and limitations
5. conclusion

Evidence attribution. For each major claim, use one of these phrasings explicitly:

• "The paper explicitly argues..."
• "The paper provides examples that suggest..."
• "My interpretation is..."

Do not blend these into a single undifferentiated voice.

For review or perspective papers, additionally distinguish:

• field evidence — what the broader literature shows
• author framing — what this paper's authors claim or organize
• your inference — what you are reconstructing

Review/Perspective Adaptation Rule

For review or perspective papers, map the six sections as follows:

• Task = the framing or evaluation problem the paper solves (e.g., "given fragmented evidence, determine what blocks clinical deployment of X")
• Challenge = why existing reviews or frameworks fail to answer this
• Insight = the paper's organizing principle or conceptual reframing
• Novelty = the paper's conceptual or translational framework, taxonomy, or evaluation structure
• Motivation = logical path from field capability → deployment gap → paper's framing contribution
• Potential Flaws & Extensions = apply as-is to the paper's framework or conclusions

Do not invent an algorithm. Analyze the intellectual contribution.

Section-by-Section Instructions

Task

Explain the precise problem the paper is trying to solve as a rigorous problem statement, not a vague topic label.

Include:

• the object of study
• the input information available
• the target output, decision, or capability
• the operating constraints or deployment context
• what counts as success

For empirical papers: given X, infer/predict/construct Y under constraints Z. For review or perspective papers: given the current state of a field, determine/evaluate/organize how to achieve Y and what blocks deployment.

Challenge

Explain why this problem is hard and why older approaches struggle. Focus on fundamental bottlenecks:

• data scarcity or annotation cost
• distribution shift
• weak observability or poor generalization
• mismatch between benchmark success and real deployment needs
• computational, regulatory, economic, or workflow constraints

Do not merely list shortcomings. Explain the mechanism of failure.

Insight

This section contains exactly two subsections.

Trigger of the insight

State what specific observation, analogy, bottleneck, or empirical pattern appears to have triggered the authors' thinking. Examples:

• a repeated failure mode in prior methods
• a capability that became possible because of a new model family or dataset regime
• a mismatch between what practitioners need and what benchmarks measure

Core insights

For each core insight:

• state the insight clearly
• explain where it applies and why it helps
• connect it explicitly to the trigger

Use a numbered list when there are multiple insights.

A strong insight is a governing idea, not a component name:

• scale changes the useful representation regime
• clinical deployment fails because the real bottleneck is operational rather than predictive

Novelty

Identify the paper's true novelty. May be architectural, methodological, training-related, evaluation-related, systems-oriented, translational, or conceptual.

Use this exact format for every novelty point — no exceptions:

• [problem solved] -> [insight that inspired it] -> [specific innovation or design in detail]

Be concrete in the final segment. Describe the actual mechanism, framework, workflow, taxonomy, or coordination structure. Do not confuse novelty with mere use of a trendy model family.

Potential Flaws & Extensions

This section contains exactly three subsections.

Context limitations

What assumptions or scope boundaries make the current approach narrower than it appears? Also assess extensibility: is it feasible to apply the method to new contexts such as higher dimensions, additional conditions, or stricter constraints — and what would break?

Failure modes and hard edge cases

What data properties, deployment conditions, or adversarial cases would make this approach struggle? Examples: heavy label noise, domain shift, missing modalities, rare classes, confounding variables, scale-up bottlenecks, workflow integration barriers.

Best next research question

Among the identified weaknesses, pick one challenge strong enough to justify an independent future paper. State:

• why this challenge matters
• why the current paper does not settle it
• what kind of next-step investigation would be most valuable

Do not propose "improve robustness" as a research question. Be specific.

Motivation

Reconstruct the paper's cognitive trajectory as a numbered chain of logical steps. No prose paragraphs.

Format:

1. Previous methods relied on X.
2. That creates limitation Y.
3. So the next natural question is whether Z could bypass Y.
4. If Z works, we need mechanism A to make it usable.
5. That leads directly to the paper's proposal.

This should feel like reverse-engineering the authors' thought process.

Style Requirements

• Be concise but not shallow.
• Prefer analytical prose over decorative language.
• Separate direct evidence from your own interpretation whenever the distinction matters.

Quality Bar

Before finalizing, check:

• Did you formalize the task rigorously?
• Did you explain why prior methods fail mechanistically?
• Did you distinguish trigger from insight, and insight from novelty?
• Did you identify novelty at the right level, not just surface components?
• Did you propose a genuinely specific future research direction (not "improve robustness")?
• Did the Motivation section use a numbered chain with no prose?
• Did the Novelty section use only arrow bullets with no prose?

Minimum evidence checklist:

• Did you cite at least one concrete translational bottleneck from the paper?
• Did you name at least one concrete enabling capability from the paper?
• Did you state one future research problem narrower than "improve robustness"?
• Did you distinguish author claim from your interpretation at least once?

Example Output Skeleton

## Task
...

## Challenge
...

## Insight
### Trigger of the insight
...

### Core insights
1. ...
2. ...

## Novelty
- [problem solved] -> [insight that inspired it] -> [specific innovation design in detail]
- [problem solved] -> [insight that inspired it] -> [specific innovation design in detail]

## Potential Flaws & Extensions
### Context limitations
...

### Failure modes and hard edge cases
...

### Best next research question
...

## Motivation
1. ...
2. ...
3. ...