Skill-Details

essay-pipeline

Collaborative essay-writing pipeline covering thesis, structure, evidence, and drafting.

ÜbereinstimmungDirektGeprüft für verfassen von essays
Quelledangeles/claudeExterne Quelle
Gemeldete Installationen17Nur Popularitätssignal

Vor Nutzung prüfen

Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.

Gespeicherte Quellvorschau

SKILL.md

Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.

---
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
Vollständige Quelle auf GitHub lesen (öffnet externe Seite)
Kontext

Verwandte Arbeit