an agent helps you write

Optional Week 5 exercises for BIOEE 7600-103

← back to the course page

Three exercises, in order of how much of the writing Claude does: first it reviews your writing, then it writes methods from your code, then it drafts a proposal from last week's review. Start with the first; the other two are there if you want more. Run them before Friday 9 October if you want, or do them in class with us.

1. A friendly reviewer (about 5 minutes)

Give Claude a whole paper or draft, and name one paragraph in it. Claude reads the whole document for context, comments on that paragraph the way a helpful reviewer would, then revises it for clarity without changing what it claims. You get tracked changes as diff.html, and a second check that compares the claims in the two versions. If English is your second language, it can explain each change, in English or another language.

  1. Open Claude Code in a new, empty folder, set to Opus 5.5 (/model to check).
  2. Paste the prompt below with its five lines filled in. For the first line, drag your document into the Claude Code window. PDF, Markdown or plain text work best.

Only use a document you are free to share, all of it: your own, a published paper, or co-authored work your co-authors have agreed to. Never use a manuscript or proposal you are reviewing.

The prompt
# Fill in these five lines, then paste everything into Claude Code

MY DOCUMENT: [drag the whole paper or draft into this window here; PDF, Markdown or plain text work best]
PARAGRAPH TO EDIT: [its first few words, or e.g. "second paragraph of the Discussion"]
KIND OF TEXT: [e.g. "manuscript draft", "published paper", "proposal"] for [venue, e.g. "Evolution", "NSF DEB"]
ENGLISH IS MY: [first language / second language]
EXPLAIN CHANGES IN: [English / another language, e.g. "Spanish"]

---

You are a friendly, careful reviewer helping me make one paragraph clearer. You improve how it says
things, never what it claims. The rest of the document is there so you understand the paragraph.

## Rules

- **Edit only the paragraph I chose.** Use the rest of the document for context: how terms are
  defined, which claims are supported elsewhere, the paper's own vocabulary. If you notice problems
  elsewhere, mention them briefly in `comments.md`; do not fix them.
- **Claims and hedging stay exactly as strong as the original.** "May contribute" must not become
  "drives"; "we show" must not become "we suggest". Do not drop qualifiers, conditions, or caveats
  as wordiness.
- **Add nothing.** No new claims, numbers, citations, or interpretations. Keep technical terms
  unless they are used wrongly, and then flag them instead of silently swapping a near-synonym.
- **Change only what the diagnosis justifies.** Leave sentences that already work. Keep my voice.
- If a change might alter meaning, make it only with a flag saying so, or leave it and comment.
- Do not edit my document. Work only in the current folder.

## Budget

One subagent. The paragraph can be up to about 300 words; the document can be any length.

## Steps

### 1. Diagnose (you)
Read the whole document. Copy the paragraph I chose, word for word, into `original.md`. If you
cannot tell which paragraph I mean, ask me before going on. Write `comments.md`: a short overall
note on the paragraph (what works, the two or three biggest clarity problems), then numbered
comments tied to quoted phrases, then a short "elsewhere in the document" list if you noticed
anything. Diagnose only. Do not rewrite yet.

### 2. Revise (you)
Write `revised.md`, addressing the comments. Mark any change that could shift meaning with
`[CHECK: why]`. If ENGLISH IS MY is "second language", add `explanations.md`: for each change, one
or two sentences in EXPLAIN CHANGES IN on the convention or reason behind it (for example article
use, putting the subject early, one idea per sentence), so it carries over to my next draft.

### 3. Tracked changes
Write a short script that makes `diff.html`: a word-level diff of `original.md` vs `revised.md`,
deletions struck through in red and insertions in green, light background. Tell me to open it in a
browser.

### 4. Meaning-drift check (1 subagent, on Opus)
Give a fresh subagent (`model: "opus"`) only `original.md` and `revised.md`, not the comments and
not the document, so its check does not lean on your reading. It lists every claim in the original
and writes `drift_check.md`, a table of `claim, original wording, revised wording, verdict (same /
stronger / weaker / changed / dropped / added)`. Restore the original wording for every claim
marked stronger, weaker, dropped or added, and update `revised.md` and `diff.html`. Do not restore
claims marked "changed"; list them for me in `comments.md` with the checker's reason, so I decide.

### 5. Finish
Tell me how many changes you made, what the drift check restored, and which "changed" claims I
should look at.

2. Methods from your code (about 5–10 minutes)

Give Claude an analysis script (and its data or a figure, if you like). It writes a methods paragraph or a figure legend from what the code actually does, asks you for anything the files cannot tell it, and a second check ties each statement to a line of code, a data column, or you.

  1. Copy the script and any data or figures into a new, empty folder, and open Claude Code there.
  2. Paste the prompt below with its four lines filled in.

The same sharing rule applies: only code and data you are free to share.

The prompt
# Fill in these four lines, then copy your files into an empty folder and paste everything into Claude Code

ARTIFACTS: [file or folder names in this folder, e.g. "analysis.R and data/plants.csv", "fig2.png", "scripts/"]
WRITE: [one of: "methods paragraph" / "figure legend and one results sentence" / "both"]
WHAT I CAN TELL YOU: [facts not in the files: organism, sites, dates, sample sizes, sequencing platform. Or "nothing; ask me".]
RUN THE CODE: [yes / no. Yes only if it runs in under 2 minutes with the data present.]

---

You are drafting methods or figure text for a paper, using only what the files in this folder
show. A reviewer will check every statement against the code.

## Rules

- **Describe only what the artifacts show.** Every statement must be supported by a line of code,
  a data column, a saved output, or a visible feature of a figure, or else by WHAT I CAN TELL YOU.
- **Do not infer biology from names.** A column called `site` tells you there is a site variable,
  not where the sites are. Dates, locations, taxa, sample sizes and methods of collection come from
  me or are marked `[YOU: ...]`.
- **Defaults are statements too.** If the analysis relies on a function default (contrasts,
  optimizer, link function, number of iterations, distance metric), say which default it is and
  flag that the methods should state it.
- **No unverified numbers.** Software versions come from querying what is installed, not from
  memory. Statistics in a results sentence come only from output you produced or a saved output
  file, never read by eye off a figure unless labelled "approximate, read from figure".
- Do not modify the artifacts. Work only in the current folder.

## Budget

Read at most about 2,000 lines of code. One verification subagent. Run the code only if RUN THE
CODE is yes, and stop it if it takes more than 2 minutes.

## Steps

### 1. Inventory (you)
List each artifact and what it is. Trace the analysis: inputs, transformations, filters, models,
outputs. Note any random step and whether a seed is set. If RUN THE CODE is yes, run it and save the
console output to `run_output.txt`. Record installed versions of R or Python and of the packages
the code calls.

### 2. Ask before writing
List the facts the text needs that neither the files nor WHAT I CAN TELL YOU supply. Ask me all of
them at once, in one numbered list, and wait for my answers. Anything I skip becomes a
`[YOU: ...]` marker.

### 3. Draft (you, on Opus)
Write `draft.md` with the requested text in the register of an ecology journal, followed by
"Things you should state that the code leaves implicit" (defaults, seeds, exclusions).

### 4. Verify (1 subagent, on Opus)
Give a fresh subagent (`model: "opus"`) only `draft.md`, the artifacts, `run_output.txt` if it
exists, and my answers from step 2. It splits the draft into individual statements and writes
`methods_ledger.csv`: `statement, support (file:line, column name, output file, figure panel, or
"author"), status (supported / default, not stated / author-supplied / unsupported)`. Fix or remove
every unsupported statement, once, and log the changes in `draft_log.md`.

### 5. Finish
Tell me the count of statements by status, and in three lines what a reviewer is most likely to
challenge.

3. A proposal from last week’s review (about 10 minutes)

Claude turns the review it wrote last week into the one-page Project Summary of a research proposal. You get claims_ledger.csv, which says where each claim came from, and panel_review.md, an AI panelist’s review.

  1. Find last week’s review. The best file is review_original.html in your Week 4 folder, because its reference list carries the DOIs. review.md or a PDF of the page also works. No review? Choose new topic in the prompt; it does a quick search first.
  2. Open Claude Code in a new, empty folder, set to Opus 5.5.
  3. Paste the prompt below with its four lines filled in. For the first line, drag your review file into the Claude Code window.
  4. When it finishes, it gives you a link to the Summary as an Artifact, a page on claude.ai only you can see.
The prompt
# Fill in these four lines, then paste everything into Claude Code

MY REVIEW: [drag last week's review file into this window here, ideally review_original.html; or write "none"]
STARTING POINT: [one of: "my review" / "new topic: ..." (a quick search builds a small evidence base first)]
PROGRAM: [e.g. "NSF DEB core, standard grant"]
MY IDEA: [a sentence or two on what you would want to test, or "propose it from the review"]

---

You are drafting the one-page Project Summary of a research proposal, grounded in the literature
review I attached. It is a starting point for me to edit, not a submission.

## Rules

- **Prior work comes only from my review.** Every claim about what is known must trace to a
  reference cited in the review, or to a row of `evidence_table.csv` if you build one in step 0.
  No new references, no citing from memory, no adding DOIs the review does not give.
- **Mark what only I can supply** as `[YOU: what is needed]`.
- Copy my review into the current folder as `review_input` (keep its file extension) and do not
  edit it. Work only in the current folder.

## Budget

No literature search unless STARTING POINT is "new topic". One critic subagent. The Summary is at
most one page (about 4,600 characters, NSF's limit).

## Steps

### 0. Evidence base (only if STARTING POINT is "new topic")
Launch one subagent (Agent tool, `model: "sonnet"`) that searches OpenAlex
(`https://api.openalex.org/works?search=...`, rebuilding abstracts from `abstract_inverted_index`;
fall back to Crossref if OpenAlex fails), screens at most 30 abstracts, keeps about 12 papers, and
writes `evidence_table.csv` with columns `doi, year, authors, title, system, study_type, design,
main_result, evidence_strength, read_as`. Check every DOI at Crossref and drop failures.

### 1. Plan (you)
Read my review. Write `review_refs.csv` listing every reference it cites (`ref_id, authors, year,
title, doi`), copying the DOI only where the review gives one. Choose the question and two aims
that follow from a real disagreement or gap in the review and fit MY IDEA. Write them to
`proposal_log.md` with the references and review sections each aim rests on.

### 2. Draft (you, on Opus)
Write `summary.md` under NSF's three headings: **Overview** (question, two aims, approach),
**Intellectual Merit**, **Broader Impacts**.

### 3. Claims ledger
Write `claims_ledger.csv`, one row per sentence that makes a claim: `claim, type (prior work / gap /
hypothesis / approach / feasibility / impact), source (a ref_id from review_refs.csv, "assumption",
or "YOU")`.

### 4. Panelist (1 subagent, on Opus)
Give a fresh subagent (`model: "opus"`) only `summary.md` and my review. It reviews the Summary as
an NSF DEB panelist would: a rating (Excellent to Poor), strengths and weaknesses for Intellectual
Merit and Broader Impacts, and a check of three claims about prior work against what the review
actually says. Save as `panel_review.md`. Revise once, and log what you changed and declined in
`proposal_log.md`.

### 5. Publish it
Make the final Summary a readable page (light background, DOIs linked, `[YOU: ...]` highlighted),
save it as `summary_original.html`, and publish the same page as an Artifact, private to me. Give
me the link. If you cannot publish Artifacts in this session, say so.

### 6. Finish
Tell me the panelist's rating, the ledger counts by source, and in three lines what you are least
confident about.