Paper Deep Reader

Very helpful in deep-reading one selected research paper, journal article, arXiv paper, working paper, technical report, benchmark paper, dataset paper, repl...

Security Scan

The skill's files, runtime instructions, and required resources are coherent with its stated purpose of producing rigorous single-paper reading notes; no surprising network access, credentials, or install steps are requested — but a subset of repository files (including the _common helper) were omitted from the review and should be inspected before trusting execution.

Purpose & Capability

The name/description (deep-reading one paper and producing a structured note) matches the code and instructions. The provided scripts (paper map, notation table, claim matrix, limitation ledger, scaffolding, and render) are exactly the kinds of local text-processing helpers expected for this task. There are no unrelated credentials, binaries, or external services declared.

Instruction Scope

SKILL.md limits the skill to reading a single selected paper and internal reference files in the repo (routing-rules.md, adapters, checklists, template files). The required execution protocol reads and writes markdown artifacts inside the repository and does not instruct reading unrelated system files, environment secrets, or calling external endpoints. The instructions are specific and constrained rather than open-ended.

Install Mechanism

No install spec is declared (instruction-only), which is low-risk. The included Python scripts state they use only the standard library; no brew/npm/foreign downloads or extract steps are present. This is appropriate for the stated purpose. Note: the package is not installed automatically — running the scripts would write files locally (scaffold/render) as intended.

Credentials

The skill declares no required environment variables, no primary credential, and no config paths. The runtime instructions and visible scripts only access local markdown files and perform parsing/templating; therefore the environment/credential footprint is proportionate to the purpose.

Persistence & Privilege

always:false and no evidence the skill attempts to persist as an always-on capability or modify other skills. The scripts write local markdown artifacts and update note scaffolds (expected behavior). Autonomous invocation is allowed by platform default but does not combine here with any high-privilege access.

Assessment

This skill appears coherent and appropriate for producing structured, evidence-focused reading notes. Before running or installing it, inspect the omitted helper files (notably the _common module and the 25 truncated files) to confirm they do not perform network calls, shell out to unexpected commands, or exfiltrate data. When you run the scripts, they will read and write local markdown files (scaffold, artifacts, final note) — only run them in a directory where you are happy with those file operations. If you plan to run these on private PDFs or notes, verify the helper code does not upload content externally. If you want higher assurance, run the scripts in an isolated environment (temporary VM or container) and review any runtime logs for unexpected network activity.

Use this skill to read one selected paper deeply each time and turn it into a durable, evidence-based note.

This skill is for serious paper reading, not for rewriting the abstract in cleaner prose.

First load

Before drafting, read these core references:

• {baseDir}/routing-rules.md
• {baseDir}/paper-taxonomy.md
• {baseDir}/references/reading-workflow.md
• {baseDir}/references/note-template-base.md
• {baseDir}/references/output-contract.md
• {baseDir}/references/checklists/general.md

Then route the paper and load:

• exactly one primary adapter
• one to three evidence checklist packs
• an optional secondary adapter only when a second contribution is independently load-bearing
• an optional domain overlay only if one exists in the repository and materially improves faithfulness

Adapters currently in use

• {baseDir}/references/adapters/theory-math-stats.md
• {baseDir}/references/adapters/method-algorithm.md
• {baseDir}/references/adapters/benchmark-evaluation.md
• {baseDir}/references/adapters/dataset-resource.md
• {baseDir}/references/adapters/empirical-econ.md
• {baseDir}/references/adapters/systems.md
• {baseDir}/references/adapters/survey-synthesis.md
• {baseDir}/references/adapters/replication-negative-result.md
• {baseDir}/references/adapters/physics.md
• {baseDir}/references/adapters/quant-finance.md

Evidence checklist packs currently in use

• {baseDir}/references/checklists/general.md
  Always run this first.
• {baseDir}/references/checklists/theory-math-stats.md
• {baseDir}/references/checklists/proof-rigor.md
• {baseDir}/references/checklists/experimental-eval.md
• {baseDir}/references/checklists/ablation-and-mechanism-isolation.md
• {baseDir}/references/checklists/robustness-and-ood.md
• {baseDir}/references/checklists/benchmark-fairness-and-contamination.md
• {baseDir}/references/checklists/reproducibility-and-compute.md
• {baseDir}/references/checklists/empirical.md
• {baseDir}/references/checklists/systems.md
• {baseDir}/references/checklists/physics.md
• {baseDir}/references/checklists/quant.md

Primary objective

Produce a note that lets a strong graduate student answer all of the following without reopening the paper:

1. What problem does the paper study?
2. Why does that problem matter?
3. What is the paper's main move?
4. How does the technical mechanism, argument, benchmark, dataset, or system work step by step?
5. What assumptions, approximations, identification logic, workload assumptions, or construction choices are doing the real work?
6. What evidence actually supports the main claims?
7. What is genuinely strong, weak, narrow, reusable, or fragile about the paper?

Non-goals

Do not use this skill for:

• shallow abstract rewrites
• vague praise or hype language
• multi-paper literature reviews unless the selected paper itself is a survey or synthesis
• papers you have not actually read beyond title and abstract

Operating principle

Treat paper reading as reconstruction plus judgment.

Your job is not only to say what the authors claim. Your job is to reconstruct the paper's intellectual structure, route it faithfully, trace claims to evidence, and record where a careful reader should trust, doubt, reuse, or extend the work.

Required execution protocol

Follow this sequence.

1. Build a paper map before prose

Before writing the note, identify:

• research question
• problem setting
• main move
• key technical objects
• main claim(s)
• evidence backbone
• where the paper's intellectual load actually lives
• the primary failure risk if the paper is weaker than advertised

Write a short internal map in this form:

The paper studies __ in the setting __. Its main move is __. It claims __, supported mainly by __. The key technical objects are __. The real intellectual load sits in __. The main failure risk is __.

If you cannot write this map, keep reading before drafting.

2. Route the paper before analyzing it

Use the routing rules in {baseDir}/routing-rules.md.

Create an internal route record in this form:

Primary adapter:
Secondary adapter:
Evidence packs:
Domain overlay:
Route confidence:
Why this route:

Routing principles:

• choose exactly one primary adapter
• add a secondary adapter only if a second contribution is independently central
• choose one to three evidence packs that are most likely to change the final verdict if the evidence is weak
• use a domain overlay only when the field has recurring objects, overclaims, or traps that deserve active reminders
• prefer the simplest faithful route

Do not route only by title words or surface buzzwords. Route by the paper's real intellectual load.

3. Read in passes

Do not read linearly from top to bottom unless the paper is unusually simple.

Pass A: framing

Read title, abstract, introduction, conclusion, and figure or table captions. Goal: identify what the authors want the reader to believe and what kind of contribution they think they are making.

Pass B: technical core

Read the model, method, theory, derivation, benchmark construction, dataset section, or system design sections carefully. Reconstruct the main equations, estimators, algorithms, proof ideas, task definitions, sampling logic, or tradeoffs.

Pass C: evidence

Read experiments, empirics, case studies, benchmarks, robustness checks, appendix evidence, or construction validation that bears on the main claims.

Pass D: limits and context

Read limitations, related work selectively, and appendix sections needed to judge the claims fairly.

Do not stop at the main body if a central claim is only supported in the appendix or supplement.

4. Use the scripts to reduce drift

If the scripts in {baseDir}/scripts/ are available, use them as a structured drafting aid. Before using any script, read its documentation {baseDir}/scripts/README.md and understand what it does and does not do.

Recommended order:

1. scaffold_note.py
2. build_paper_map.py
3. route the paper manually using {baseDir}/routing-rules.md
4. build_notation_table.py
5. build_claim_matrix.py
6. build_limitation_ledger.py
7. render_final_note.py

Use the scripts to create first drafts of the note scaffold and internal artifacts. Then review and correct them against the paper. The scripts are helpers, not authorities.

5. Prefer scripted artifacts when the note will be saved

When the user wants a saved markdown note, prefer this flow:

• scaffold the note from {baseDir}/references/note-template-base.md
• draft the paper map
• route the paper explicitly
• draft the notation table when notation is nontrivial
• draft the claim-evidence matrix for the main claims
• draft the limitation ledger
• render the final note and then revise it manually for accuracy and pedagogy

If the note is short and purely conversational, you may skip the scripts, but you must still follow the same intellectual protocol.

Mandatory internal outputs

Before finalizing the note, build these internal structures. They can remain implicit unless the user asks for them, but the final note must reflect them.

A. Paper map

A compact statement of problem, setting, contribution, evidence backbone, and main failure risk.

B. Route record

A compact routing decision with:

• primary adapter
• optional secondary adapter
• one to three evidence packs
• optional domain overlay
• route confidence
• short justification

C. Notation table

When notation is nontrivial, record:

• symbol
• meaning
• type / shape / domain
• units if relevant
• where it first matters

D. Claim-evidence matrix

For each major claim, record:

• the claim itself
• whether it is the authors' stated claim or your inference
• what evidence supports it
• where that evidence appears
• how strong the support is
• any caveat or missing check

E. Limitation ledger

Separate:

• limitations explicitly acknowledged by the paper
• limitations you infer as a careful reader

Core rules

1. Read before judging. Never infer the entire contribution from title and abstract alone.
2. Separate authors' claims from your evaluation. Mark the distinction clearly.
3. Preserve the mathematical or technical spine. Keep the note anchored in equations, estimators, theorem statements, algorithms, benchmark construction, data construction, identification logic, or system tradeoffs when relevant.
4. Trace claims to evidence. Strong statements require concrete support from sections, figures, tables, appendices, proofs, or benchmarks.
5. Explain mechanisms, not just outcomes. Answer why the method, argument, benchmark, dataset design, or system should work and when it should fail.
6. Prefer exactness over praise. Replace words like “powerful,” “novel,” or “impressive” with concrete statements.
7. Do not hide uncertainty. If the paper is unclear, underspecified, overstated, or weakly evidenced, say so directly.
8. Use scripts as drafts, not verdicts. Heuristic extraction must always be checked against the paper.
9. Choose the simplest faithful route. More adapters or packs do not automatically make a better note.

Adapter and checklist rule

Always keep the common structure from the base template, then expand or tighten sections using the routed adapter and chosen evidence packs.

• Use one adapter for a clean single-contribution paper.
• Use two adapters only when the paper is genuinely mixed and the second contribution is independently load-bearing.
• Do not bolt on irrelevant sections just to satisfy a template.
• Run general.md first, then the chosen evidence packs, then any adapter-specific or domain-specific checks.

Writing contract for the final note

Follow the output contract in {baseDir}/references/output-contract.md. Use the base note template as the default scaffold, then adapt it to the routed paper type and evidence profile.

Evidence rule

For every important conclusion in the note, ask:

1. Is this the authors' claim, or my inference?
2. What concrete evidence supports it?
3. How strong is that support?
4. What would make me trust it less?
5. Did I record that caveat in the note?

If you cannot answer these questions, keep reading or weaken the statement.