Research Literature Interpretation

Condense a single paper into an explanatory chain that readers can retell, question, and apply: why old methods are limited, what the authors changed, why the mechanism might work, the strength of evidence support, and what the costs and failure conditions are.

Active prioritization is more important than length. Page numbers, sections, and charts only serve for review, not to dictate the narrative.

Scope and File Boundaries

Only process a single paper; leave discovery, screening, and deduplication to
```
research-literature-radar
```
, and multi-paper synthesis to review skills.
Confirm the title, authors, year, venue, version, DOI/arXiv ID, primary URL, access date, and readable scope. Record version conflicts side by side without making arbitrary rulings.
Prioritize reading the abstract, introduction, conclusion, methods, key figures/captions, ablation studies, failure cases, appendices, and code descriptions, then delve deeper into parts that affect the conclusion. When only the abstract or charts are available, deliver an evidence map and narrow down the conclusions.
Only use legally accessible primary materials and reliable follow-up sources; do not bypass access restrictions or execute unknown code. Distinguish between static reading, actual execution, and results reported by the authors.
By default, write to
```
docs/papers/<friendly-id>/<friendly-id>.md
```
. Existing notes are revised or appended by default, without overwriting user content; do not modify
```
raw/
```
or
```
.bensz-api/research-literature-radar/catalog.jsonl
```
. Intermediate materials are placed in the current round's
```
.bensz-api/
```
.

Process

Input

Provide necessary input according to user requests and configuration files; clearly list missing information and stop steps that depend on that input.

Execution Steps

Only design flaws of this Skill (process misjudgments, incomplete input contracts, or incorrect environmental assumptions) are considered reportable bugs; user data errors, third-party service fluctuations, users actively modifying source code, and occasional model fluctuations are not included in this scope.
When a design flaw is found, first record it desensitized in
```
~/.bensz-skills/bugs/
```
and continue the current task; only when the user explicitly requests public reporting, use the local
```
gh api
```
to upload directly without cloning the repository.
Do not collect usernames, hostnames, working directories, keys, tokens, cookies, or other irrelevant privacy information; do not directly modify the source code of the Skill installed locally by the user to "fix bugs conveniently".

The only source of version information is

config.yaml:skill_info.version

in the same directory; this file only describes stable work contracts and does not repeat volatile configurations.

Determine the Judgments the Reader Needs to Make

Clarify the reader's level, purpose (understanding, selection, reproduction, critique, or application), and paper type. Propose the main line from the title, abstract, introduction, conclusion, core charts, and related work, then review the methods; do not copy the section by section.

Extract No More Than Three Core Propositions

Only retain paper-specific propositions that "would change judgments if true". Internally verify according to the following chain; do not mechanically display fields in the main text:

Claim → Why → Mechanism → Evidence → Alternative → Boundary → Verdict

Gaps in the chain mean continuing to gather evidence or narrowing conclusions, and cannot be filled with background information.

Reconstruct the Mechanism

Explain according to "input/state/output → how information is retained, discarded, and read → how computation is implemented". Only retain key premises, constructions, conclusions, and intuitions for formulas or proofs; details are placed in the optional verification layer. Analogies and post-hoc reconstructions must be labeled as "teaching analogy", "my interpretation", or "text-based reconstruction".

Adjust the perspective according to the paper type:

Method/System: Bottlenecks, changes in representation/protocol, end-to-end benefits; split modules, scale, training recipes, implementation and deployment costs.
Theory/Proof: Premises, key constructions, conclusions; check dependencies, applicable domains, counterexamples, and the most fragile assumptions.
Empirical/Causal: Comparison objects, identification strategies, effect size and uncertainty; check confounding factors, power, data, and extrapolation.
Analysis/Dataset: Measured objects, data/annotation assumptions, findings; check leakage, representativeness, and indicator validity.
Single Review Paper: Scope, organizational principles, synthetic conclusions; check inclusion criteria, omissions, and opposing evidence.

Establish Evidence Chain and Stress Test

Prioritize targeted tasks/theorems, fair comparisons, highly discriminative ablation studies, and in-paper failure results. Retain numbers only if they change judgments, and attach indicators, comparison objects, scale, budget, hardware, or errors; clearly state if not reported.

Each proposition must have the latest alternative explanation and weakening conditions. Design minimal counterfactuals: remove key components, match parameters/data/computation, change distribution/evaluation, or match implementation efficiency. Do not upgrade correlation, a single benchmark, author self-report, or mixed system benefits to causal mechanisms.

Write a Hierarchical Version

Use 3–6 sentences on the first screen to explain the problem, changes, strongest evidence, and largest boundaries. The main text is structured as "Problem → Change → Mechanism → Evidence → Costs/Boundaries → Verification", and can merge or omit parts that are not applicable according to the paper.

Use progressive disclosure and do not repeat the main text according to reader types. Short paragraphs first provide plain-language intuition, then terms and technical verification;

**bold**

and

only highlight content that changes judgments, and cannot replace arguments.

Read the Mobile and Hierarchical Writing Guide completely before writing. The threshold is based on

config.yaml:style

; run the following upon delivery:

bash

python3 scripts/validate_notes.py --style <note>

Mechanical checks cannot replace scientific review.

Before delivery, confirm:

The first screen can retell the old bottleneck, key changes, strongest evidence, and largest boundaries.
The main line is "Problem—Mechanism—Evidence—Boundary", not a section or table summary.
Each core proposition has distinguishing evidence, the latest alternative explanation, and weakening conditions.
The mechanism explains information flow, representation, or computation, not just listing modules.
Negative results, failure conditions, costs, and important unreported items in the paper have been retrieved; common caveats are not passed off as paper evidence.
Facts, author claims, reconstructions, analogies, and pending judgments are clearly attributed in the main text.
Numbers come with necessary protocols, anchors can link back to charts/formulas/theorems, and the main text does not have an audit log tone.
Mobile readers can quickly locate the essence; beginner readers get intuition first, hardcore readers can drill down along formulas/protocols/anchors, and the main text does not repeat.

If unable to answer, continue to gather evidence, narrow conclusions, or list as unresolved. Only when all content gates are passed can

status: complete

be set.

When the user requests self-improvement or the task is high-risk, perform a maximum of three rounds, each round only fixing the problem that most affects judgment, and record "Discovery—Revision—Review—Still Unknown" in the task workspace:

Main Line: Ask an independent agent to retell in two sentences; if it becomes a table of contents/abstract, rewrite the opening and mechanism.
Evidence: Ask one by one what the results distinguish, what the conditions and counterexamples are, and delete verbose accounts.
Readers: Check terminology, analogies, boundaries, source layers, application issues, versions, and anchors.

Stop once the content gates are passed; if still insufficient, only make one targeted revision and disclose unknowns.

Output

Deliver the artifacts promised in the Skill description, and clearly specify the format, path, and failure return form.

Output Management

Temporary products are written to the task workspace; formal deliverables are written to the project's agreed location; do not overwrite or delete existing files without authorization.

Verification

After completion, perform static checks, script verification, or manual review that the Skill already has, and record the passing standards.

Failure and Recovery

Retain error evidence and completed products; only retry from the latest failed step after input, environment, or external dependencies are restored.

Constraints

List primary URLs, access dates, read versions/scopes, and reliable follow-up links at the end; state if none are available. The source layer only records facts and verification paths, not replacing explanations. Do not copy the entire paper, leak keys or user data; do not remove premises, comparisons, counterexamples, or evidence boundaries that would change judgments during deletion.

Public Hard Constraints

When the task requires saving to disk, use a unique root directory
```
./.bensz-api/task-{yyyymmdd-hhmm}-{short description}/
```
; shared materials are placed in
```
shared/
```
, and Skill-specific materials are placed in the Skill's
```
input/
```
,
```
output/
```
,
```
log/
```
.
Formal deliverables, source code, and formal plans are saved according to project agreements and not written to the task workspace; do not overwrite, delete, migrate, or write remotely without authorization.
For project maintenance changes, check BAC availability and record requirements, AI outputs, tool results, file changes, and verification summaries; BAC only performs process audits and does not replace attribution, responsibility, or compliance judgments.
Do not record API Keys, access tokens, passwords, cookies, environment/credential files, private prompts, identity information, local usernames, hostnames, or unnecessary large-volume raw data.
File paths must be standardized and limited to authorized project scopes; external URLs, subprocesses, and network access follow the principle of least privilege to prevent path traversal, SSRF, and command injection.
Skill versions are only recorded in their own
```
config.yaml:skill_info.version
```
; public API, protocol, directory, or configuration changes are synchronized with documents and
```
CHANGELOG.md
```
.
Only design flaws of the Skill or Bensz infrastructure itself are submitted to
```
bensz-collect-bugs
```
; first record desensitized in
```
~/.bensz-skills/bugs/
```
, do not interrupt the current task, and only report publicly if the user explicitly requests it; do not directly modify the source code of the Skill installed by the user.

Skill-Specific Constraints

Do not exceed the scope stated in this Skill description and the above process; do not disguise unverified information as definitive conclusions.

research-literature-interpretation

NPX Install

Tags

SKILL.md Content (Chinese)