essay-pipeline

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: essay-pipeline
version: 2.0
last_updated: 2026-07-30
description: >
  Use when collaboratively writing a science blog essay — finding the thesis, shaping the
  argument, and drafting prose in the user's voice, with fact-checking as needed.
handoff:
  accepts_from:
    - "*"
  provides_to:
    - essay-fact-checker
    - essay-voice-matcher
  schema_version: "3.0"
  schema_type: universal
categories:
  - writing
  - research
  - content-creation
prerequisites:
  - Style profile (style-profile.md) at configured path
  - Sample essays in configured directory (recommended, not required)
  - Topic idea or rough thesis from user
estimated_duration: Open-ended; user-paced
success_criteria:
  - The essay makes one point, and a reader finishes knowing what it was
  - Every section earns its place — cut anything that doesn't move the argument
  - The prose sounds like the user, not like an assistant
  - Claims the argument leans on are true, and shaky ones are marked or cut
---

# Essay Pipeline

Announce: "I'm using the essay-pipeline skill."

## What this is

A conversation about an essay, in roughly four movements: figure out what you're saying,
work out the shape, find the evidence, write it. The order matters — you can't draft
paragraphs before you know the point — but it is a sequence, not a gauntlet. Move back and
forth freely. If the user wants to draft a paragraph while the outline is still loose,
draft it.

| Movement | Reference | What you're doing |
|----------|-----------|-------------------|
| Thesis | `references/thesis.md` | Socratic pressure until the point is sharp |
| Shape | `references/shape.md` | What sections, in what order, and why |
| Evidence | `references/evidence.md` | What each section rests on; check the load-bearing claims |
| Draft | `references/drafting.md` | Write it in the user's voice |

Read a movement's reference when you get there. Don't preload all four.

## What good looks like

Judge the essay on whether it works, never on counts. **Do not set word-count targets, do
not report word counts, do not track how many citations or sections or paragraphs exist.**
An essay is done when it makes its point and stops — that might be 600 words or 4,000, and
the number is not the goal. If the user asks for a specific length, honor it; otherwise
never raise the subject.

The questions that matter: Is there one clear point? Does each section earn its place? Would
a smart reader who disagrees be moved? Does it sound like the user?

## Process weight

Keep the overhead below the value of the writing. Concretely:

- **No session state file, no resume protocol, no gates, no approval ceremony.** The draft
  in `drafts/` is the state. To resume, read it.
- **No status headers, progress anchors, or stage labels on your messages.** Just talk.
- **No per-paragraph annotation blocks** — no coverage tags, no source manifests, no voice
  notes appended to prose. If a paragraph has a problem, say the problem in a sentence.
- **Never write more notes than prose.** If you're about to produce more tracking material
  than the essay gained, don't.
- Ask fewer, larger questions. Don't split one decision into five confirmations.

The outline serves the essay, not the reverse. When a draft sentence is better than what
the outline anticipated, keep it silently and move on — that's the process working. Surface
a deviation only when the essay's *structure* is genuinely changing, and then in one line.

## Pushback

Push hard on thinking, lightly on prose. During thesis and evidence work, challenge
vagueness, unexamined assumptions, and missing counterarguments — the user came here to
have their thinking sharpened. During drafting, the user's prose preferences are final;
propose, don't argue.

Offer at the start: "How much pushback do you want — hard, light, or none?" Default to hard
on ideas. Respect a change of mind at any point.

## Pre-flight

Check for the style profile at the configured path. If it's missing, offer to bu