Useful Claude Skills for Researchers: A Curated Catalogue

What this is: A collection of reusable prompts and custom commands for common research tasks. Some are ready to copy-paste into a conversation; others are set up once as Claude Code slash commands and invoked with /command-name thereafter.

The distinction from A15 agent personalities: personalities change how Claude behaves; skills are specific tasks Claude performs. A skill is a well-crafted prompt for a recurring job — something you would otherwise retype (slightly differently each time) from memory.

Setting up skills as slash commands

A Claude Code skill is a .md file in .claude/commands/ (project-specific) or ~/.claude/commands/ (global). The filename becomes the command name. $ARGUMENTS receives anything you type after the command.

~/.claude/commands/summarise.md   →  /summarise paper.pdf
~/.claude/commands/first-pass.md  →  /first-pass register_1241.pdf

For setup instructions see A.markdown-central and A.concept.global-vs-local.

Category 1: Reading and summarising

/summarise — standard paper summary

Read $ARGUMENTS and produce a structured summary:

**Main argument** (2 sentences)
**Key evidence** (bullet list, max 5 items)
**Methods** (1 sentence)
**Sources relied on** (key authors/works cited)
**Critical note** (1 sentence: the strongest objection or limitation)
**Relevance to my research** (1 sentence — based on CLAUDE.md context)

Save the summary to the same filename with _summary.md appended.

Usage: /summarise article.pdf

/first-pass — archival source first pass

Read $ARGUMENTS. Treat it as a primary historical source.

Produce:
1. **Overview** — what this document is and what it covers (2 paragraphs)
2. **Named persons** — list with page/folio references
3. **Place names** — list with page references
4. **Date range** — earliest and latest dates mentioned
5. **Document structure** — sections, hands, any notable features visible in the text
6. **Flags** — anything unusual, damaged, or requiring specialist attention

When uncertain: mark with [?]. When text appears missing: mark with [gap].
Do not infer; record what is there.

Save to [filename]_firstpass.md

Usage: /first-pass montauban_1241.pdf

/reading-notes — seminar or supervision reading

Read $ARGUMENTS and write reading notes for seminar preparation:

1. **Main argument** (2 sentences — your characterisation, not the abstract)
2. **How the argument is built** — what evidence, what logic
3. **Methodological approach** — what kind of history/sociology/analysis is this?
4. **Where it sits in the literature** — who does it agree with, who does it argue against?
5. **Strongest objection** — what would a critical reader push back on?
6. **One discussion question** — something genuinely worth debating, not a factual question

Save to notes/[filename]_reading.md

Usage: /reading-notes article.pdf

/batch-read — process all PDFs in a folder

Read all PDF files in the current folder.
For each one, produce a one-paragraph summary: main argument, key method, key finding.
Compile into reading_batch.md with one section per file, using the filename as the heading.
Note any files you could not read or that appear to have no text layer.

Usage: /batch-read (no argument needed — operates on current folder)

Category 2: Writing and editing

/abstract — write or revise an abstract

Read $ARGUMENTS.

Write an abstract of 200 words (±20) structured as:

- Background and problem (1–2 sentences)

- Research question (1 sentence)

- Method or approach (1 sentence)

- Main findings (2 sentences)

- Significance (1 sentence)

If a draft abstract already exists in the file, revise it to fit this structure.
If not, write one from scratch based on the content.
Do not overclaim. Do not use words like "novel", "innovative", or "groundbreaking".

Usage: /abstract draft_article.docx

/review-argument — argument structure check

Read $ARGUMENTS.

Assess the argument structure:
1. State the main claim in one sentence
2. List the sub-claims or steps in the argument
3. For each step: is the evidence adequate? Is the logic sound?
4. Where are the weakest links?
5. Are there assumptions that need to be made explicit?
6. Does the conclusion follow from the argument as presented?

Do not rewrite — diagnose. Be direct about weaknesses.

Usage: /review-argument section2.md

/register-check — academic register and tone

Read $ARGUMENTS.

Identify:
1. Sentences that are too informal for academic writing (quote them)
2. Sentences that overclaim — state more certainty than the evidence supports
3. Sentences that underclaim to the point of vagueness — hedged so much they say nothing
4. Passages where Claude's voice may have crept in (smooth, generic, not yours)
5. Any jargon used inconsistently or incorrectly

For each issue: quote the sentence, name the problem, suggest one alternative.
Do not rewrite the whole passage.

Usage: /register-check draft_chapter.md

/cite-check — internal citation consistency

Read $ARGUMENTS.

Check internal citation consistency:
1. List all sources cited in footnotes or in-text
2. List all sources in the bibliography (if present)
3. Identify any source cited in the text but missing from the bibliography
4. Identify any source in the bibliography but not cited in the text
5. Note any footnotes that appear to have formatting errors (missing author, year, page, etc.)

Do not check whether citations are accurate — only whether they are internally consistent.

Usage: /cite-check draft_article.docx

Category 3: Data and extraction

/extract-persons — extract named persons from a source

Read $ARGUMENTS.

Extract all named persons. For each person:

- Name as it appears in the text

- Name variants (if the same person appears under different forms)

- Role or status (if stated)

- Folio/page references for each mention

Format as a markdown table.
When you are not sure two name forms refer to the same person, list them separately and note the uncertainty.
Save to [filename]_persons.md

Usage: /extract-persons deposition_guilhem.md

/extract-structured — extract fields to CSV

Read $ARGUMENTS.

Extract the following fields and output as CSV:
[EDIT THIS LIST FOR YOUR PROJECT — example below]

- deponent_name

- date (as given in source; add Gregorian equivalent in brackets if Julian)

- location

- inquisitor

- persons_mentioned (semicolon-separated)

- charges (1 sentence)

- confidence (high/medium/low — based on text clarity)

First row: column headers.
One row per document or deposition unit.
When a field is absent or unclear: write "unclear".
Save to extractions.csv (append if file exists; do not overwrite).

Usage: /extract-structured deposition_14.md

/consistency-check — check a dataset for issues

Read $ARGUMENTS (a CSV or spreadsheet file).

Check for:
1. Duplicate rows (identical values across key columns)
2. Empty required fields — flag any row where [NAME YOUR REQUIRED FIELDS] is empty
3. Values that appear to be outliers or errors (dates outside expected range, implausible values)
4. Inconsistent formatting in the same column (e.g. dates written different ways)

Report issues as a list with row numbers. Do not modify the file.
Save the report to [filename]_issues.md

Usage: /consistency-check depositions.csv

Category 4: Research process

/lit-gap — literature gap analysis

Read all markdown files in /notes/ (or $ARGUMENTS if specified).

Based on the literature I have engaged with as reflected in these notes:
1. What methodological approaches are well-represented?
2. What time periods, regions, or source types are well-covered?
3. What is notably absent — approaches, periods, debates I have not engaged?
4. What questions do these sources collectively not ask?
5. What would a reviewer say is missing from my literature engagement?

This is a gap analysis, not a summary. Focus on what is not there.

Usage: /lit-gap (reads notes folder) or /lit-gap article_notes.md

/refine-question — research question sharpening

I have a draft research question: $ARGUMENTS

Analyse it:
1. What is the implied unit of analysis?
2. What would count as an answer — what kind of evidence would resolve it?
3. What assumptions does the question make that need to be explicit?
4. Is the scope appropriate — too broad, too narrow, or about right?
5. Suggest three reformulations: one narrower, one broader, one that reframes the approach

Do not tell me which is best — present the options.

Usage: /refine-question How did kinship ties shape heretical belief transmission in Languedoc?

/progress-update — end-of-session log entry

Based on what we have done in this session, write a brief progress log entry for progress.md.

Include:

- Date: today's date

- What was done (bullet list, factual)

- What was found or decided (anything notable)

- Next step (what should happen next session)

Append to progress.md. Do not rewrite existing entries.

Usage: /progress-update (at end of session)

/task-plan — weekly task planning

Read CLAUDE.md and progress.md.

I have approximately $ARGUMENTS hours of research time available.
Draft a prioritised task list:
1. What must happen this week (blockers, deadlines)
2. What should happen if time allows
3. What can wait

Format as a simple checklist. Be realistic about what fits in the available time.
Ask me if there are deadlines or constraints I have not mentioned.

Usage: /task-plan 10 (for 10 hours available)

Category 5: Format conversion (quick reference)

These are covered in depth in A.markdown-central. Summary:

Command What it does
/to-md $ARGUMENTS Convert file to markdown using markitdown
/to-docx $ARGUMENTS Convert markdown to Word using pandoc
/convert-folder Convert all PDFs in current folder to markdown

Maintaining your skill library

Start small. Two or three skills you actually use beat twenty you installed and forgot. The ones worth making into commands are tasks you do at least once a week.

Evolve them. The first version of a skill prompt is rarely the best. After using /extract-persons on ten documents, you will know exactly what instructions to add. Edit the file; the next invocation uses the updated version.

Share within a team. Skills in .claude/commands/ (project-level, in git) are shared with everyone working on the project. A good extraction prompt developed by one team member is immediately available to all. This is how shared methodological conventions become embedded in the workflow.

Document what each skill does. Add a comment line at the top of each skill file:

<!-- Extract named persons from a historical source. Output: markdown table + _persons.md file -->
Read $ARGUMENTS...

This helps future you (and colleagues) understand what the skill does without running it first.

Related