Turn reports into a paper draft (a worked example)

Written for Olivia — uses the Inhassoro Dugong / wedgefish project as the running example. Useful for anyone else starting their first AI-assisted project from existing materials.

What this page is. A concrete walkthrough of using everything from Lessons 1–7 on a real project end-to-end. Specifically: you’ve got an existing body of work (project reports, data sheets, draft outputs, notes), and you’d like to turn it into something publishable — a paper, a journal note, a polished report, a Conservation Evidence write-up.

For Olivia: the running example throughout is your Inhassoro Dugong / wedgefish project — the final reports are written, the data is there, and there’s genuinely a paper (or two, or three) in it. The steps below substitute cleanly for anyone else with a different starting project.

The lesson is designed so you can muddle through it on your own, asking Claude questions as they come up, without needing Simon or Clare on the call. You won’t get a publishable manuscript in one session — but you’ll have enough structure to make the first hard part (the blank page) disappear. The rest is iteration.

Before you start

You’ll get the most out of this if you’ve already done:

Lesson 2 — Install the software — Claude Desktop, Obsidian, and ideally ChatGPT Plus for voice and Codex.
Lesson 3 — Connect Claude to your notes folder — Claude Code pointing at your vault.
Lesson 4 — Tell Claude about your work — the /onboard interview, so Claude knows your name, your team, your project context, your spelling preferences.

If those three are done, Claude already knows enough about you and your work to be useful from the first prompt below. If you skip them — especially Lesson 4 — you’ll spend a lot more time re-explaining yourself, and the output will be more generic.

Step 1 — Gather your stuff in one folder

Open Obsidian. Make a project folder somewhere in your vault — for the dugong example, that might be 02_MARINE MEGAFAUNA/PROJECTS/Inhassoro Dugongs/ (or wherever fits your vault). The exact location doesn’t matter much; what matters is that everything related to the project ends up in one place.

Inside the folder, drop in:

Existing reports — the final report, any interim reports, donor reports, grant reports. Whatever’s been written up already. PDFs are fine; Claude can read them.
Data sheets — sighting logs, CSV exports from KoBo or wherever, BRUV summaries, biometric measurements. The actual numbers.
Drafts — anything you’ve started writing on this project that didn’t go anywhere. Even rough notes count.
Photos that matter — especially photos that document method (a BRUV deployment, a transect line, the sampling location). Skip the holiday snaps.
Related grant applications — they often have the cleanest articulation of the project rationale and have already been peer-reviewed by the funder, so they’re useful framing material.
Anything tangentially relevant — meeting transcripts where you discussed the project, voice memos you recorded after fieldwork, emails that captured an insight. If you have transcripts from running Lesson 5, those are gold.

Don’t over-think the structure. A flat folder is fine. If you want sub-folders, reports/ / data/ / drafts/ / references/ works. Don’t convert PDFs to markdown yet — Claude can handle PDFs directly, and converting is a chore you don’t need to do up-front.

Tip. While you’re gathering, write down two or three things in plain English in a fresh note called _about-this-project.md: what the project is, why it matters, what you wish you could say publicly about it. Don’t structure it — just type or dictate. This becomes the orientation note Claude reads first.

Step 2 — Tell Claude about the project

Open Claude Code (Desktop → Code tab), make sure it’s pointing at the folder you just built. Now paste this prompt:

I want to start a project on the Inhassoro Dugong work. I've gathered
the relevant materials in this folder — reports, data, drafts, some
related photos and notes. Have a look through everything and tell me
back what you see:

- What the project is about, in your own words.
- What data we've got, and what's already been written up.
- What feels like it could become a paper or a published note.
- Anything that's missing or that would strengthen a writeup.

Take your time. Read the files properly. Ask questions if you're not sure
what something is.

(Substitute “the Inhassoro Dugong work” for whatever your project is.)

Claude will work through the folder, read the reports and data, and come back with a structured summary. This usually takes a minute or two if there’s a lot of material. It might ask you clarifying questions — that’s fine, answer them as they come.

Voice tip. Don’t type long messages like the one above. Press-and-hold the microphone button at the bottom of the Claude Desktop chat, dictate it, release. Ramble — don’t try to structure your answer. Claude reads through the noise just fine. Most of the prompts in this lesson are good candidates for voice.

Step 3 — Pick an angle

Claude’s summary will surface several candidate stories you could tell from the same project. For Inhassoro Dugongs as the example, the candidate angles probably look something like:

Traditional dugong ecology paper — sighting rates, distribution, habitat-use patterns.
Wedgefish BRUV note — a separate species, same project, possibly its own short publication.
Conservation Evidence note on the alternative-livelihoods program — less science-y but very publishable; documents the management intervention.
Methodology paper — how you ran the aerial + community-science combo, useful to other researchers planning similar work.

You don’t have to write all of them. Pick one to focus on first. The easiest first paper is usually the one with the cleanest standalone story — not necessarily the one you care most about. Ask Claude:

Of the angles you flagged, which one has the most complete data set
and the clearest story for a first paper? I want to start with the
easiest one, not the most ambitious one.

Take its recommendation as a starting point. You can override it; you know the data better than it does.

Step 4 — Build the structure together

Once you’ve picked an angle, ask Claude to draft an outline:

Let's focus on the wedgefish BRUV paper. Help me think about the
structure — what sections, what goes in each one. Don't write any
prose yet — just an outline with bullet points under each section.

You’ll get back something like an Introduction / Methods / Results / Discussion outline with bullet points under each. Iterate on the outline before any prose gets written. It’s much faster to fix structure now than to fix it after you’ve drafted 5,000 words.

Iteration looks like:

The introduction should lead with the wedgefish conservation status —
they're Critically Endangered, listed on Appendix I of CITES last year.
Move that bullet to the top. Then bycatch is the main threat — that's
the second paragraph. Save the Mozambique-specific framing for the
third paragraph.

Keep iterating until the outline reads like a paper you’d actually write. Don’t worry about getting it perfect — good enough that the next step (prose) won’t waste effort is the bar.

Step 5 — Draft one paragraph at a time

Once the outline’s locked, ask Claude to draft prose one paragraph at a time, with specific direction:

Write the first paragraph of the introduction. Five sentences.
Open with the global wedgefish conservation context (cite IUCN
Critically Endangered status, the 2024 CITES Appendix I listing).
Second sentence on what makes them vulnerable (slow life history,
inshore habitat use). Third on the data gap — most studies are
Indian Ocean, few in Mozambique. Fourth as transition to MMF's
involvement. End with the paper's specific aim.

Read what comes back. Edit it. Replace whole sentences if they don’t sound right. Move on to the next paragraph.

Simon’s framing (from a recent call): “It’s not necessarily getting me a finished paper — it’s just getting me to what I would have produced faster. But you have to be able to take responsibility for every word in that manuscript.” Same here: AI accelerates the boring scaffolding; you stay in charge of what gets your name on it.

Anti-pattern: don’t ever ask “write the whole paper.” It won’t work — Claude will produce something generic and bland. Always paragraph-level, always with the structural points you want it to hit. The more specific your prompt, the better the prose.

Step 6 — Verify every citation

This is the most important step on the page.

AI sometimes hallucinates citations — it confidently cites a paper that doesn’t exist, or attributes a finding to a paper that says something different. This is the single biggest risk in AI-assisted scientific writing.

Before submitting anything that has your name on it: every citation in the draft must be checked against the actual source. Either:

Open each citation, find the paper (PDF, journal page, or DOI), and confirm the paper actually says what your draft claims it says. Tedious but bulletproof.
Or run the /verify-citations skill (if it’s installed in your Claude Code — see the mmf-claude-code skills list for install instructions). It cross-checks each citation against Semantic Scholar, CrossRef, and OpenAlex and flags fabrications. Faster but not a substitute for reading the actual papers on the key claims.

Either way: assume nothing. If Claude cited it, check it.

Step 7 — Cross-check with a second AI (optional, recommended)

If you’ve got ChatGPT Plus, paste the draft into Codex (OpenAI’s coding/analysis agent) or ChatGPT and ask:

Read this draft paper. Where do you disagree with the author? What's
weak? What would you push back on? What's a reviewer most likely to
flag?

Different AI, different blind spots. You’ll get critique that Claude either missed or wasn’t going to volunteer. Look for the criticisms that have teeth and address them before going to a human reviewer.

This step is optional but high-leverage. The marginal time is small; the marginal quality lift is real.

Step 8 — Take it to a human

When the draft is rolling — outline solid, ~half the paragraphs in shape, citations verified — set up a call with Simon, Chris, or whoever’s the right co-author. The AI’s draft gets you to “something to react to” much faster than a blank page. The human conversation moves it from “draft” to “publishable.”

Useful framing for the call: “Here’s a draft paper. I’ve used AI to get the scaffolding done. I want your eyes on whether the framing is right, whether the analysis is sound, and whether the data supports the claims. Treat this as a co-author review.”

What to expect

First session: feels weird. You’re not sure what to ask. The prompts above are a starting point — copy them, adapt them as you go.
Second session: starts feeling like a back-and-forth. Claude has more context. Your prompts get tighter.
By session four or five: surprised how much faster the structural work is. The blank-page problem is gone. The slow parts are the parts that genuinely need thinking (which is your job, not the AI’s).

If you get stuck

Ask Claude. Most often the unblocker is just talking through what’s confusing. Press the mic, ramble at it, see what comes back. Stupid questions are fine — Claude doesn’t judge.
If Claude is being unhelpful: rephrase. The most common cause of bad output is a vague prompt. “Make this better” is bad; “the second paragraph reads like a list — rewrite it as flowing prose, keep all four facts but make them connect” is good.
If you hit a methodology or stats question: that’s when you bring in a human. Or use Claude to learn the method first (“explain a generalised linear mixed model in plain English, in the context of count data with a site-level random effect”) and then verify the explanation with someone who knows.
If you’re genuinely stuck: Slack Simon a voice message describing what’s stuck. He’ll either answer or point you at someone who can.

What’s next

Once you’ve done this once, the workflow generalises. The same pattern — gather materials → tell Claude about the project → pick an angle → outline together → draft paragraph by paragraph → verify citations → cross-check → human review — applies to any project where you’ve got materials and want a structured output. Donor reports, grant applications, conservation notes, blog posts, conference abstracts, whatever.

Specialised skills that pair well with this workflow, available as on-demand installs in Claude Code (skill source links go to the canonical version on GitHub):

/research — deep three-model literature search for filling reference gaps you didn’t know you had.
/verify-citations — automated citation audit (mentioned in Step 6).
/pdf-to-markdown — convert PDFs in your project folder to readable markdown so Claude can use them more easily.
/red-team — adversarial review of a draft before submission. Three independent models (Claude, Codex, Gemini) tear it apart so you find the weaknesses before a reviewer does.

Each link above goes to the canonical skill source on GitHub — Claude follows that exact source when you invoke the skill. Run /install-skill <name> to install any that aren’t on your machine yet. Ping Simon when you want any of these turned into a dedicated lesson on this site.