Targeted Analysis of Research Papers for Decision-Making

Analyze the attached research paper based on my goal, not with a generic summary. Select the appropriate analysis mode, apply it rigorously, and return only decision-relevant information.

Inputs

Goal: [screen / implement / critique / explain / compare]

Audience: [self / engineers / product / leadership / mixed technical team]

Depth: [fast / standard / deep]

Output format: [markdown / table / memo / checklist]

Paper: [attach paper or paste text]



---

Step 1 — Select the operating mode

Choose the dominant mode from the goal:

screen → Rapid Triage

implement → Methodology & Reproducibility Review

critique → Gap Analysis

explain → Professional Synthesis

compare → Comparative Review if multiple papers are provided; otherwise say comparison is not possible


State the selected mode in one line, then proceed.


---

Step 2 — Apply the mode

Mode A — Rapid Triage

Use this to decide whether the paper deserves deeper reading.

Return:

Core Problem — the precise gap or challenge addressed

Big Idea — the central claim or solution in one sentence

Key Findings — at most 3 results that matter

Practical Utility — classify as theoretical, experimental, or implementation-relevant

Read Decision — deep read, skim only, or skip

Reason — one short justification tied to leverage, novelty, or applicability


Constraint:

Exclude anything that does not affect the read decision



---

Mode B — Methodology & Reproducibility Review

Use this when I need to understand how the work functions and whether it can be trusted or implemented.

Return:

System / Method Overview — architecture, pipeline, or core mechanism

Inputs and Outputs — what goes in, what comes out

Training / Experimental Setup — datasets, splits, baselines, metrics, ablations, evaluation design

Key Assumptions — explicit and implicit

Fairness of Comparison — whether baseline comparisons are valid

Reproducibility Status — what is present, what is missing, what blocks replication

Implementation Notes — what an engineer would need to verify before using this approach


Constraint:

Separate:

Observed in paper

Inference


Do not blur these



---

Mode C — Gap Analysis

Use this when I want weaknesses, research opportunities, or ideas for a stronger next version.

Return:

Main Limitations — highest-impact weaknesses only

Omissions — what the authors did not test, model, or discuss

Scalability Risks — what likely breaks in production or at larger scale

Load-Bearing Assumption — the assumption carrying the most weight

Most Serious Threat to Validity — internal, external, or construct validity issue

Version 2.0 — the first design change, experiment, or methodological fix to make


Constraint:

Prioritize structural critique over stylistic or minor issues



---

Mode D — Professional Synthesis

Use this when I need to explain the paper to capable people outside the exact subfield.

Return:

1. Why this matters now


2. What the paper is actually doing


3. Useful analogy


4. Bottom line for practitioners


5. Adoption risks


6. Who should care and why



Constraint:

Keep technical integrity intact

Avoid oversimplified hype language



---

Mode E — Comparative Review

Use this only when multiple papers are provided.

Return as a table with columns:

Paper

Problem addressed

Main method

Strongest result

Best use case

Weakest point

Reproducibility risk

My recommendation


Then add:

Best paper for theory

Best paper for implementation

Best paper for future research

Overall pick and reason


Constraint:

Force a ranking

Do not preserve weak options for symmetry



---

Step 3 — Evidence discipline

For every substantial claim, classify it as:

Fact — directly supported by the paper

Inference — reasoned from the paper

Speculation — plausible but unsupported


Rules:

Do not present inference as fact

Label speculation explicitly

If evidence is weak, narrow the claim



---

Step 4 — Adversarial check

Before finishing, include:

Strongest Objection — the hardest serious criticism

Would it change the conclusion? — yes or no, with one sentence



---

Step 5 — Terminal condition

Stop when the output contains:

one clear understanding of the contribution

the main risk or weakness

the decision or next action


Do not add extra sections unless they materially change the decision.


---

Output defaults

Unless I specify otherwise:

use Markdown headers

keep it dense and professional

avoid filler

optimize for action, not elegance



---

Optional instruction block to append

If the paper is in AI, ML, agents, or systems, also include:

Benchmarks used

Whether the evaluation matches real-world deployment conditions

What would need to be true for this to work in production

What evidence would most increase confidence