Workshop: Claude Code and Claude Desktop as Research Assistant for Humanities

Audience: Researchers at DISSINET — historians and social scientists in computational humanities, mostly non-programmers or light coders.

Format: ~3h in-person workshop. Self-contained materials (usable without presenter afterward).

Presenter profile: Technical person who is also a humanities insider. Can code. Goal is to "sell" Claude Code even to people who don't code or code little.

Participant setup: All have Claude Pro license + Claude Desktop installed. Claude Code is NOT pre-installed.

Core pitch: Claude Code is not just for programmers. It is a better research assistant than Claude Desktop for document-heavy work — and you can use it too.

The one takeaway: I can use Claude Code, not just Desktop — or at least I can use Desktop much better than before.

Focus: AI as AID in day-to-day research work

The workshop covers AI assistance across the full range of researcher activity at DISSINET:

• Document work — reading, annotating, extracting from PDFs, DOCX, XLSX, MD (this is the core)

• Writing aid — drafting, revising, grant proposals, paper reviews

• Research aid — refining research questions, literature searching, Zotero integration

• Project/personal management — organising work, tracking tasks, using markdown as project memory

• Data analysis — working with spreadsheets, structured data, light scripting

Development phases

Phases C and D will be decided once materials are gathered — the material pool may exceed what fits in 3h; we will select.

A. Gathering materials

Each item = a document or set of notes gathering relevant facts, examples, screenshots, links.

Tool understanding

• A1 Claude Desktop vs Claude Cowork vs Claude Code: three-tier comparison — when to use which ✓

• A2 Claude Desktop basics: Projects, custom instructions, skills/plugins — how to get the most out of Desktop ✓

• A3 Claude Code basics for non-programmers: installation, launching, what it looks like, why it is not scary ✓

• A4 Conceptual vocabulary: MCP, Skills, context window, system prompt — minimum necessary understanding ✓

• A5 Claude Code keyboard shortcuts and daily usage patterns ✓

• A6 Claude Code for non-programmers: specific workflows that require zero coding ✓

Concepts

• A.concept.under-the-hood — how Claude Desktop and Code work under the hood ✓

• A.concept.agents — what "agent" means, chat vs. agent mode, trust/supervision for researchers ✓

• A.concept.global-vs-local — working directory as project environment; global vs. local layers ✓

• A.issue.upload-dance — the upload dance problem and how Code solves it ✓

• A.setup.settings-local — .claude/settings.local.json basics and tips ✓

• A.setup.windows-wsl — WSL vs native Windows: decision guide and setup instructions ✓

• A.token.management — tips about how to be efficient in token usage (context window and also limits) ✓

Document-centric workflows (core)

• A7 Working with PDFs in Claude Code: reading papers, extracting data, batch processing a folder ✓

• A8 Working with DOCX and XLSX: editing drafts, reading spreadsheets, light analysis ✓

• A9 Using markdown files as project memory and context for Claude ✓

• A.markdown-central — markdown as the hub format: to-markdown and from-markdown tools, skills ✓

• A.markdown.history — why keep a project history file: the complement to CLAUDE.md, how to use it with Claude ✓

• A.markdown.meta-docs — all four project meta-documents as a practice: _history (narrative), _ownership (attribution), progress (task state), _index (concept navigation); why keep them; how to use them at session boundaries ✓

• A.markdown.token-efficient-docs — writing lean context: seven principles for token-efficient project files (active instructions vs. background, structure over prose, positive instructions, front-loading, read-frequency-matched structure, @imports for depth, pruning) ✓

• A10 Claude and Zotero: searching your library, summarising sources, connecting to a research question ✓

• A.working-with-images — multimodal: what Claude can do with images (description, transcription, table extraction, comparison) and its limits; workflows for manuscript photographs, historical maps, archival diagrams ✓

• A.setup.zotero-mcp — step-by-step installation of zotero-mcp MCP server; Path A (Windows native for Claude Desktop via uv); Path B (WSL for Claude Code via web API — the local API WSL2 bug documented); known issues ✓

Real-world examples (internet research)

• A11 Good practice examples: academics and researchers using Claude Code — find and document ✓

• A12 Good practice examples: Claude Desktop used well for research — find and document ✓

• A13 DISSINET-relevant use cases: network data, historical sources, Latin texts, grant writing ✓

• A11-A13.research-examples-raw — raw web research findings with all URLs ✓

• A14 Useful Claude skills and plugins for researchers (curated set of reusable prompts and commands) ✓

• A.skills-ecosystem — the Claude skills ecosystem overview for researchers: discovery channels, document foundations (pdf/docx/xlsx), K-Dense scientific skills + Imbad0202 academic pipeline, lifecycle-mapped skill selection, caveats on automated pipelines; distributional convergence principle; creating your own skills (skill-creator tool, DISSINET examples) ✓

• A15 Useful agent personalities for social science and humanities research ✓

• A16 Claude for personal life management ✓

Critical perspective

• A.critical.limitations — hallucination stats, vibe research, execution vs. interpretation, qualitative cautions ✓

• A.issue.privacy-security — where your data actually goes: Desktop vs. Code vs. e-Infra, GDPR, agentic risks, decision matrix by data type ✓

• A.issue.context-scope — what to put into Claude and why it matters: the "too much" and "too little" crisis states, CLAUDE.md scope guidelines, maintaining context over time ✓

• A.issue.bounding — bounding the problem: the spectrum from underbounded to overbounded tasks; what is necessary/misleading/unnecessary in a prompt; decomposing complex tasks; the "state your understanding" check ✓

• A.issue.plan-mode — plan mode (Shift+Tab): separating proposal from execution; when to use it; the practical pattern (describe → plan → review → approve → execute); researcher framing (irreplaceable data, supervision principle) ✓

• A.issue.python-basics — Python survival guide for non-programmers: pip install explained, uv alternative, virtual environments concept, common failures, when to ask Claude to handle it ✓

• A.issue.nodejs-basics — Node.js/npm/npx survival guide: why it's no longer needed for Claude Code install but still required for skills and MCP servers; four commands researchers encounter ✓

• A.issue.prompt-iteration — debugging failing output: three root causes (task misunderstood / wrong context / underbounded), reading response signals, iterate-vs-restart decision rule, targeted fixes, when the prompt is not the problem ✓

Model and configuration

• A.issue.model-selection — when to use Sonnet vs Opus vs Haiku: task-type calibration, quota implications, quick-reference table ✓

• A.issue.costs-quotas — Claude Pro quota mechanics, rate limits, API economics, token estimation for DISSINET-scale work, practical decision rules ✓

• A.concept.memory — Claude Code's Memory system: Claude-written persistence distinct from user-written CLAUDE.md; /memory command; what belongs in Memory vs. CLAUDE.md ✓

• A.issue.personalisation — the full personalisation system: Claude Code mechanisms layer (CLAUDE.md, Memory, Skills, Hooks, MCP) and project accountability files layer (_history, _ownership, progress); step-by-step setup sequence ✓

• A.issue.team-claude — team sharing via git: personal vs. shareable configuration; team baseline (shared CLAUDE.md + skills); settings.json vs. settings.local.json; onboarding; machine migration ✓

• A.issue.slack-workspace — Slack as team worktable: copy-paste txt workflow (selective consent), Slack MCP server (full integration), privacy/consent threshold, four use cases (workflow memory, onboarding, decision documentation, synthesis) ✓

• A.issue.research-data-memory — compartmentalising project memory for data-heavy research: three-layer model (CLAUDE.md as router / domain knowledge layer / meta-docs); data description, analysis plan, transformation log, data variants, proposal anchor; trialinter _logic/ as concrete example ✓

• A.issue.research-wiki — the compounding research wiki: Karpathy LLM Wiki pattern; three layers (sources / wiki / CLAUDE.md as schema); three operations (Ingest, Query, Lint); error compounding and graph self-correction; perspective filter; decision-support framing; Memex historical note ✓

• A.issue.session-endings — the pre-close audit: planned vs. discovered session output; what lives only in the conversation; the update trigger; session-end prompts for progress log and history ✓

Literature and resource discovery

• A.literature-discovery — assembling the search stack: Gemini Deep Research, Claude Code database skills, Elicit, Research Rabbit; the 6-step discovery workflow; Zotero as capture layer; verification rule ✓

Adjacent tools (context only, not taught)

• A.adjacent.gemini — Gemini Deep Research: what it does differently, when it complements Claude ✓

• A.adjacent.tools — NotebookLM (incl. Claude Code integration), Perplexity, broader landscape ✓

Note-making and reading/writing workflows

• A.workflows.notes-reading-writing — Claude for note-making, reading workflows, PKM, Zettelkasten, writing ✓

• A.workflows.notes-reading-writing-raw — raw web research findings ✓

• A.obsidian-logseq — Obsidian (file access) and Logseq (MCP integration) with Claude; the Zotero+PKM+Claude triangle ✓

• A.multi-project-planning — planning across multiple repos with symlinks; planning CLAUDE.md pattern ✓

• A.git-for-researchers — git as safety net for Claude Code sessions; version control for text and data work ✓

B. Experience points — researcher workflow and the "why"

Think through user experience: when does AI help, when does it get in the way, what changes the workflow.

• B.usecases — full scenario sketches for all 8 use cases, with what Claude does, what requires human review, and workshop demo potential ✓

Meta-documents

• README.md — public-facing entry point: audience/pitch, file structure map, curated reading map by theme, key concepts table, authorship disclosure summary ✓

• CLAUDE.md — project context for Claude Code: structure, naming conventions, working conventions, trigger to run /update-meta-docs ✓

• _history.md — development history: decisions, pivots, reasoning behind each document ✓

• _history.archive.md — archived sessions 1–16 (split from _history.md to reduce context pressure on /update-meta-docs) ✓

• _ownership.md — ownership record: who made what, by mode of collaboration; disclosure statement for publication ✓

• _microcase.template.md — template for collecting personal experience cases: 4-part structure (problem / challenge / solution / good-bad-ugly) with leading questions ✓

• .claude/commands/update-meta-docs.md — slash command for updating the three meta-documents at session end ✓

• _index.md — ~120-term concept-to-documents index: quick-search input, wiki hover data source, network visualisation term layer; covers all major themes across A/B/C/E documents ✓

• B.experience — the experiential dimension: control/ownership axis, emotional states (joy, curiosity, overwhelm, anxiety, FOMO), real vs. anxiety-driven productivity, work-life balance ✓

• B.ownership — assessing the distribution of ownership: dimensions of contribution, asking Claude for an honest accounting, practical review prompts, connection to disclosure ✓

• B.trust — trust as a designed relationship: three dimensions (accuracy, scope alignment, epistemic transparency); project infrastructure as trust infrastructure; verification as architecture; trust calibration by task type; trust degradation; team trust conditions ✓

• B.autonomy — autonomy as a long-term relationship with AI: the paradox (AI can increase autonomy), mechanisms of erosion (epistemic capture, atrophied judgment, agenda drift, confirmation accumulation, voice homogenisation, peer substitution), signals, good practice, DISSINET-specific risks, peer group as final calibrator ✓

• B.team-ai — AI in collaborative work: the third-party problem; transparent pass-through vs. opaque encapsulation; "Claude said" as diplomatic flag vs. authority citation; full-report-with-review workflow; adoption asymmetry (technical vs. humanist); trust calibration over time; team norms; grounded in Slack+GDocs collaborative culture ✓

• B.lifecycle — AI across the full research project lifecycle; engineering-like vs. interpretive gradient; iterative/non-waterfall model with feedback loop diagram; lifecycle map with links to all subdocs ✓

• B.lifecycle.0.iteration — the foundational principle: fail quickly and let it be documented; cost curve of failure; what AI changes about iteration time; scaffolding the micro-discovery loops (before/during/after); the pre-mortem; documentation infrastructure; cultural dimension; ownership of redirects ✓

• B.lifecycle.1.creativity — research question formation: centroid problem, frontier, Socratic reframe, good practice ✓

• B.lifecycle.2.literature — literature engagement: finding vs. synthesizing vs. interpreting; Zotero; verification; recency ✓

• B.lifecycle.3.datacapture — data collection and processing: preparation, post-collection processing, the micro-discovery loop, what stays human ✓

• B.lifecycle.4.dataanalysis — analysis: execution vs. interpretation (Pepinsky); qualitative coding complications; pattern-finding at scale; analysis as feedback signal generator ✓

• B.lifecycle.5.manuscript — manuscript writing as thinking; diagnostic signals; AI roles that work vs. fragile; proposal writing (even internal) as thinking tool; the 5↔1 feedback loop ✓

• B.epistemics — sycophancy, confirmation loops, tunnel effect, team groupthink: the structural mechanisms behind epistemic distortion; counter-practices including adversarial prompting, multi-agent with different contexts, cross-model checking (Claude + Gemini CLI) ✓

• B.centroid-periphery — center vs. periphery navigation: center-work is legitimate and AI-excellent; periphery (novel questions, gaps) requires a different AI relationship; the tractability drift mechanism; the mode-switching practice ✓

• B.TH.personal.use-cases — nine first-person microcases (dissertation review, course prep, data analysis, software building, project management, this workshop); patterns across cases; the ownership doubt that runs through all of them ✓

• B.TH.institutional.use-cases — six institutional cases (UR department, DISSINET research group): website audit, curriculum guide, thesis archive visualization, data snapshots, five-year synthesis, research opportunity mapping; the periphery task argument; what you gain and what you can lose ✓

• B.adoption-spectrum — five positions on the spectrum of AI-assisted research (occasional querier → regular partner → context-aware collaborator → workflow integrator → agent orchestrator); spectrum as structural integration not just skill; risk distribution across levels; Level 2–3 as the right target for most humanities researchers ✓

• B.time — "Does Claude save time?" — capacity ceiling vs. schedule compression; task floor compression (where time IS genuinely saved); the expansion trap (Parkinson's Law); what good use looks like; right expectations ✓

• B.knowledge-curation — knowledge curation as highest-leverage AI investment: tribal knowledge problem; Wikipedia materialised-view model; individual vs. team curation infrastructure; connection to DISSINET shared interpretive conventions ✓

Recurring themes

• Ad hoc use vs. complex zero-to-product use

• Personalisation: custom instructions, persistent project context

• Iterating over a problem with Claude as thinking partner

• Markdown files as project organisation and memory for Claude

• The "upload dance" problem: why Desktop's file handling frustrates; how Code solves it

Use cases: specific (DISSINET framing) 1. "Here is a paper to read" — summarise, extract arguments, flag gaps ✓ 2. "Here is a dissertation you should review" — structured feedback, section by section ✓ 3. "Here is a draft of my paper" — line editing, argument coherence, register check ✓ 4. "I need to write a grant proposal" — structure, boilerplate, budget narrative ✓ 5. "I need to refine my research problem" — Socratic dialogue, literature gap analysis ✓ 6. "Here is a folder of 40 PDFs from my archive scan" — batch extraction, structured output ✓ (core demo) 7. "Here is my Zotero library" — find what I need, suggest connections, identify gaps ✓ 8. "Help me organise this project" — task breakdown, markdown structure, notes ✓

C. Exploring and condensing

Making summary and synthesis documents over the gathered material. Identifying what is essential vs. nice-to-have for the workshop.

• C.start-here — "Five Things That Make Everything Else Make Sense": 10-minute conceptual orientation for self-directed readers; folder workspace, markdown bridge, CLAUDE.md, Fail quickly (ethics/privacy/ownership paths), adoption spectrum ✓

• C.rules — Ten Simple Rules for AI-Assisted Research (PLoS format): named rule, failure mode, explanation, link; rules 1–4 setup/process, 5–8 epistemic, 9–10 sustainability ✓

• C.philosophy-experience — glossary of the distinctive concepts that run through the project: named framings (execution vs. interpretation, centroid problem, epistemic capture, tractability drift, etc.) with links to primary treatment documents ✓

• C.dangers — map of all AI-as-assistant risks: output quality, epistemic, autonomy, structural/relational; detectability spectrum table; three compound risk combinations; cross-referenced to 12 source documents ✓

• C.leveling-packages — transition guide for the adoption spectrum: four packages (0→1, 1→2, 2→3, 3→4), each with conceptual shift / first experiment / practice; closes with "you don't have to level up" ✓

• C.why — curated one-liner motivations to start using AI and to level up on the spectrum; grouped by benefit type (time/load, thinking quality, capability, autonomy); per-transition reasons; closes with "FOMO doesn't sustain adoption" ✓

• C.tasks — tasks by adoption level (cumulative list from L1 to L4); what AI does vs. what human retains per task; closes with tasks AI is not reliable for ✓

• C.cheatsheet — one-page quick reference: keyboard shortcuts, slash commands, tool decision matrix, privacy quick-check, when-stuck checklist ✓

• C.calibration — honest performance assessment using Pepinsky's execution/interpretation frame; where AI demonstrably helps vs. where it disappoints; signs of good vs. self-deceived use ✓

• C.ethics-compact — three decisions every researcher faces: can I share this data? / do I need to disclose? / am I still the intellectual author? ✓

• C.prompts — prompt gallery: 20 copy-paste-and-adapt prompts across reading, corpus work, writing, project setup, DISSINET-specific ✓

• C.workflows — four end-to-end workflow templates: reading a paper set, grant section writing, archival corpus processing, new project setup ✓

• C.project-history — narrative history of this project written from Claude's perspective: reconstruction problem, research agents, CLAUDE.md moment, the graph emerging from document links ✓

• C.resources — curated reading list for workshop participants: books (Mollick), getting started resources, CLAUDE.md and the .claude/ folder, Claude Code in research practice, humanities/social science perspectives, critical perspectives, qualitative methods, AI as research collaborator ✓

• C.llm-as-reader — the "Claude helps you read / Claude reads for you" spectrum: what changes at each end, vibe research risk, working responsibly at the "reads" end, calibration table by work type, connection to Karpathy pattern and SwarmVault ✓

D. Formulating workshop structure and final materials

Making the workshop structure, slides, hands-on exercises, and participant handouts.

• d.plan.md — presenter's guide: 2.5h agenda (4 blocks), scripted demo prompts, pre-workshop checklist, pacing notes; Block 1 conceptual basics references A.concept.under-the-hood (agent loop + data boundary diagrams) and A4.conceptual-vocabulary ✓

• D.tutorial.setup.md — participant installation guide: Windows native (Git → Node.js → Claude Code → Obsidian), terminal basics, troubleshooting ✓

• D.tutorial.firstproject.md — participant hands-on guide: clone workshop repo + explore; new project + PDF workflow + reading note ✓

• D.tutorial.first-month.md — week-by-week post-workshop integration guide (weeks 1–4): first real task, CLAUDE.md improvement, first batch task, spectrum self-placement; five abandonment patterns and what each signals ✓

• D.handout.md — one-page printed quick reference for participants: 4 terminal commands, 3 starter prompts, CLAUDE.md template, when-things-go-wrong table ✓

• D.tutorials.md — navigation index for the three tutorial documents: numbered progression (setup → first project → first month), time estimates, one-sentence descriptions per step ✓

D1. GitHub Pages site — shareable workshop materials ✓ v1 DONE

Publish the selected workshop materials as a self-contained GitHub Pages site — usable by participants after the workshop without any login or account.

v1 implementation (2026-03-17):

• docs/ folder served via GitHub Pages (no _config.yml needed — just enable Pages → docs/ in repo settings)

• docs/map.html — force-graph WebGL network visualisation, full-viewport, node-click navigates to document page (formerly index.html)

• docs/{slug}.html — one page per document (82 pages), generated from markdown

• docs/_index.html — concept index as browsable page (generated from _index.md; links clickable) ✓

• docs/assets/ — diagram images embedded in document pages (agents, adoption-spectrum, privacy-dataflow, centroid-periphery PNGs) ✓

• docs/network-data.json — 82 nodes, 380 edges extracted from ## Related sections

• docs/term-index.json — 107 terms from _index.md (ready for v2 wiki hover)

• build/build.py — single Python script, run python build/build.py to regenerate

• Node colours by category: A blue, B orange, B.lifecycle amber, C red, E green, meta purple, level distinct

• Home panel: default right-half panel with thematic nav, random quote from C.why, concept index link ✓

• Meta-documents (start, _history, _ownership) visible as purple graph nodes ✓

• Hover tooltip: title + description; click → document page; pan/zoom built in

v1 additions (2026-03-18):

• docs/index.html — new landing page: two-column layout (hero + "What's inside" + "Find your level"), links open documents in map split-screen ✓

• docs/level-0.html through docs/level-4.html — five standalone adoption-spectrum level pages: level nav strip, hero with watermark numeral, recognition checklist, risk card, level-up section from C.leveling-packages ✓

• Level nodes injected into graph (5 nodes, L0→L4 chain, level-2 linked to B.adoption-spectrum) ✓

• "Your level" section in map home panel (first box, colored chips, link to adoption spectrum) ✓

• Lightbox for deck slide illustrations: postMessage-based, covers full viewport across both panels ✓

• B.TH.* files excluded from build (SKIP_FILES); source .md files remain in repo but not published ✓ (restored in session 20 — private server deployment)

• _deck/ — 21 slide images from notebooklm-slides-v2.pdf, named by content; embedded in 20 knowledge documents at thematically appropriate positions ✓

• Level pages cross-referenced to knowledge documents: inline links at concept-level precision; footer links added per page ✓ (extended second round in session 21)

• docs/map.html "Claude for Research" heading linked to landing page ✓

• _github.pages.plan.md — publication plan for GitHub Pages under DISSINET/claude-as-research-assistant; repo renamed, steps 2–3 on hold ✓

• docs/C.media.html — standalone media page: playable NotebookLM podcast (~40 min) + zoomable infographic lightbox; assets served from docs/assets/ ✓; enhanced (session 22) with inline PDF slide deck iframe (620px), section icons, "How This Was Made" 6-step automation box ✓

• Carousel rebuilt: all 21 _deck/ slides included, height doubled, images compressed (PIL), each slide links to target page with #deck scroll-to-image ✓

• Level nodes rendered as diamonds in network graph; LEVEL_LINKS expanded to ~45 edges matching all HTML cross-references ✓

• #home-media strip: 3 pill chips (🎙 Podcast, 📑 Slides, 🗺 Infographic) placed between persona nav and carousel; replaces buried footer link ✓

• C.start-here.html as primary entry point in "Is this useful for me?" home panel nav; C.rules.html as primary in "I want to think carefully" ✓

Multi-book refactor (session 26, 2026-04-04):

• Repo restructured: all content moved into research-augmented/, meta-docs into research-augmented/_meta/, student guide started in student-guide/ ✓

• build/build.py refactored into multi-book build with BOOKS registry; output to docs/research-augmented/ ✓

• build/static/ — static HTML sources (map.html, level-0..4.html) tracked here, copied to book output on build ✓

• build/publish.py — rewritten with rsync-style sync (upload + delete stale remote files) ✓

• docs/.htaccess — 93 redirect rules auto-generated for old root-level URLs → /research-augmented/ ✓

• research-augmented/CLAUDE.md — book-specific CLAUDE.md created ✓

Landing page 3-column layout (session 27, 2026-04-04):

• build/static/index.html — refactored to 3-column at ≥1400px (hero / what's inside / find your level); fixed CSS ordering bug (media queries now after base styles); hero justify-content: flex-start; overflow-x: hidden; levels fade-in animation added; page fits in 1440×900 viewport without scroll ✓

v2 backlog:

• Wiki hover: scan rendered HTML for ~90 index terms → <span> popups from term-index.json

• Guidance panel: Phase C–derived entry paths and thematic clusters

• Client-side search (Lunr.js)

• GitHub Actions auto-build on push

• Czech/English multilingual support (deferred)

E. Mini-books for two audiences

(Deferred — developed after C and D, drawing on selected materials)

Two compact, self-contained guides derived from the workshop material pool. Practical in tone. Good pedagogic segmentation — each section should be usable standalone, not requiring the reader to have read everything before it.

E1. Mini-book for scholars and researchers

Audience: Working researchers, postdocs, junior and senior faculty. People with established research practices who want to integrate AI tools deliberately and critically.

Framing: Not "here is a new toy" but "here is how this changes your existing workflow, and what you need to watch out for."

Structure (draft): 1. The landscape in 10 minutes — Desktop / Cowork / Code, what each is for 2. The one setup that changes everything — CLAUDE.md and project memory 3. Document work — the core use case (PDFs, batch extraction, Zotero) 4. Reading and note-making — where AI helps and where it gets in the way 5. Writing — how to use Claude without losing your voice 6. Critical use — hallucinations, execution vs. interpretation, what not to delegate 7. Reference: useful prompts and configurations for research

Tone: Peer-to-peer. Assumes intelligence and scepticism. Does not oversell.

MUNI guidelines reference: Scan and incorporate relevant Masaryk University (MUNI) guidelines on AI use in academic work — particularly on attribution, data privacy, and academic integrity. These provide the institutional framing that makes the guide usable in a Czech academic context.

E2. Mini-book for students (BC / MA / PhD) — development moved to student-guide/

(Session 26: E2 is now being developed as a separate book in student-guide/. See student-guide/_meta/plan.md for the current development plan and student-guide/_meta/start.md for the document inventory. The outline below is the original draft that seeded the plan.)

Audience: University students at Masaryk University and similar Czech institutions, across three levels.

Central theme: "You need to own the result."

This is the organising principle of the entire book — not a rule imposed from outside, but a practical standard the student applies to themselves:

Can you explain this? Can you defend it? Can you stand behind it?

If yes — you own the result. Whether or not AI helped produce it is secondary. If no — you do not own the result, and submitting it puts you at risk: in seminar, in the thesis defence, in a job interview, in front of a future supervisor.

This framing:

• Is honest rather than moralistic — it is about capability and risk, not virtue

• Explains the MUNI disclosure requirement from the inside out: you cannot disclose what you do not understand

• Scales naturally across levels: the standard of "owning" is higher at PhD than at BC, but the principle is the same

• Connects directly to the CUNI/MUNI principle that "the researcher has full responsibility" — for students, this means: you submitted it, you own it

• Positions AI as a tool that can help or hurt your ownership depending on how you use it

The two failure modes to avoid (structured around the theme): 1. Under-use: Refusing to use AI from principle or fear, while peers who use it well work more effectively — also a form of not owning your workflow 2. Over-delegation: Submitting AI output you cannot explain, defend, or stand behind — the real integrity risk

Framing: Practical guide to using AI tools in academic study — organised by what students actually do at each level, always through the lens of: does this help you own the result, or does it replace your ownership?

Pedagogic segmentation by level:

BC (Bachelor):

• First contact with academic reading and research tools

• What "owning" means at BC: being able to explain any paragraph you submit, answer your teacher's follow-up question, describe what any source actually says

• Core needs: processing assigned readings, taking notes, understanding sources, writing first academic texts

• Focus: Claude Desktop basics, reading workflows, responsible use

• The key question: "If your seminar teacher asks you about this paragraph tomorrow, can you answer?"

• MUNI rules: disclosure required if AI affected content; four methods; ask your instructor first

MA (Master):

• Independent literature research, seminar papers, beginning thesis work

• What "owning" means at MA: being able to defend your literature review, explain your methodological choices, describe the argument of every source you cite

• Core needs: literature review workflows, Zotero integration, structuring longer arguments, feedback on drafts

• Focus: Claude Desktop Projects, Zotero + Claude, writing feedback workflows

• The key question: "Can you defend this in your thesis seminar, or in front of your supervisor?"

• MUNI rules: thesis declaration wording; disclosure in methods section; citation format

PhD:

• Original research, corpus work, publication pipeline, grant writing

• What "owning" means at PhD: being able to describe AI's role in your methods section, stand behind your analysis under peer review, reproduce your results, take responsibility for any bias in AI-assisted coding

• Core needs: batch document processing, data extraction, writing at scale, project memory

• Focus: Claude Code for non-programmers, CLAUDE.md, agentic workflows with supervision, critical limitations for published research

• The key question: "Can you describe this in your methods section and defend it to a reviewer?"

• MUNI/CUNI rules: FAIR principles, publish prompts and coding schemes for qualitative research, document model parameters

Structure per level: Each level section is self-contained. Sections cross-reference upward ("when you reach MA level, see..."). The "own the result" principle is stated at the start and returned to at the end of each level section.

Tone: Direct, peer-to-peer, non-moralistic. Addresses the student as a capable adult making strategic decisions about their own work. Does not lecture. Does not pretend AI is not being used widely.

E — shared tasks

• Scan journal and funder AI policies ✓ → E.journal-funder-policies.md

• Scan MUNI AI guidelines ✓ → E.muni-guidelines.md

• Scan CUNI researcher recommendations ✓ → E.cuni-researcher-recommendations.md

• Key finding: non-binding recommendations only (not in formal SaZŘ regulations)

• Core rule: undisclosed AI use affecting content = treated as plagiarism

• No researcher/publication policy exists at MUNI

• PhD students in grey zone — student rules for submitted work, journal rules for publications

• Approved tools: MS Copilot, Google Gemini (institutional), e-Infra (for sensitive data)

• Claude Code (local) = safe for sensitive data (never leaves the machine)

• Identify shared content — some sections will be the same or nearly the same in both books (e.g. the critical limitations section, the Zotero integration). Write once, reference in both.

• Format decision — PDF? Web (GitHub Pages)? Both? Consider whether the student book should be available in Czech.

E — project assessment and planning

• E.plan.md — development assessment and forward plan (March 2026): what is complete, four content gaps (addressed), five development directions in priority order (E1/E2 mini-books, Czech localisation, maintenance model, site interactivity, workshop variants) ✓

• _gacr.standard.proposal.md — GAČR Standard Project proposal structure reference (for Demo 2; not participant-facing) ✓