B. Use Case Scenarios: The "Why" and "When"

Purpose: Concrete scenario sketches for each key use case. Each scenario describes: who the person is, what they actually say to Claude, what Claude does, what the output looks like, and what would NOT have worked in Claude Desktop. These are the building blocks for workshop demos and mini-book examples.

The recurring themes behind the use cases

Before the scenarios — the patterns that run through all of them:

Ad hoc vs. systematic use Some tasks are genuinely one-off: read this paper, answer this question. Desktop is fine. Others are systematic: process all sources in a project, maintain a running extraction database, iterate over a corpus. Code is necessary. Recognising which type you are doing is the first step.

Personalisation compounds over time The first week with CLAUDE.md feels like overhead. After a month, Claude opens knowing your project, your conventions, your preferences — without any re-explanation. The investment front-loads.

Iteration, not single-shot Claude rarely produces a perfect output on the first try — nor should you expect it to. The right mental model is a dialogue: ask, review, correct, refine. "Make this better" is a weak prompt. "This argument is unclear in the third paragraph because the reader doesn't yet know X — fix only that" is a strong one.

Markdown as connective tissue Across all these workflows, markdown is what everything flows through: your notes, your CLAUDE.md, your outputs, your structured data. Converting to markdown before giving Claude a document, and keeping outputs in markdown until you need them elsewhere, reduces friction throughout.

Scenario 1: "Here is a paper to read"

Who: A DISSINET researcher has received a preprint from a colleague — a 30-page article on social network analysis of inquisition records, not directly in their subfield.

What they say:

Read preprint_network_analysis.pdf

1. What is the main argument in 3 sentences?
2. What methods do they use — specifically for network construction?
3. Do they cite Duvernoy or Brenon? What do they say about them?
4. What would a critical reviewer point out as a weakness?
5. Is this relevant to my project? Context: my project is about Cathar networks
   in Languedoc 1245–1280. See CLAUDE.md for details.

What Claude does: Reads the PDF. Extracts argument, methods, specific citations by name. Applies the project context from CLAUDE.md to assess relevance.

Output: A structured 1-page response. Saved to reading_notes/preprint_network.md if asked.

Why Desktop would be slower: Same task is possible in Desktop — but requires uploading the PDF. If the researcher then wants to compare it to three other papers, that is three more uploads. Claude Code just reads what is already on disk.

Workshop demo potential: Medium. Good for showing how CLAUDE.md project context changes the last question.

Scenario 2: "Here is a dissertation you should review"

Who: A supervisor has received a 280-page PhD dissertation to review over the weekend.

What they say (Desktop, with the dissertation uploaded to a Project):

This is a dissertation I am reviewing. Read it and give me:

1. The core argument (2 paragraphs)
2. Chapter by chapter: what each chapter claims and whether it delivers on that claim
3. The three strongest points in the dissertation
4. The three weakest points — where the argument is thin, evidence insufficient,
   or methodology unclear
5. Does Chapter 4 (the quantitative analysis) make appropriate use of network metrics?
   Flag any potential misapplications.
5. Suggested questions for the oral defence (viva)

What Claude does: Reads the full dissertation. Produces a structured critical review. The final question (network metrics) applies domain expertise the researcher cares about specifically.

Output: A 4–6 page review document usable as the basis for the formal review.

What requires human review: Everything substantive. Claude will identify patterns and gaps — the supervisor judges which are real. The viva questions in particular need triage: Claude will produce generic and good questions mixed together.

Why this matters: A 280-page dissertation is within Claude's context window. Reading it takes Claude 2–3 minutes. Writing first-pass structured feedback takes another 2–3 minutes. The supervisor spends their time on the intellectual judgement, not the read-through.

Workshop demo potential: High for Desktop — shows Projects handling a large document. Strong emotional resonance with the audience.

Scenario 3: "Here is a draft of my paper"

Who: A researcher has a near-complete draft of a journal article and wants feedback before sending to co-authors.

What they say (Claude Code, draft in project folder):

Read my current draft: article_draft_v3.md

I want feedback in two passes:

Pass 1 — argument and structure:

- Does the introduction set up what the paper actually delivers?

- Is the transition from Section 2 to Section 3 clear?

- Does the conclusion go beyond summarising — does it say something new?

Pass 2 — specific writing:

- Flag any sentence longer than 40 words

- Flag any paragraph that starts with "It is" or "There is"

- Flag passive voice in the methodology section
Write your feedback as inline comments in a copy: article_draft_v3_feedback.md

What Claude does: Two-pass reading. Creates a feedback copy with inline comments formatted as [FEEDBACK: ...]. Argument-level feedback as a separate section at the top.

What requires human review: All argument judgements. The mechanical writing flags (long sentences, passive voice) are reliable; the structural feedback needs the author's evaluation.

Why Code over Desktop: The "write feedback to a new file" instruction creates a file on disk directly. In Desktop, the researcher would need to copy Claude's response text and paste it somewhere. With a long draft, that is meaningful friction.

Workshop demo potential: High — shows the practical "write output to disk" advantage clearly.

Scenario 4: "I need to write a grant proposal"

Who: A DISSINET researcher is preparing a submission to a Czech Science Foundation (GAČR) individual project call.

What they say (in a dedicated Claude Desktop Project for the grant):

I am writing a grant proposal for GAČR. The call is for a 3-year project.
My research topic: [topic]
Core argument: [argument]
I have attached: the call text (gacr_call.pdf), my CV (cv.pdf),
and my project notes (project_notes.md).

Today's task: draft the "State of the Art and Innovation" section (max 5000 characters).
Requirements from the call: [paste relevant excerpt]
My key points to hit: [list]
Previous draft: [paste or attach]

Please draft this section. Stay within 5000 characters.
Mirror the language of the call text where appropriate.
Do not add claims I haven't made in my notes.

What Claude does: Reads all context. Drafts the section within the character limit. Uses the call's own framing language. Stays inside the researcher's stated claims.

Iteration round 2:

Good. Now I want to strengthen the third paragraph —
the reviewer won't know why our network approach is better than prosopography.
Add one sentence making that explicit, without changing the paragraph's length.

Why this workflow works: The Project holds all the documents permanently. Each writing session starts with full context. The researcher does not need to re-explain the project or re-attach documents.

What requires human review: All factual claims. The character count. Whether the "call language mirroring" is natural or jarring. Whether the innovation claim is actually defensible.

Workshop demo potential: Very high — grant writing is a universal pain point. Shows Project instructions + iterative refinement.

Scenario 5: "I need to refine my research problem"

Who: A PhD student is six months in, has read a lot, but feels their research question is still too broad or unclear.

What they say:

I want to use you as a thinking partner to sharpen my research question.
My current question: "How did social networks shape the survival of Cathar communities
after 1244?"

Please don't give me a new question. Instead:
1. Ask me three clarifying questions that will help us narrow this down together.
2. After I answer, reflect back what you heard and suggest two more specific framings.
3. We will iterate from there.

What Claude does: Enters Socratic dialogue mode. Does not produce a polished answer immediately. Asks questions that surface what the researcher actually cares about vs. what they think they should care about.

Why this is valuable: Claude will not get tired, will not have opinions about what is a "correct" research question, and will not signal approval prematurely. It is a neutral sounding board with depth.

What requires human judgment: Every decision. Claude facilitates; the researcher decides.

The limitation to flag: Claude will sometimes produce a refined research question that sounds good but subtly drifts from what the researcher actually means. The researcher must own the final formulation.

Workshop demo potential: Medium — harder to demo quickly, but resonates strongly with PhD students and supervisors.

Scenario 6: "Here is a folder of 40 PDFs from my archive scan"

Who: A researcher returns from an archive trip with 40 JPEG/PDF scans of inquisition registers. They need to know what they have before deciding what to transcribe.

What they say (Claude Code):

I have 40 PDF scans in /archive_trip_2025/
They are inquisition registers, probably 13th century Languedoc.
Quality varies — some are clear, some are faded.

For each file:
1. Can you read it? (yes / partial / no — rate readability)
2. If readable: what does it seem to contain? (deposition? notarial act? other?)
3. Any names or dates visible in the first few lines?
4. Any obvious structural features (columns, marginalia, rubrics)?

Write results to: archive_overview.md
Use a table format: filename | readability | content_type | first_names | notes

What Claude does: Works through the 40 files one by one. Produces a structured table. Flags unreadable files. Gives the researcher a triage document.

What requires human review: Every readability assessment. Claude's OCR-free reading of manuscript images is imperfect — it will confuse letters, miss abbreviations, misread damaged passages. The table is a starting point for the researcher's own triage, not a definitive inventory.

Why this is the core demo: This is the scenario that best illustrates what Code can do that Desktop cannot. 40 uploads in Desktop would take 20+ minutes of manual work and multiple sessions. Claude Code does it in one prompt.

Workshop demo potential: Maximum — this is the live demonstration. Use real DISSINET archive scans if available. The audience sees Claude working through the files one by one in the terminal in real time.

Scenario 7: "Here is my Zotero library"

Who: A researcher is starting a new project sub-thread and needs to know what they already have in Zotero before going to the library.

What they say (with Zotero MCP connected):

Search my Zotero library for materials relevant to:
"economic relations between perfecti and credentes in Cathar communities"

For each result:

- Author, title, year

- One sentence on relevance

- Whether I have the full text attached

Then: are there obvious gaps? What key authors or works would you expect to find
on this topic that are NOT in my library?

What Claude does: Queries Zotero via MCP. Returns relevant results with relevance summary. Identifies gaps based on its knowledge of the field.

The gap identification caveat: This is the interpretation/execution boundary. The relevant results retrieval is reliable. The gap identification is Claude's best guess from training data — it may suggest works that don't exist or miss important recent publications. Treat gaps as suggestions to investigate, not a definitive bibliography.

Workshop demo potential: High for Zotero users — shows MCP in action. Requires prior Zotero MCP setup (may need to be pre-configured for the demo machine).

Scenario 8: "Help me organise this project"

Who: A researcher has a messy project folder — PDFs scattered, notes in various formats, no clear structure, a partially started CLAUDE.md.

What they say (Claude Code):

I want to organise this project folder. Here is what I have:
[Claude reads the folder structure]

Help me:
1. Propose a sensible folder structure for a historical research project with
   primary sources, secondary literature, my notes, and data outputs
2. List which existing files belong where in that structure
3. Draft a CLAUDE.md for this project — ask me 5 questions first to get the context right

What Claude does: Reads the folder. Proposes structure. Lists files with suggested destinations. Then enters dialogue mode to build the CLAUDE.md.

The CLAUDE.md dialogue:

Claude: Before I draft CLAUDE.md, I need to understand the project. Let me ask 5 questions:
1. What is the core research question in one sentence?
2. What are the primary source types you work with?
3. Are there key terms or concepts that always need consistent handling?
4. What is your preferred output format when I extract data?
5. What should I never do without asking you first?

Why this matters: Project organisation is something researchers perpetually defer. Claude Code can do the inventory and propose the structure in 5 minutes. The CLAUDE.md dialogue produces a document that will save time on every future session.

Workshop demo potential: Good for showing CLAUDE.md creation in action. The "5 questions" dialogue is memorable.

B — themes for the workshop

From these scenarios, the key workshop messages are:

  1. The same Claude, very different capability — scenarios 1–5 mostly work in Desktop; 6 does not. The question is always: does this involve the filesystem?

  2. Context is everything — every scenario improves significantly when CLAUDE.md provides project background. The difference between "summarise this paper" and "summarise this paper in the context of my project on Cathar networks 1245–1280" is large.

  3. Iteration is the workflow — no scenario produces a finished product on first ask. All of them involve at least one follow-up round.

  4. The researcher stays in charge of interpretation — in every scenario, the output is a first draft, a triage, a structured starting point. The intellectual work — deciding what matters, judging what is true, owning the argument — remains entirely with the researcher.

Related