Maintainer of this skill?
by lucasbabur
A Claude Code skill that makes a model write an essay the slow way, with a script checking every step.
# Add to your Claude Code skills
git clone https://github.com/lucasbabur/jp-essaySee how jp-essay compares with popular alternatives.
jp-essay is an open-source ai agents skill for AI coding assistants such as Claude Code, Codex CLI, and ChatGPT, built by lucasbabur. A Claude Code skill that makes a model write an essay the slow way, with a script checking every step. It has 51 GitHub stars.
jp-essay's catalog security scan is still queued. You can run an instant dependency and prompt-injection check now with the "Scan for vulnerabilities" button above.
Clone the repository with "git clone https://github.com/lucasbabur/jp-essay" and add it to your Claude Code skills directory (see the Installation section above). jp-essay ships a SKILL.md manifest, so compatible agents can discover and load it automatically.
jp-essay is primarily written in Python. It is open-source under lucasbabur on GitHub, so you can review or fork the full source.
Yes. SkillsLLM lists many other AI Agents skills you can browse and compare side by side. Open the AI Agents category from the badge at the top of this page, or use the Related Skills and comparison links further down to weigh jp-essay against similar tools.
No comments yet. Be the first to share your thoughts!
Available after the catalog security scan passes.
⚠️ Third-Party Software Notice
This skill is third-party open-source software developed and hosted independently on GitHub. SkillsLLM is an informational directory and does not control or maintain the underlying repository.
Any security checks, ratings, or warnings displayed by SkillsLLM are automated and limited in scope. They do not constitute a security certification or guarantee that the software is safe, error-free, or free from malicious code, vulnerabilities, compromised dependencies, or prompt-injection risks.
Review the source code, permissions, dependencies, and configuration before installing or running any third-party skill. Use is at your own risk. To the maximum extent permitted by applicable law, SkillsLLM is not liable for losses arising from third-party software.
The deep catalog scan for this skill is still queued. Run an instant dependency check now instead.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.A Claude Code skill that runs Jordan Peterson's essay process, adapted to how models write.
Question, reading list, outline, bad draft, outline from memory, reorder, rewrite, ask again.
Peterson's writing guide is built for students, whose problem is skipping the work: no question, no reading, no outline, one draft. A model has the opposite problem. It does every step fluently and still produces generic prose: no claim worth arguing, no specifics, inflated words, hedged verdicts and an ending that summarizes. jp-essay keeps Peterson's steps and aims each one at the model's failure. A script checks every step, so the model can't skip one and say it's done, and no model grades the prose, because models asked to judge writing barely beat chance and reward overwriting.
Not affiliated with Jordan Peterson.
jp-essayis an independent project. Jordan B. Peterson has not reviewed or endorsed it. It is an iteration of the method in his writing guide, adapted for AI agents.
You answer one short form at the start. After that the skill runs on its own until the essay is finished.
| # | Peterson's step | How the model runs it | Why it changed |
|---|---|---|---|
| 1 | Question | One question a reader could answer two ways, plus who the reader is. You confirm it. | The reader decides what to explain, which kills glossary clutter. |
| 2 | Reading list | A research subagent gathers facts, scenes, numbers and verbatim quotes, questioning from a skeptic's, a newcomer's and an expert's point of view. Your own records count for essays about you. | Specifics are the cure for genericness. |
| 3 | Outline | A thesis that answers the reader's own question (what to do, not what the studies found), a carrier (the person or case the reader follows) and a puzzle the ending answers, then one sentence per paragraph. A critic attacks it. | Peterson's ten per thousand words is the centre, not a quota. |
| 4 | Bad draft | Written straight through by one author in a smart friend's voice, carried by the case, 15% long, with at most one named study per paragraph and the figures that make each claim concrete; extra detail goes to short footnotes. | No sentence quotas per paragraph: they make a model write choppy sentences. The study budget keeps a well-researched essay from reading like a literature review. |
| 5 | Outline from memory | A fresh reader reads the draft once and outlines it from memory, and says where it would have stopped reading by choice. | A model can't forget its own draft, so someone else remembers. Understanding a paragraph isn't the same as wanting to read the next one. |
| 6 | Reorder | Recall and outline compared; a new outline; paragraphs, then sentences, reordered and rebuilt on it. | Structure is fixed before sentences, so no polish is spent on paragraphs that move or vanish. |
| 7 | Rewrite sentences | An editor marks flawed spans at four levels of resolution (word, sentence, paragraph, essay). Each gets three genuinely different versions, or a reason it stands. | Three versions of every sentence makes a model change good sentences; three versions of the flawed ones doesn't. |
| 8 | Fact-check | A fact-checker marks every claim supported, fixed or cut against the notes, and changes nothing else. | Easy prose makes claims feel truer, so accuracy gets its own pass and never restyles. Not in Peterson. |
| 9 | Can it be better? | A second cold read. Done when its recall matches the outline and the reader would have kept reading. | One round: every further round of self-revision drifts from the essay's intent. |
You need Claude Code and uv. The checker declares its own Python dependencies.
npx jp-essay@latest
That installs both /jp-essay and /jp-essay-scientific into ~/.claude/skills. Start a new Claude Code session and they're there. To update later, run npx jp-essay@latest --force. npx jp-essay doctor checks that Claude Code and uv are installed.
To track the repo instead, clone it:
git clone https://github.com/lucasbabur/jp-essay ~/.claude/skills/jp-essay && ~/.claude/skills/jp-essay/install.sh
Update a clone with git -C ~/.claude/skills/jp-essay pull.
/jp-essay Why do we procrastinate on things we care about? 1200 en
/jp-essay <question or topic> [word count] [language]
en or pt. The default is the language you asked in./jp-essay-scientific runs the same process for an academic reader. Sources must be published works, drafts mark borrowed claims with [@id], and the essay ends with in-text citations and a reference list in your style (APA by default, ABNT and others on request).
/jp-essay-scientific What made dinosaurs dominate the land? 1500 en APA
Each essay gets its own folder under ~/Documents/essays/<slug>/:
what-made-dinosaurs-dominate-land/
├── question.md # question, reader, length, language (+ style if scientific)
├── sources.md # material: facts, scenes, numbers, verbatim quotes
├── research.md # three readers' questions, the strongest objection, gaps
├── outline.md # the thesis, then one claim per paragraph
├── outline-review.md # APPROVED, or numbered objections
├── draft.md # the bad draft
├── reader.md # a cold reader's outline from memory, and what it took away
├── outline-2.md # the outline the essay follows after the recall
├── draft-2.md # the draft rebuilt and reordered on it
├── edits.md # flawed spans, by level of resolution
├── rewrites.md # three versions of each flawed span, or why it stands
├── facts.md # every claim: supported, fixed or cut
├── reader-2.md # the last cold read
└── final.md # the finished essay ✦
Do We Sleep to Wash the Brain? came out of one unedited run with a 500-word ceiling. It follows the reader through the morning after an all-nighter, across a 2013 study, a 2024 study that contradicts it, a sleep-deprivation experiment in Oslo and a 2025 twist. The fact-check covered 32 claims and fixed one. Read it on the website.
check.py checks only what a script can see. A step counts as done when its gate prints PASS:
~/.claude/skills/jp-essay/check.py <gate> <essay-dir>
| Gate | Checks |
|---|---|
question |
Question, reader, length ≥ 500 and language present |
sources |
At least three sources, notes on each, every link fetched or local file found |
outline |
A thesis sentence; one point per 80 to 250 words; every cited id exists |
draft |
Length up to 15% over; no headings; mechanical tells |
recall |
One recall sentence per paragraph, in the reader's own words; all eight report sections |
outline2 |
The new outline is well formed and draft-2.md has one paragraph per point |
rewrite |
One block per flawed span; three distinct versions or a reason; every choice reaches final.md |
facts |
Every claim in the fact-check is supported (with a source id), fixed or cut, and supported claims are in final.md |
final |
Title; length between 90% of the target and the target; quotes verbatim from the notes; mechanical tells; citations in scientific mode |
The mechanical tells are AI vocabulary, filler, stock openers, "serves as", "not X but Y", dashes used as punctuation, duplicated sentences, three sentences in a row with the same opening, and a summary closing paragraph. Quoted source text is exempt. Warnings flag paragraphs with more than five figures, sentences over 40 words, staged run-ups ("And the result?"), paragraph-ending fragments, curly quotes and heavy use of parentheses.
uv run --with pytest==8.3.4 --with pysbd==0.3.4 --with httpx==0.28.1 pytest -q test_check.py
npm test # the npx installer
Publishing a GitHub release publishes the package to npm (.github/workflows/publish.yml).
The website, jpessay.com, is landing/, deployed on Vercel. Preview it with python3 -m http.server -d landing 8774 --bind 127.0.0.1.
Clarity traffic attribution uses explicit UTMs first, then the referring domain, and retains the entry source across internal pages for 30 minutes of inactivity. Filter by the native UTM Source/Medium/Campaign fields or the custom tags traffic_source, `tr