agentleFS
shimo4228shimo4228/claude-harness/skills/persona-read-loop/SKILL.md

persona-read-loop

Skill4 starsChanged 33 days agoMITView on GitHub

Have three isolated LLM reader personas read a draft (article, README) in rounds, revise only how it is shown, and count what each revision added. Use when checking whether a draft gets across before the author reads it (ペルソナに読ませて).

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Write each in 1–2 sentences: role, what they already know and use, what they compare against, and their time or budget.

    line 44
  2. Distinctive:

    Keep the same three, on the same models, for every round: changing them makes rounds incomparable.

    line 53
  3. Distinctive:

    When the draft names a feature newer than the reader model, read the feature's primary source (official docs, changelog) for its exact name …

    line 65
  4. Distinctive:

    If an answer has a code fence or prose around the JSON, strip it.

    line 98
  5. Distinctive:

    Read the answers as the preset says, then put each reason in one of two bins.

    line 103
  6. Distinctive:

    Run it after every revision, whatever the preset.

    line 126
  7. Distinctive:

    Stop at the first of:

    line 142
  8. Distinctive:

    No new reason that is fixable in the text (plus the preset's own condition)

    line 144
  9. Distinctive:

    Every remaining reason is a missing fact

    line 145
  10. Distinctive:

    Write the stop reason in one line.

    line 149
  11. Very specific:

    Keep in <work>: both copies of each round, each reader's JSON, the drift outputs, and log.md with the writer's model and each reader's …

    line 155

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

persona-read-loop — freeze, read, sort, revise, stop

Three readers chosen for the target read a frozen draft in isolated processes and answer in JSON. You revise how the draft shows what the author decided, count what each revision added, and stop when no new reason appears. This is a cheap pre-screen, not user research: the answers are material for revision, and the readers' evaluation is never an acceptance condition. Acceptance stays with the author's read-through (and any review the caller runs after this loop). The loop closes on reasons, never on a score.

Paths below start at ${CLAUDE_SKILL_DIR}, the directory holding this SKILL.md; other agents read it as that directory.

Presets

A preset holds what differs by target: the three reader roles, the prompt and its JSON fields, how to read the answers, and any extra stop condition. Everything else is in this file.

targetpresetreaders confirmed by the author
article, essay, post${CLAUDE_SKILL_DIR}/presets/article.mdno — recorded, not waited for
README${CLAUDE_SKILL_DIR}/presets/readme.mdyes, before r0

For another kind of target, write a preset of the same shape next to these.

The loop

<work> is the directory the caller names for this target (a scratch directory otherwise). Round r0 is the draft before any revision from this loop.

1. Pick three readers (once per target)

Pick three readers whose verdicts would split for different reasons, using the preset's roles. Write each in 1–2 sentences: role, what they already know and use, what they compare against, and their time or budget. Make them plausible real readers, not straw men. Give each a short ID (the preset's, or one of your own) and save it as <work>/persona-<ID>.txt in the form "You are <description>. Answer honestly as that person." — it becomes the reader's system prompt.

Give each reader a model by how deeply the role reads: the preset's model column, or for a role the preset does not list, a light model for a skimming reader and a strong one for a reader who judges how far the author thought. Note which reader, if any, runs on the writer's model.

Keep the same three, on the same models, for every round: changing them makes rounds incomparable.

2. Freeze round r<N>

Save two copies:

  • <work>/r<N>.md — the full draft. Drift is counted on this copy, so claims added inside collapsed sections or image descriptions are counted too
  • <work>/r<N>.reader.md — what readers get: the body of every collapsed section (<details>, :::details) removed with its summary or title kept, images replaced by their alt text, front matter dropped except the title. Real readers judge without opening collapsed sections

When the draft names a feature newer than the reader model, read the feature's primary source (official docs, changelog) for its exact name before reading. A reader's "I don't know this term" about it is the model's cutoff, not a real reader's reaction, and is not a reason to revise. A preset may add handling on top of this rule.

3. Read

Once per target, before the first round, check the isolation once for each distinct reader model:

"${CLAUDE_SKILL_DIR}/scripts/read.sh" --probe [model]

Exit 0 (tools 0, MCP servers 0, user skills 0, context NONE) → read. Any other exit → stop and hand the output to the author; CLI updates can change what reaches the reader.

Save the preset's prompt as <work>/prompt.md, then run the three readers in parallel:

for pair in <ID1>:<model1> <ID2>:<model2> <ID3>:<model3>; do
  id=${pair%%:*}; model=${pair#*:}
  "${CLAUDE_SKILL_DIR}/scripts/read.sh" "<work>/persona-$id.txt" "<work>/prompt.md" \
    "<work>/r<N>.reader.md" "$model" > "<work>/r<N>-$id.json" &
done; wait

Each reader is a new process with no tools, none of the author's settings, memory or skills, and none of the writing context (brief, thesis, intended reading). A reader who already holds the answer cannot show that it failed to get across. Revisions rest on what readers missed or misread, not on their praise: self-preference between Claude models remains, strongest for a reader on the writer's model. Without a model argument, read.sh uses PERSONA_READ_MODEL, else sonnet. PERSONA_READ_CMD swaps the CLI; isolation is verified for Claude Code only.

If an answer has a code fence or prose around the JSON, strip it. If it still does not parse, run that reader once more.

4. Sort the reasons

Read the answers as the preset says, then put each reason in one of two bins. When the preset makes only the judgment match a ground for revision, take reasons from shift and missing readers only:

  • Fixable in the text — where readers stopped, order, the entry, where a decision sits, a missing one-sentence reason, a coined term, no example of the output. You fix these. You change how the decision is shown; the decision itself stays as the author made it
  • Missing facts → author — not measured, a premise left unstated, nothing to compare against, cost unknown. These go to the author as a list. Leave them out of the text rather than thinning them with wording

A claim a reader asks for that the sources do not support stays out of the text.

5. Revise, freeze, count the drift

Revise, freeze the result as the next round (step 2), then compare it with the round just read (r<N-1>, the revision is r<N>):

python3 "${CLAUDE_SKILL_DIR}/scripts/drift_count.py" "<work>/r<N-1>.md" "<work>/r<N>.md" \
  [--dossier <evidence file>] > "<work>/r<N>-drift.json"

Run it after every revision, whatever the preset. It lists new numbers, added superlatives and added or removed hedges (Japanese and English terms), and new Latin-script names. Numbers and names in the previous round or the evidence file count as already said.

  • Exit 1 → settle each flagged item and read the next round: take out new numbers and names the sources do not hold, and return added or removed hedges and superlatives to the previous round's wording. A word the author has said stays. The JSON and what you settled go to the author with the final hand-off
  • new_katakana does not affect the exit code; read it and pass any proper nouns to the author

Revision driven by critique drifts toward hedging: in a writing loop where a manager sent drafts back, revised drafts used 53% more hedging words per 1,000 words (5.03 vs 3.30; Loop-Back Authority in LLM Agent Teams, arXiv 2609.14767, §4.2; as-of 2026-10-18).

6. Stop

Stop at the first of:

  • No new reason that is fixable in the text (plus the preset's own condition)
  • Every remaining reason is a missing fact
  • Three revisions (stop after reading r3) — in the same Loop-Back study, judged clarity fell about 0.14 per revision (a correlation, not a measured cause)

Write the stop reason in one line. Hand the author the latest draft with: a table per round of each reader's key answers and reasons, the missing-facts list, and the drift outputs. The author's read-through decides.

Records

Keep in <work>: both copies of each round, each reader's JSON, the drift outputs, and log.md with the writer's model and each reader's model at the top, then one section per round (the sorted reasons with quoted reader sentences, the preset's matching result, and the stop reason).

Limits

  • The three readers are one model family (Claude), so they are not independent samples and can converge
  • Whether simulated readers stall where real readers stall has not been measured (no study found as-of 2026-10-18)
  • The isolation rests on observed CLI behavior (--setting-sources "" is undocumented); the probe is the check

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.