research-literature-interpretation

Research Literature Interpretation

Compress a single paper into a chain of explanation the reader can restate, question, and transfer: why the old method was limited, what the authors changed, why the mechanism might work, how strong the evidence is, and what the costs and failure conditions are.

Active selection matters more than length. Page numbers, sections, and figures serve verification only; they do not dictate the narrative.

Scope and file boundaries

• Handle only a single paper; leave discovery, screening, and deduplication to research-literature-radar, and leave multi-paper synthesis to the review skill.
• Confirm title, authors, year, venue, version, DOI/arXiv ID, primary-source URL, access date, and readable scope. Record version conflicts side by side; do not adjudicate them on your own.
• Read the abstract, introduction, conclusion, method, key figures/captions, ablations, failure cases, appendix, and code notes first, then dig deeper into the parts that affect the conclusions. When only the abstract or figures are available, deliver an evidence map and narrow the conclusions.
• Use only legally accessible primary material and reliable follow-up sources; do not bypass access restrictions, and do not execute unknown code. Distinguish static reading, actual execution, and author-reported results.
• Write to docs/papers/<friendly-id>/<friendly-id>.mdby default. Revise or append to existing notes by default; do not overwrite user content; do not modify raw/ or .bensz-api/research-literature-radar/catalog.jsonl. Put intermediate material in this round's .bensz-api/。

Process

Input

Provide the necessary inputs according to the user's request and the configuration file; missing information should be clearly listed and steps that depend on that input should stop.

Execution steps

• Treat only design flaws of this Skill (missed process judgments, incomplete input contracts, or incorrect environment assumptions) as reportable bugs; user data errors, third-party service flakiness, user-initiated source code changes, and occasional model fluctuations do not fall within this scope.
• When a design flaw is found, first record it in sanitized form to ~/.bensz-skills/bugs/, and continue the current task; only when the user explicitly requests a public report, 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 private information; do not directly modify the source code of the user's locally installed Skill to "fix a bug along the way."

The sole source of truth for the version is the config.yaml:skill_info.versionin the same directory; this file describes only the stable working contract and does not repeat volatile configuration.

Determine the judgment the reader needs to make

Clarify the reader's level, purpose (understanding, selection, reproduction, critique, or transfer), and paper type. Propose the main thread from the title, abstract, introduction, conclusion, core figures, and related work, then check back against the method; do not copy the table of contents section by section.

Distill no more than three core propositions

Keep only paper-specific propositions that "would change the judgment if true." Internally verify along the following chain, but do not mechanically display the fields in the main text:

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

A gap in the chain means either continue gathering evidence or narrow the conclusions; do not fill it with background.

Reconstruct the mechanism

Explain according to "input/state/output → how information is retained, discarded, and read → how computation is implemented." For formulas or proofs, keep only the key premises, construction, conclusion, and intuition; put details in an optional verification layer. Analogies and retrospective reconstructions must be labeled as "teaching analogy," "my explanation," or "text-based reconstruction."

Adjust the lens according to the paper type:

• Method/system: bottlenecks, representation/protocol changes, end-to-end gains; break down modules, scale, training recipe, implementation, and deployment costs.
• Theory/proof: premises, key constructions, conclusions; check dependencies, scope of applicability, counterexamples, and the most fragile assumptions.
• Empirical/causal: comparison targets, identification strategy, effect sizes, and uncertainty; check confounding, power, data, and extrapolation.
• Analysis/dataset: what is measured, data/annotation assumptions, findings; check leakage, representativeness, and metric validity.
• Single review paper: scope, organizing principles, synthesis conclusions; check inclusion criteria, omissions, and opposing evidence.

Build the evidence chain and stress-test it

Prioritize targeted tasks/theorems, fair comparisons, high-discriminative-power ablations, and in-paper negative results. Keep numbers only when they change the judgment, and attach the metric, comparison target, scale, budget, hardware, or error; if unreported, say so explicitly.

Every proposition must have the nearest alternative explanation and weakening conditions. Design minimal counterfactuals: remove the key component, match parameters/data/compute, change the distribution/evaluation, or match implementation efficiency. Correlation, a single benchmark, the authors' own account, or gains from a mixed system must not be upgraded to a causal mechanism.

Write it as a layered version

The delivered note must start with interpretation_contract: research-literature-interpretation-evidence-v1 and save in the frontmatter source_id、evidence_depth（normative/fulltext/abstract/web/source）、read_scope、stable_citation、question、method、key_results、limitations and supports_or_refutes. These fields are an evidence index and do not replace the body;fulltext must not be declared together with an abstract-only reading scope. Old notes can only use --allow-legacy for read-only checks and cannot serve as complete interpretation evidence for a new run.

Use 3–6 sentences on the first screen to state the problem, the change, the strongest evidence, and the biggest boundary. Develop the body as “problem → change → mechanism → evidence → cost/boundary → test,” and merge or omit inapplicable parts as appropriate per paper.

Use progressive disclosure and do not repeat the body according to reader type. Short paragraphs should first give the plain-language intuition, then the terminology and technical checks;**加粗** and > should highlight only what changes the judgment and must not replace the argument.

Before writing, read in full mobile and layered writing guide. Thresholds follow config.yaml:style ; at delivery, run:

python3 scripts/validate_notes.py --style <note>
# 旧笔记仅兼容读取，不用于新运行完成认证：
python3 scripts/validate_notes.py --allow-legacy <note>

Mechanical checks cannot replace scientific review.

Before delivery, confirm:

• The first screen can restate the old bottleneck, the key change, the strongest evidence, and the biggest boundary.
• The main line is “problem—mechanism—evidence—boundary,” not a chapter or table summary.
• Every core proposition has discriminative evidence, the nearest alternative explanation, and weakening conditions.
• The mechanistic explanation addresses information flow, representation, or computation, rather than merely listing modules.
• Negative results, failure conditions, costs, and important unreported items in the paper have been searched for; common-sense caveats must not masquerade as paper evidence.
• Facts, authors' claims, reconstructions, analogies, and judgments pending verification are clearly attributed in the body.
• Numbers come with the necessary protocol, anchors can be traced back to figures/tables/formulas/theorems, and the body does not read like an audit log.
• Mobile readers can quickly locate the essence; beginners get the intuition first, and hardcore readers can drill down along formulas/protocols/anchors, with no repetition in the body.

If you cannot answer, keep gathering evidence, narrow the conclusion, or list it as unresolved. Only when all content gates pass may you set status: complete。

When the user requests self-improvement or the task risk is relatively high, do at most three rounds, each round fixing only the issue that most affects the judgment, and record in the task workspace “finding—deletion/revision—recheck—still unknown”:

1. Main line: have an independent agent restate it in two sentences; if it has turned into a table of contents/summary, rewrite the opening and the mechanism.
2. Evidence: ask item by item what the result distinguishes, what the conditions and counterexamples are, and delete the running account.
3. Reader: check terminology, analogies, boundaries, source tiers, transfer questions, versions, and anchors.

Stop once the content gate is passed; if still insufficient, do only one targeted revision and disclose the unknowns.

Output

Output the deliverables promised by the Skill description, and specify the format, paths, and failure return form.

Output management

Write temporary artifacts to the task workspace and formal deliverables to the project-agreed location; do not overwrite or delete existing files without authorization.

Verification

After completion, run the Skill's existing static checks, script validation, or manual review, and record the pass criteria.

Failure and recovery

Preserve error evidence and completed artifacts; retry from the most recent failed step only after the input, environment, or external dependency has recovered.

Constraints

At the end, list first-hand URLs, access dates, read versions/scope, and reliable follow-up links; if there are none, say so. The source tier records only facts and verification paths, and does not replace explanation. Do not copy entire papers, leak keys or user data; deletions must not remove premises, comparisons, counterexamples, or evidence boundaries that would change the judgment.

Common hard constraints

• When the task needs to be written to disk, use the unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; put shared materials in shared/, and put Skill-specific materials in that Skill's input/、output/、log/。
• Formal deliverables, source code, and formal plans are saved according to project conventions and are 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 is only for process auditing 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 volumes of raw data.
• File paths must be normalized and restricted to the authorized project scope; external URLs, subprocesses, and network access follow least privilege to prevent path traversal, SSRF, and command injection.
• The Skill version is recorded uniquely in its own config.yaml:skill_info.version; public API, protocol, directory, or configuration changes are synchronized in the documentation and CHANGELOG.md。
• Only design flaws in the Skill or Bensz infrastructure itself are handed to bensz-collect-bugs; first redact and write to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting is only done when the user explicitly requests it, and directly modifying the source code of a Skill already installed by the user is prohibited.

Skill-specific constraints

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