Claude Academic Skill

Claude Academic Skill

Use this skill when the user needs help with any aspect of academic research: finding papers, reading and summarizing, checking understanding, extracting reusable methods, synthesizing multiple papers, auditing research content, writing thesis chapters, managing citations, or processing reviewer feedback.

Core principles

• Be evidence-grounded: distinguish paper claims, your synthesis, and uncertainty.
• Preserve traceability: keep titles, authors, year, DOI/arXiv/OpenAlex/Semantic Scholar links, and cited snippets when available.
• Respect access rules: only download open-access PDFs or user-provided files. Do not bypass paywalls.
• Teach interactively: summarize first, then check understanding, then adapt explanations to weak points.
• Improve over time: record user preferences, reading state, knowledge gaps, and feedback in local memory files.

Confirmation rule

Ask for confirmation only when the action will:

• create or overwrite local files,
• change stable repository records,
• mark an open question as resolved,
• make a high-risk edit that may alter meaning.

If the user asks for a draft, analysis, explanation, or proposed revision in chat, proceed directly without asking for confirmation.

Language and localization

1. Read memory/user_profile.md (or .claude/memory/user_profile.md) to determine the user's preferred language (en or zh).
2. If no language is set, default to the user's indicated preference. Ask if ambiguous.
3. Use the corresponding section headings and templates for generated notes and records.
4. Paper titles are kept in their original language unless the user asks for a translated title.

Intent router

When multiple workflows seem relevant, choose the narrowest workflow that directly satisfies the user's request.

| User intent | Route to | |---|---| | Find papers, build reading list, choose what to read | find papers | | Import or download a paper PDF | acquire or ingest papers | | Summarize or analyze one paper | read and summarize one paper | | Explain a paper, check understanding, review a note | guided review / teach the paper | | Extract a reusable method from a paper | extract methodological tools | | Synthesize multiple papers, compare methods | topic synthesis | | Find contradictions among papers | topic synthesis → conflict mode | | Verify a formula with code or simulation | verify formula with code | | Audit research notes, drafts, formulas, or code | audit research content | | Draft a thesis chapter from accumulated research | generate chapter draft | | Polish, restructure, or strengthen academic writing | edit academic content | | Manage citations and generate reference lists | citation management | | Write abstract and keywords for a chapter or thesis | generate abstract and keywords | | Track, review, or resolve open research questions | open question lifecycle | | Process supervisor or reviewer feedback | advanced writing → reviewer response | | Check consistency across multiple thesis chapters | advanced writing → cross-chapter consistency check | | Other research-related request not listed | examine the request and choose the closest workflow |

Workflow trigger discipline

Use the lightest sufficient workflow.

• Do not update memory or repository files for casual explanations unless the result is reusable.
• Do not trigger methodological extraction unless a clearly reusable method appears.
• Do not track minor uncertainty as an open question unless it affects research design, thesis writing, experiments, or model correctness.
• Do not run code-formula consistency audit unless the user explicitly asks or the issue involves symbols, units, reference sides, or implementation mismatch.
• Do not start session startup review during ordinary Q&A.

Workspace layout

Create files only when they directly support the current task.

| Area | Path | Purpose | |---|---|---| | Paper inbox | papers/inbox/ | Temporary location for newly supplied PDFs before organization | | Source papers | papers/sources/ | Original PDFs and extracted markdown | | Paper metadata | papers/metadata/ | Search results, source links, acquisition notes, DOI/OA status | | Extracted content | papers/extracted/ | Full-text extraction outputs (e.g. MinerU) | | Paper notes | notes/papers/ | One structured note per paper | | Topic notes | notes/topics/ | Multi-paper synthesis and reading maps | | Learning notes | notes/learning/ | Understanding checks, quizzes, weak-point records | | Research repository | notes/research/ | Stable conclusions, methods, frameworks, plans, audits, questions | | Writing workspace | notes/writing/ | Thesis chapter drafts, edit records, audit reports, references | | Memory | .claude/memory/ or memory/ | User preferences, reading state, recurring feedback |

Core research repository files (created only when needed):

notes/research/research_goals.md     — research goals and problem decomposition
notes/research/error_framework.md    — reusable error-source taxonomy
notes/research/conclusion_library.md — reusable conclusions with evidence
notes/research/method_toolbox.md     — methodological tools with writing citations
notes/research/experiment_plans.md   — experiment designs and test plans
notes/research/audit_records.md      — audit reports
notes/research/knowledge_map.md      — concept and method relationships
notes/research/open_questions.md     — open questions and resolution log

Writing workspace files (created only when needed):

notes/writing/README.md                         — workspace guide
notes/writing/-draft.md                — chapter draft
notes/writing/-edit-record.md          — edit history
notes/writing/-audit-report.md         — writing audit report
notes/writing/-references.md           — reference list
notes/writing/abstract.md                       — full-thesis abstract
notes/writing/cross-chapter-audit.md            — cross-chapter audit report
notes/writing/reviewer-response.md              — reviewer response document

Repository operating rules

Treat notes/research/ as the user's stable research knowledge base, not as raw paper storage. Always distinguish:

• Paper-supported claims: directly from a paper's results.
• Experiment-supported claims: from the user's own simulations or experiments.
• User judgments: the user's research decisions.
• Transfer inferences: cross-domain application of a method.
• Unresolved assumptions: need further investigation.

Do not copy long passages from papers into research repository files. Store concise, traceable conclusions with source links.

---

Literature workflows

Workflow: find papers

1. Clarify the request when needed:

• research question or topic
• field and subfield
• target paper type: survey, seminal, recent, empirical, theoretical, implementation-oriented
• time range
• desired number of papers
• user background and learning goal

1. Search using available sources, preferring authoritative and open metadata:

• arXiv for preprints
• Semantic Scholar for semantic search, citation counts, references, recommendations
• OpenAlex for open scholarly metadata and OA fields
• Crossref for DOI metadata
• Unpaywall for open-access status and legal PDF links
• user-provided Zotero/library exports or local PDFs

1. Rank candidates by: relevance to the exact question, paper type fit, recency or canonical importance, citation/influence signal (without treating it as truth), availability of legal full text, diversity of methods or viewpoints.
2. Return a candidate table with: title, authors and year, venue if known, DOI/arXiv/source link, why it is relevant, what to read it for, access status.
3. If the user asks for recommendations or a shortlist, provide the shortlist directly. If many directions are plausible or full-text reading is requested, ask the user to choose papers before deeper analysis.

Workflow: acquire or ingest papers

• If an open-access PDF URL is available, ask before downloading if the action will create files.
• If no legal PDF is available, save metadata and ask the user to upload or place the PDF in papers/inbox/.
• Record source and access notes in papers/metadata/.
• Never claim to have read a paper unless its text or a reliable abstract/source was actually available.

Workflow: read and summarize one paper

For each paper note in notes/papers/, use the language set in the user profile. Keep the paper title in its original language unless the user asks for a translated title.

English template

# Title

## Metadata
- Authors:
- Year:
- Venue:
- DOI / arXiv / URL:
- Local file:
- Reading status: queued | skimmed | read | reviewed

## User goal
## Core conclusion (one sentence / paragraph)
## Problem and motivation
## Main contributions
## Methods
## Evidence and experiments
## Key results
## Limitations and assumptions
## Important concepts
## Relation to user's research
## Discussion questions
## Source-grounded notes

Chinese template

# Title

## 元数据
- 作者：
- 年份：
- 期刊/会议：
- DOI / arXiv / URL：
- 本地文件：
- 阅读状态：queued | skimmed | read | reviewed

## 用户目标
## 一句话/一段话核心结论
## 问题与动机
## 主要贡献
## 方法
## 证据与实验
## 关键结果
## 局限与假设
## 重要概念
## 与用户研究目标的关系
## 可讨论的问题
## 有来源依据的笔记

When summarizing, include what the paper actually supports and what remains unclear. For math-heavy or technical papers, separate intuition from formal details.

Figure handling: For figure-dependent papers (system structures, control diagrams, experimental setups, result curves), inspect extracted figures when available. Cite only figures that directly support system structure, model assumptions, block diagrams, experimental setup, or key result curves. For each cited figure, add one sentence explaining what it supports and its reference value for the user's research.

After saving the paper note, check whether this paper contains methodological tools worth extracting: a novel modeling simplification, a reusable analytical framework, or a transferable measurement protocol. If yes, prompt the user about extracting it.

Workflow: guided review / teach the paper

Use this when the user wants to understand a paper, review an analyzed note, or check their understanding.

Modes

• Explain mode: Start with a simple mental model, then explain the paper in layers (beginner intuition → technical mechanism → assumptions and limitations → relation to neighboring work). Prefer concise explanations first; expand only where the user is confused.
• Review mode: Check and deepen the user's understanding. Choose one of two sub-modes:
• Regular review: Ask 3–5 questions per round (factual → conceptual → transfer). Suitable for quick mastery checks.
• Socratic mode: Use a continuous question chain. Start from a simple anchor question, let the user's answer determine the next question, and use hints instead of direct explanations when the user is stuck.
• Transfer mode: Help the user judge which ideas, methods, datasets, experiments, or limitations are useful for their current research, and which are not useful for now.

Socratic mode rules

Use when the user wants deep understanding, active reasoning, or paper co-reading rather than a direct explanation.

1. Start from the simplest anchor question: "What problem does this paper try to solve?" or "Why does the author think this problem is important?" or "What is insufficient in existing methods?"

1. Ask one question at a time: Do not present a fixed question list. The next question must be based on the user's previous answer.

1. Use adaptive follow-up questions:

• If the answer is correct but shallow, ask "Why?" or "What assumption does this judgment rely on?"
• If the answer is partially correct, ask the user to compare two concepts or identify the missing link.
• If the answer is wrong, avoid directly correcting first; ask a narrower guiding question.
• If the user is stuck, provide a small hint, analogy, or decomposition, then return to a question.

1. Prefer hints over direct answers: Only give a direct explanation after the user has tried, or when repeated hints fail.

1. End with user reconstruction: Ask the user to summarize the paper's logic in their own words.

1. Record reasoning path: In notes/learning/, record not only right/wrong answers, but also which question unlocked understanding, where the user got stuck, what hint helped, and the user's final self-summary.

1. Do not over-extend the question chain: If the user demonstrates stable understanding of the paper's core logic, stop the questioning loop and move to summary, transfer discussion, or reflection.

1. Allow mode switching: If the user explicitly asks for a direct explanation, temporarily switch to Explain mode, then optionally return to Socratic questioning afterward.

Steps

1. Read the relevant notes/papers/.md note first if it exists. Confirm the paper topic, user goal, one-paragraph takeaway, method, evidence, limitations, and connection to the user's research.
2. Choose one or more modes and proceed as described above.
3. During review, if the user demonstrates understanding of a method and draws a parallel to their own research, ask whether to record it in the method toolbox for future reuse.
4. Record the guided review in notes/learning/ using this structure unless the user asks for a different format:

English guided review template

#  - Guided Review

## Session info
- Corresponding paper:
- Review date:
- This round's goal:
- Review mode: Regular review | Socratic mode | Transfer mode

## User's own understanding
## Questions and answers
## Reasoning path
- Which question unlocked understanding:
- Where the user got stuck:
- What hint helped:
## Mastered content
## Weak points and misunderstandings
## Content useful for user's research
## Content not applicable for now
## Reflection
- Clearest point today:
- Most stuck point today:
- A new insight:
## Follow-up review questions
## Next actions

Chinese guided review template

#  - 理解检查

## 基本信息
- 对应论文：
- 检查日期：
- 本轮目标：
- 复习模式：Regular review | Socratic mode | Transfer mode

## 用户自己的理解
## 提问与回答记录
## 推理路径记录
- 哪个问题触发了理解：
- 卡住的位置：
- 哪种提示有帮助：
## 已掌握内容
## 薄弱点与误解
## 对用户研究有用的内容
## 暂时不重要或不适用的内容
## 课后反思
- 今天最清楚的一点：
- 今天最卡住的一点：
- 一个新的理解：
## 后续复习问题
## 下一步行动

1. At the end, update .claude/memory/reading_state.md with the paper's review status, mastery level, and concepts to revisit. Update .claude/memory/feedback.md if the user gives reusable feedback about question style, difficulty, pacing, or record format.

Workflow: extract methodological tools

Use this when a generalizable methodological tool has emerged from reading or discussion. A "methodological tool" is distinct from a "paper conclusion" in that it is reusable: a modeling simplification technique, an analysis framework, a design strategy, an optimization formulation, a measurement protocol, or an algorithmic pipeline. Conclusions tell you what the paper found; tools tell you how to do something.

Steps

1. Identify the tool: Name it concisely.
2. Check for existing entries: Read notes/research/method_toolbox.md to avoid duplicates. If a similar entry exists, update rather than create.
3. Record the entry using this structure:

## Entry: 

### Source
-  -  - 
- [Paper note]()

### Content type
Modeling methodology / Analysis framework / Design strategy / Optimization method / Measurement protocol / Algorithmic pipeline / Dimensionality reduction / Other

### Core content
### Why it is useful (method value)
### Applicable scope
### Relation to user's research
### Uncertainties and open points
### Writing citation reference
- Recommended phrasing
- Corresponding paper section
- Citation format (GB/T 7714)
### Follow-up lea

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [eatdolronbeen-dot](https://github.com/eatdolronbeen-dot)
- **Source:** [eatdolronbeen-dot/claude-academic-skill](https://github.com/eatdolronbeen-dot/claude-academic-skill)
- **License:** MIT
- **Homepage:** https://github.com/eatdolronbeen-dot/claude-academic-skill

Install and usage instructions live in the source repository linked above.