Jp Essay

Write an essay answering $ARGUMENTS by running Jordan Peterson's essay process, step by step. Step 1 is the only time you ask the user anything; after it, run to the end and send the finished essay.

Peterson wrote his guide for students, whose problem is that they skip the work: no question, no reading, no outline, one draft. A model has the opposite problem. It does every step fluently and produces prose that is generic: no claim worth arguing, no specifics, inflated words, hedged verdicts and an ending that summarizes. So the steps stay and their order mostly stays, but each one is aimed at the model's failure. Three of Peterson's mechanics change. A model cannot forget its own draft, so the outline from memory comes from a fresh reader. Rewriting every sentence three ways makes a model change good sentences for the sake of change, so the three versions go to the spans an editor marks as flawed. And polishing sentences in paragraphs that later move or vanish is wasted, so structure is fixed before sentences. Two rules hold throughout. Production and editing stay separate: the draft is written straight through, and editing starts once it is complete. And no model grades the prose, because models asked to judge writing barely beat chance and reward overwriting. Readers report what happened to them, editors point at spans, and you decide.

Blind tests against plain Claude exposed a second failure: run as pure rigour, these steps turn out a dense, noun-heavy brief that careful readers enjoy less. Reading research points the same way: readers keep going when the prose is easy, carried by a case, and holding an open question; a queue of studies and caveats loses them, while concrete figures and a plain verdict at the evidence's strength keep them. So pleasure and accuracy are kept apart. The draft is written for the reader, around one case and one open puzzle. A separate fact-check guards accuracy and never touches style.

Every step ends on a gate: ~/.claude/skills/jp-essay/check.py <gate> <dir>, run as the file itself so uv supplies its dependencies (tell subagents this too). The gates check what a script can see: format, length, links, verbatim quotes, mechanical AI tells and the paperwork of each step. A step is done when its gate prints PASS; on FAIL, fix each listed failure and run it again. Treat a WARN as a question to answer, not an order. Give each subagent exactly the files its step names.

Steps

1. Question. An essay answers a question, so rewrite the request as one question a reader could answer two ways. Settle the reader (who they are and what they already know; this decides what the essay explains), the length (default 1,000 words, at least 500; it is a ceiling: the final essay lands between 90% of the target and the target, never over) and the language (en or pt, default: the request's). Ask all four in one AskUserQuestion call, each with your default as the recommended option, and the question with up to three sharper alternatives. Then create ~/Documents/essays/<slug>/ (slug: at most six words of the question, kebab case) and write question.md. Gate: question.

2. Reading list. Peterson's reading list exists so the writer has something to say; for a model, it is the cure for genericness. Dispatch a research subagent (model: "sonnet") with question.md and this brief: find the facts, numbers, named cases, scenes and quotable lines that bear on the question; question it from three readers (one who doubts the likely answer, one new to the subject, one who knows it well) and find what each would need; record the strongest objection to the likely answer and what answers it. Prefer primary sources and words worth quoting. When the essay is about the user or their work, their own records are the best material: read the files they point to, or the conversation, and file them as sources with a local path or conversation as the link, copying their words verbatim into the notes. Use as many sources as the question needs, at least three. Record a missing fact as missing; the essay works around a gap and never fills it. Output: sources.md, and research.md holding the three readers' questions, the strongest objection with its answer, and the missing facts. Gate: sources.

3. Outline. Answer the question the reader asked, in the terms they asked it, in one sentence they would not already believe or would argue with, as strong as the material allows and no stronger: the thesis. When the question asks what to do (should I, is it worth, does it help), the thesis says what to do and when; the research is evidence for that answer, never the subject of the essay, so a thesis about what the studies tested or found is answering the wrong question. Then name the carrier: the person or case the reader follows from the first paragraph to the last, a real case from the notes or an imagined one plainly framed as imagined, whose situation is the question. Then the puzzle: the gap the opening sets against what the reader already believes, answered only in the final paragraph. Then write Peterson's outline, one sentence per paragraph, each a claim that follows from the one before and ends with the ids of the sources whose material carries it. Peterson asks for ten sentences per thousand words; treat that as the centre and let the material move it. Open on the carrier and the puzzle; a study enters as evidence for a claim, never as the opening. Every point either moves the carrier's story or argues the thesis, and an anecdote that carries no claim is cut, because an interesting irrelevant detail raises interest and lowers understanding. End on the answer, what this reader should do or believe and when, at the strength the evidence allows, and give the strongest objection its own sentence. Hold each paragraph to at most one named study: an essay is not a literature review, and a reader can follow one study per paragraph but not a queue of them. Output: outline.md. Gate: outline. Then dispatch a fresh critic (model: "sonnet") with question.md, sources.md and outline.md. It answers six questions: does the thesis answer the reader's own question, telling them what to do or believe, rather than reporting what the research found; would the reader find the thesis worth an essay; does the carrier carry the argument or only decorate it, and is the puzzle answered at the end; where does a sentence fail to follow from the one before; which sentence is obvious or padding; which claim do the notes not support. It writes outline-review.md: first line APPROVED or REVISE, then one numbered objection per line. Fix every objection and re-run the gate. Review once more only when the critic rejected the thesis itself.

4. Bad draft. Peterson's bad draft: write fast, straight through, one paragraph per outline sentence, and leave the editing for later. Write draft.md yourself in one pass from outline.md, sources.md and style.md; you hold the argument and the material, and one author keeps one voice. Peterson's ten-to-fifteen-sentence paragraphs are dropped, because a model filling a sentence quota writes choppy sentences; let each paragraph run as long as its claim needs. Write it the way a smart friend would tell it over coffee: the carrier on stage in the first paragraph and back whenever the argument turns, sentence length following the thought, long where it runs and short where it lands, plain everyday words, nothing explained that this reader can infer, and the puzzle kept open, with no verdict announced, until the end. Keep to the study budget: at most one named study per paragraph, and give the figures that make each claim concrete and checkable, as frequencies ("16 in 1,000") where they fit; state findings plainly, with one specific hedge where the evidence is really in doubt, never stacked qualifiers. A number the reader would not miss stays in the notes, or, when a curious reader would want to check it, goes in a footnote ([^1] in the text, [^1]: … at the end), kept short. Like Peterson, overshoot so editing has room to cut: land between the target and 15% over. Gate: draft.

5. Outline from memory. Peterson puts the draft away and outlines it from memory, because what you remember is what the essay actually says. You cannot forget your own draft, so a fresh reader does the remembering. Dispatch a cold reader (model: "sonnet") with only draft.md and the Reader: line. It reads the draft once, as that reader, then writes reader.md without looking back: under ## Recall, one sentence per paragraph saying what that paragraph argued, in its own words; under ## Claim, the essay's claim in one sentence; under ## Lost, the paragraph where it lost the thread, and why; under ## Stop, the paragraph where it would have stopped reading by choice if nobody had asked it to finish, and why, or Nowhere; under ## Unclear, every term or step it could not follow; under ## Enjoyed, the passage it enjoyed most, or Nothing; under ## Remember, the sentence it will remember; under ## Doubt, the claim it believed least. Gate: recall.

6. New outline and reorder. Compare the recall with outline.md sentence by sentence. Where they match, the paragraph landed. Where the recall says something else, or something vaguer, the paragraph failed to make its point; where the recall phrases a point better than your outline, take its phrasing. Write outline-2.md, the outline the essay should follow now. Then rebuild the draft on it as Peterson does: reorder the paragraphs, then the sentences inside each, until each follows from the one before; rewrite each paragraph whose point did not land; treat the ## Stop paragraph like a lost one, since a reader who leaves never reaches the argument; cut what the reader skipped; explain what the reader could not follow, the first time it appears, and only that. Take every added fact from the notes. Output: draft-2.md. Gate: outline2.

7. Rewrite sentences. Peterson's sentence work, aimed where it pays. Dispatch an editor (inheriting your model) with draft-2.md, sources.md, question.md, style.md and tells.md. It reads at Peterson's levels of resolution, word, sentence, paragraph and essay, and marks flawed spans, at most 25, strongest first, each with its level and category from tells.md, a proposed replacement, DELETE or FOOTNOTE (move the span to a footnote), and the gain. It also lists every claim the notes do not support. Output: edits.md. Then, for each entry, write a block in rewrites.md: either at least three genuinely different versions of the span (a new structure or a new idea, not new punctuation; the editor's proposal, DELETE and FOOTNOTE may be among them) and the one you chose, or Rejected: with the reason the span is fine as it is. Fix or cut every unsupported claim. Apply the chosen versions, then reread every sentence a change touched, since a span replaced in isolation can break the words around it. Add one # title of at most eight words that names the reader's question or its answer, never the research (not "What One Trial Found"), and write final.md. Gate: rewrite, then final.

8. Fact-check. Easy prose makes claims feel truer than they are, so accuracy gets its own pass, kept apart from style. Dispatch a fact-checker (model: "sonnet") with final.md and sources.md only. It lists every factual claim in the essay, each number, name, study result, quote and causal claim, and checks it against the notes. Each gets supported with its source id, fixed with the corrected wording and its source id, or cut. It changes nothing else: no restyling, no added hedges, no new facts. Output: facts.md; apply its fixes and cuts to final.md. A cut can leave the essay under 90% of the target; restore length only from the notes. Gate: facts, then final. From here on never re-run gate rewrite: the fact-check may have changed the spans it matches.

9. Can it be better? Peterson's last step asks the question again. Dispatch a fresh cold reader with only final.md and the Reader: line, under the step 5 brief, writing reader-2.md. When its recall matches outline-2.md and nothing in ## Lost, ## Stop or ## Unclear names a real problem, the essay is done. Otherwise fix what it names, take every new fact from the notes, and re-run gate final. Stop there: every further round of self-revision accepts fewer changes and drifts further from what the essay meant.

Send the user final.md's path, its word count, the sources used, what the fact-check fixed or cut, anything the material lacked that the essay had to work around, and what the last reader still doubted.

Reference

File formats.

• question.md: four lines, Question: …?, Reader: <who, and what they already know>, Words: <n>, Language: en|pt.
• sources.md: one ## <id> heading per source (short kebab case, e.g. duhigg-2012), then Link: <url, DOI, local path or conversation> and Notes: on its own line, followed by the source's facts, scenes, numbers and verbatim quotes.
• outline.md, outline-2.md: Thesis: <one sentence>, a blank line, then 1. <claim>. [id, id], one per paragraph.
• outline.md, outline-2.md also carry Carrier: <who or what the reader follows> and Puzzle: <the gap the opening sets> lines after the thesis.
• reader.md, reader-2.md: the eight ## sections of step 5, with the recall as a numbered list.
• facts.md: numbered entries, each with Claim: "<text as it stands in final.md, or as it stood if cut>", Verdict: supported|fixed|cut and, unless cut, Source: <id>. Use plain straight quotes, never backslash escapes.
• edits.md: numbered entries, each with Span: "<exact text>", Category: <level>, <category>, Replacement: <text, DELETE or FOOTNOTE> and Gain: <clause>, then a ## Unsupported claims section.
• rewrites.md: one ### <n> block per edits.md entry, holding Span: "<exact text>", then either - v1: …, - v2: …, - v3: … (more if written) and Chosen: <text, DELETE or FOOTNOTE>, or Rejected: <reason>.
• draft.md, draft-2.md, final.md: paragraphs separated by one blank line, no headings in the body, straight quotes. Optional footnotes go after the last paragraph as [^n]: … lines, each marked once in the text; they do not count toward the length and together stay under a fifth of it. Quotation marks hold only words copied verbatim from a source's notes.