content/skills/research-learning-knowledge/paper-workbench/SKILL.md
Researcher-profile-driven paper intake and literature workbench for academic workflows. Use this whenever the user wants to skim, deep-read, card, compare, synthesize, map research gaps, or build a literature review from papers, arXiv/AlphaXiv links, DOIs, PDFs, landing pages, or existing paper JSON / workbench artifacts. Normalize sources into `paper-record`, then route into scan, deep-read, card, synthesis, review, or compatibility modes (`json`, `interpret`, `xray`). Trigger even when the user only says things like “精读这篇”, “整合这几篇”, “找研究空白”, or “搭综述框架”.
npx skillsauth add bahayonghang/my-claude-code-settings paper-workbenchInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Unified entrypoint for paper intake, strategic reading, multi-paper synthesis, and review construction.
Keep paper-record as the normalization layer. Do not merge high-level
analysis back into the normalized record.
Use this skill when the job is to:
Do not use this skill when the primary job is to implement a paper. In that
case, route to paper2code.
paper-record — normalized single-paper factsresearcher-profile — user research anchorpaper-deep-read — single-paper strategic analysis artifactliterature-synthesis — cross-paper integration artifactreview-outline — literature-review planning artifactdoi.org/... URLspaper-record JSONresearcher-profile, paper-deep-read, literature-synthesis, or
review-outline JSON$ARGUMENTS, the latest user message, or a
pasted JSON artifact.scripts/normalize_paper.py first.researcher-profile or collect only the missing fields.scan
deep-read
card
interpret
xray
json
paper-recordsynthesis
review
jsonscansynthesissynthesis and mark any gap mapping as provisionalFor any paper-like input, run:
python "$SKILL_DIR/scripts/normalize_paper.py" \
--source "<paper-source>" \
--lang "<lang>" \
--fulltext "<auto|prefer|never>"
Use --save only when the user asked to persist the normalized JSON.
Before deep-read, card, synthesis, or review, prefer a
researcher-profile.
If missing, collect only these fields:
research_fieldcore_questionthesis (optional)target_tierstageIf the user clearly wants no back-and-forth, proceed with a generic profile-light analysis and explicitly mark that personalization is limited.
If the user wants persistence, create or update the profile with:
python "$SKILL_DIR/scripts/workbench_io.py" init-profile \
--path "<profile-path>" \
--research-field "<field>" \
--core-question "<question>" \
--thesis "<optional-thesis>" \
--target-tier "<target-tier>" \
--stage "<stage>"
When the user asks to save a deep read, synthesis, or review plan, write a JSON artifact plus an optional Markdown or Org sidecar:
python "$SKILL_DIR/scripts/workbench_io.py" save-artifact \
--workspace "<workspace-dir>" \
--artifact-type "<paper-deep-read|literature-synthesis|review-outline>" \
--title "<artifact-title>" \
--payload-file "<json-payload-file>" \
--profile-path "<optional-profile-path>" \
--source-record "<path-to-paper-record>" \
--sidecar-file "<optional-md-or-org>"
作者观点 from 系统分析[信息待核实]synthesis and review must integrate arguments across papers rather than
serially summarizing each paperreview paragraphs must use PEEL as a micro-argument structure, not a
citation listdeep-read:
references/routing.md — source classification and routing logicreferences/schema.md — canonical paper-record contractreferences/artifacts.md — researcher-profile and higher-level artifactsreferences/migration.md — compatibility and alias mappingreferences/modes/json.md — machine-readable output rulesreferences/modes/interpret.md — lightweight explanation pathreferences/modes/xray.md — compact critique pathreferences/modes/scan.md — single-paper quick triagereferences/modes/deep-read.md — full single-paper deconstructionreferences/modes/card.md — literature card onlyreferences/modes/synthesis.md — cross-paper integrationreferences/modes/review.md — literature-review planning and writingdevelopment
Implement safe, behavior-preserving code refactors after inspecting the existing project. Use when the user asks to refactor code, split large files or modules, extract functions or methods, reduce duplicated logic, rename confusing classes/functions/variables, improve code comments, remove unused or dead code, or says 重构代码, 拆分模块, 提取方法, 减少重复代码, 优化命名, 优化注释, 删除未调用代码. For broad refactor requests, plan safe slices and wait for approval; for narrow scoped requests, directly implement the smallest verifiable slice.
development
Use only when the user explicitly asks for swarm, subagents, parallel agents, dynamic workflow, multi-agent orchestration, 多智能体编排, or when the task truly needs coordinated research plus implementation plus review plus verification packets. Do not use for ordinary code review, planning-only work, single-line bugfixes, routine audits, or migrations unless orchestration is requested or at least two independent workflow dimensions are present.
development
Run a code quality review focused on maintainability, structure, abstraction quality, file growth, branching complexity, boundary cleanliness, and refactoring opportunities. Use when the user asks for code quality review, code review, maintainability review, architecture quality review, PR code quality feedback, 代码质量审查, 代码质量 review, 可维护性审查, 架构质量审查, or review comments about code structure. Do not use for pure security review, formatting-only review, performance profiling, or implementation tasks unless the user also asks for a code quality review.
development
Plan-first brainstorming workflow that turns an idea into an approved Markdown implementation plan by default. Use when the user wants to brainstorm, design, scope, or plan a feature/spec before implementation. Spark explores project context, asks only blocking questions, writes the plan under the project root's .plannings/YYYY-MM-DD-feature-slug.md path, self-reviews it, and waits for user approval. Create an HTML or visual plan/spec only when the user explicitly asks for HTML, browser-viewable, or visual output; save the paired .html beside the Markdown plan.