rl-content-pipeline

Files (1)

• SKILL.md

SKILL.md (first lines)

# Content Pipeline — Structured 10-Step Writing Process

An orchestrator, not another generator. This skill owns **sequencing**
for long-form or high-stakes pieces; it borrows every actual writing rule from
the skills that already have them:

- **your content-generation skill** / **your author-voice skill, if you have one** — generation, voice. "Your author-voice skill" resolves to an actual installed skill if you have one, or to `VOICE-PROFILE.md` at the repo root directly (produced by `rl-voice-discovery`) if that's what exists instead — check for the file before concluding there's no voice reference at all.
- **rl-writing-craft** — structure, grounding (Grounding Rules), line edit, anti-AI audit, copyedit. Always present — this is the one dependency that isn't optional.
- **rl-review-panel** — the blind multi-lens panel pass in step 6. Bundled with this suite.
- **an optional closing polish skill, if you have one** (e.g. ann-handley-voice) — a final voice/readability pass on top of rl-writing-craft's floor. Not required — skip this if you don't have one.

This skill assumes a lane architecture — a router/generator skill, a craft
skill, a polish skill — with the lane boundaries as listed above. If your
content-generation skill documents its own orchestration rules, defer to
those wherever the boundaries seem unclear.

If you find yourself restating a rule those skills already own, stop — invoke
the skill instead of re-deriving its logic here.

**No content-generation or author-voice skill installed? This still works.**
Draft directly from the brief and outline (steps 3-4) at step 5, using
`rl-writing-craft`'s Grounding Rules as the floor — same as `rl-writing-craft`
itself works standalone with no author-voice skill present. What you lose
without a dedicated generation/voice skill is a tailored register — the draft
will read in a competent, neutral voice rather than *your* specific voice.
What you don't lose is the process: interview, brief, outline, adversarial
review, and the approval gate all run exactly the same either way. Building a
content-generation or author-voice skill later is worth doing for voice
quality, not for this pipeline to function. If you have real writing samples
(or none, and want the interview path), `rl-voice-discovery` builds that
starting profile — see `VOICE-PROFILE.md` at the repo root, which this skill
already checks for wherever it says "your author-voice skill."

## When to use this vs. the short pipeline

Two independent triggers, either one is enough — length is not the real
criterion, cost-of-being-wrong is:

- **Long-form**, where a wrong structural call is expensive to fix after the
  words are already written: blog posts, whitepapers, essays, case studies,
  thought-leadership pieces.
- **High-stakes, regardless of length** — a 150-word statement carrying the
  company's name, a short email where the wrong claim damages a
  relationship, an announcement whose bad framing can't be retracted once
  it's out. The interview, brief, and adversarial review steps catch exactly
  the mistakes that are cheap to fix here and expensive to fix after it's
  sent.

For a LinkedIn post, a routine email, or social copy that's genuinely
low-stakes — the kind where a bad opening line costs you nothing but a
slightly weaker post — go straight to your content-generation or author-voice
skill. Running all 10 steps there is pure
overhead. The overhead isn't earned by word count; it's earned by what a
mistake would cost.

## Why 10 steps, not one draft

Each step exists to catch a specific, well-documented failure mode:

- Drafting before the goal and audience are pinned down produces content that's
  fluent but aimless.
- Skipping the interview means the draft ships without the specifics —
  first-hand examples, a real opinion, a concrete number — that separate
  writing worth reading from generic AI output. Expert input arriving *after*
  a draft is already structured turns into rework, not refinement.
- Drafting without an approved outline means restructuring after the words are
  already written — the most expensive place to catch a shape problem.
- Reviewing "does this sound okay" instead of "does this hit the brief"
  produces polish without progress. A critique needs to name what's missing
  and where, or the revision has nothing to aim at.
- Skipping the writing suite ships something that reads competent but
  generic — uniform sentence rhythm, hedge-everything phrasing, no point of
  view. That's the exact signature readers now flag as AI-written.
- Treating a finished draft as a finished *deliverable* is how the wrong thing
  gets published. Nothing here is done until step 10 says so.

## The 10 Steps

### 1. Define topic, angle, goal

Pin down: topic, target reader, the angle/thesis (what position is this piece
taking, not just what it's about), the goal (educate, convert, thought
leadership, internal alignment), which venture or publication this is for, and
a rough length target. Infer whatever's already given in the request; ask only
what's genuinely missing — one consolidated question, not a checklist.

If the topic came from `rl-topic-scout`, it already carries this from the
shortlist. Otherwise, check `AUTHOR-CONTEXT.md` at the repo root for who this
piece is for and why it's worth writing at all — same file `rl-topic-scout`
reads, kept consistent so "who I write for" doesn't drift between the two
skills. If it's still the unfilled template, `rl-context-discovery` builds it
properly (evidence first, then a guided interview) rather than a one-off
question here.

### 2. Interview the SME/author

Adaptive, based on who the expertise belongs to:

- **The writer is the SME** (most of their own ventures/projects) — a short,
  pointed interview. Ask 2-4 open-ended questions aimed at surfacing the
  specifics a draft would otherwise invent or skip: a real example, a number,
  a position you'd defend, something that didn't work. Don't ask what's already
  answered by step 1.
- **A named third party is the SME** (a client, a guest expert, a partner) —
  a fuller interview. Ask open-ended questions so they can surface
  things you wouldn't have thought to ask about, and explicitly ask them to
  quantify or define anything they state in vague or abstract terms. Record
  what they say rather than paraphrasing from memory.
- **A voice memo, dictated stream-of-consciousness, or existing meeting
  transcript** (e.g. a Granola recording) is a valid interview answer in its
  own right — often lower-friction and more specific than typed answers,
  since talking through an idea surfaces the real example or the actual
  number faster than composing it in writing. If one already exists for this
  topic, use it directly as raw material instead of asking the person to
  re-type answers to questions it already answers.

In every case, this step's output is raw material — quotes, numbers, opinions,
examples — not prose. That material is what step 5 draws on instead of
inventing connective filler.

From reventurelabs/rl-content-os, MIT.

More from reventurelabs/rl-content-os