research-literature-radar

Research Literature Radar

Goal

Turn candidate papers from different discovery channels into a sustainably maintained research radar.research-literature-search It is only a retrieval sub-step of this skill, responsible for database recall based on explicit keywords, field normalization, canonical deduplication, and provenance; this skill is still responsible for layered discovery, cross-channel aggregation, value judgment, classification, tracking, and archiving.

This skill is responsible for:

Translating user goals into screening criteria and paper-type quotas;
Judging relevance, evidence depth, publication status, and identity credibility for all canonical candidates separately;
Classifying, ranking, recording uncertainty, and retaining core, auxiliary, to-be-tracked, and out-of-scope roles;
Mapping selected papers to stable IDs, writing them into the paper library, and maintaining cross-round tracking.

Trigger and Input Overview

Triggered when the user proposes "find papers worth reading", "build a paper radar for a certain topic", "recommend papers by type such as classic/hot/top conference", or similar discovery and learning needs.

Required: user topic and target quantity. Optional: domain/subtopic, quotas for the five paper types (classic、rising-star、community、hot、top-venue), time window, author/venue whitelist, exclusions, whether to download public PDFs, note depth.

Before running, read .bensz-api/research-literature-radar/catalog.jsonl(create if it does not exist), and retain the user's original request and run date.

Process

Input

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

Execution Steps

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

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

Do not simplify paper discovery into a single keyword search. According to the user's topic and target quantity, combine the following five types of channels; each type may use online search, researcher context, or community signals, but its source and purpose must be recorded:

Classic papers: Locate field founders, star researchers, surveys, awards, and recognized milestones, then find their representative works.
rising-star papers: Find authors, labs, or research lines that have made continuous breakthroughs in the past 3–5 years, focusing on researchers who are not yet widely known but whose influence is rising rapidly.
Community selections: Check Hugging Face Daily/Weekly/Monthly Papers, Import AI, researcher newsletters, WeChat official accounts/X accounts, and trusted curated pages.
Occasional hot papers: Focus on papers that have attracted attention after recent publication due to discussion volume, code dissemination, news, or social platforms, even if the authors are not well known.
Recent papers at top conferences/top journals: Use with emphasis only when the user's topic is sufficiently narrow, combined with a clear venue and time window, to avoid broad topics producing endless candidates.

research-literature-search is responsible for the small step of "retrieving academic databases based on keywords"; classic author lineages, community selections, and hot-signal sources cannot be assumed to appear automatically in that retrieval bundle.

Preferred: call the search backend

When the layered strategy requires keyword/database recall, call research-literature-search of run, providing it with valid topic and 5–25 explicit queries; then call its validate. Only accept manifest.json bundles whose status is success or partial_success . When there is no channel requiring database retrieval, do not force a call for form's sake; but you must state which other discovery channels were used.

Save the following files as read-only inputs to this radar run:

manifest.json
candidates_deduped.jsonl
provenance.jsonl
dedupe_map.json

Candidates must conform to rls.paper.v1. Preserve the manifest, contract version, artifact hash, canonical candidate count, and search source path for traceability. If search was actually called but bundle validation fails, there are no valid queries, or the search skill cannot be discovered, stop that retrieval substep and report the reason; do not silently switch to another embedded provider. Other layered channels may still be independently recorded as supplementary discoveries, but must not be disguised as search results.

Supplementary discovery signals

Non-standard database signals such as community selections, awards, researcher compilations, code dissemination, or news discussion may serve as supplementary evidence, but must:

Record the URL, access date, source purpose, and corresponding paper identity;
Map to an existing canonical candidate, or serve as a clearly marked candidate pending confirmation;
Not be disguised as search provider results, and not override search's canonical order and deduplication conclusions.

When supplementary signals produce new papers, compare them against the catalog using this skill's stable identity keys; mark similar but unconfirmable records as possible_duplicate, and do not silently merge them.

First build a landscape for all canonical candidates, then score those that may enter the core set. Each record includes record_id、canonical_rank、role、cluster、relevance、evidence_depth、publication_status、identity_confidence、use_cases、reason、uncertainties and source_refs. Titles may be used for discovery, clustering, and watchlists; abstracts may support relevance and author self-reported judgments; strong conclusions about methods, results, and equivalence must match full-text evidence. Preprint status and source count cannot replace relevance judgment.

Have AI batch-cluster and fill in brief judgment drafts, then run scripts/build_landscape.py --bundle <search-bundle> --draft <draft.jsonl> --output <literature-landscape.jsonl> --summary <landscape-summary.json> to reconcile manifest/hash, full coverage, ID uniqueness, enumeration, canonical order, and counts. Deterministic scripts must not hard-code domain keywords or judge scientific value on AI's behalf.

Record core candidates on a 0–5 scale:conceptual_novelty、simplicity、surprise、generality、unification、new_primitive、follow_up_potential、practical_impact. Evidence quality is listed separately as confidence, and is not mixed into "interestingness".

For each core candidate, record the total score, a two-sentence rationale, key evidence, idea tags, and uncertainties; the remaining candidates are still retained in the landscape and must not be reduced to a total number of rejected items. Idea tags may use:problem-reformulation、unexpected-simplicity、hidden-equivalence、assumption-revisit、new-measurement、failure-revealing、new-primitive、cross-domain-transfer。

Use quotas to check research line coverage, but do not select low-quality papers just to fill quotas; then form a small, refined core set based on total score, idea tags/years/author diversity. When auxiliary or to-be-tracked entries become key neighbors, retain the Search record ID, and may add R anchors and interpretation history, without re-deduplicating.

scripts/catalog.py Provide network-independent ID generation, title normalization, index loading, and duplicate determination;scripts/validate_layout.py Before delivery, check whether run-level files are mistakenly written to the docs/papers/ root directory. The script does not download or delete files.

Output

Each round first loads the catalog, then consumes the verified search bundle. Duplicates only update the source, version, rating, or follow-up record; only genuinely new papers create directories. Write the literature-landscape.jsonl、landscape-summary.json、discovery.md、selection.md、dedup-report.md and the run summary into the same runs/<run-id>/, and explicitly state canonical count = core + supporting + watchlist + out_of_scope.

Confirm before delivery: every actually used search manifest is consumable, and the canonical hash and count are traceable; the landscape covers exactly every canonical record ID; the applicability and coverage of the five channel types are explained. One reliable source is usually sufficient to confirm identity; only metadata conflicts, version merges, suspected duplicates, or decisive near neighbors require additional verification. IDs, metadata, catalog, raw manifest, and internal paths are consistent; the root directory index.md already contains every newly added paper;docs/papers/ the root directory contains no run-level files.

Output Management

Directory IDs use <first-author-full-name>-<year>-<keyword>: the first author's full name, four-digit year, and an identifiable work/method keyword are all ASCII lowercase and separated by a single hyphen. Keywords preferentially use recognized abbreviations; when there is no stable abbreviation, use a short slug of the title. External numbers such as arXiv, DOI, and OpenReview cannot be used as the directory primary name and must be written into identifiers。

The identity comparison order is DOI → arXiv/OpenReview → other stable IDs → normalized title + first author + year. Preprints and official versions are merged and version links are retained; on conflict, append a stable short hash to the end of the keyword. Existing notes are not overwritten; only missing fields are supplemented and the reason for the change is stated in history .

docs/papers/
└── <friendly-id>/
    ├── raw/                       # 公开 PDF、HTML、metadata、manifest
    └── <friendly-id>.md           # 学习笔记

.bensz-api/research-literature-radar/
├── catalog.jsonl                  # 跨轮次论文索引
└── runs/<run-id>/                 # run.yaml、search 交接包、筛选与去重报告

docs/papers/ Store only paper entities and their original materials/study notes; run-level configuration, manifests, screening reports, logs, and deduplication reports are uniformly written into .bensz-api/research-literature-radar/. Original files are named with external identifiers, may record SHA-256, and silent overwriting is prohibited.

catalog.jsonl Each line records at least id,title,authors,year,venue,status,paper_types,tags,identifiers,sources,files,scores,confidence,first_seen_run,last_seen_run,history, and id must be consistent with the paper directory name and the note file name.

Validation

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

Failure and Recovery

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

Constraints

Comply with the following public constraints, and enforce this Skill's specific boundaries.

Public Hard Constraints

When a task requires writing to disk, use a unique ./.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/ root directory; shared materials go into shared/, and Skill-specific materials go into that Skill's input/、output/、log/。
Formal deliverables, source code, and formal plans are saved according to project conventions and are not written into the task workspace; without authorization, do not overwrite, delete, migrate, or write remotely.
Project maintenance changes check BAC availability and record requirements, AI outputs, tool results, file changes, and validation summaries; BAC only performs process auditing and does not replace attribution, responsibility, or compliance judgment.
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 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 uniquely recorded in itself config.yaml:skill_info.version; public API, protocol, directory, or configuration changes are synchronized with the documentation and CHANGELOG.md。
Only design flaws in the Skill or the Bensz infrastructure itself are handed over to bensz-collect-bugs; first write them in desensitized form to ~/.bensz-skills/bugs/, the current task is not interrupted, public reporting is done only 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 definitive conclusions.