# Copy Longform

> Copy Longform

- Skill: `risukisu/copy-longform` (Agent Skill)
- Install (CLI): `npx skillmds@latest add risukisu/copy-longform`
- Raw SKILL.md: https://api.skillmd.com/api/skills/risukisu/copy-longform/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: risukisu (https://skillmd.com/u/risukisu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/risukisu/copy-longform

---


# Copy Longform

A workflow skill for working through a defined document with structured feedback. Produces replacement copy, new paragraphs, reframed sections, and fresh prose where needed, always in context of an existing source document, a defined voice ruleset, and locked decisions.

A single edit-list file doubles as the tracker, so progress survives across sessions.

The skill assumes the structure already exists: a document, sections, defined slots where prose belongs, and feedback or direction guiding what changes. It does not start from raw notes or fuzzy ideas where the shape has not been decided.

## When this skill applies

Trigger on any of:
- "/copy-longform" or "/copyedit"
- "Help me edit this [ebook/report/whitepaper/long post]"
- "Run an edit pass on..."
- "Copyedit this for me"
- "Polish pass"
- "Strip the AI tells from..."
- "Anti-AI scrub on..."
- User pastes a long doc and asks for systematic editing
- User points at a file and asks to walk through it

Do NOT trigger when there is no source document or no defined structure to work within. The skill needs a document, sections, or slots where the prose belongs.

## Step 1 — Intake (always ask, never skip)

Even if context appears pre-loaded, ask. The user's own words shape the workflow. Ask in one batch:

1. **What's the source?** (file path, paste, or URL — load it before suggesting changes)
2. **What is it?** (ebook, report, whitepaper, blog post, deck, internal memo) — voice and stakes differ
3. **Audience and stakes.** Who reads it, what does success look like
4. **Voice template.** Is there existing material with the right voice you want to match? (other chapters, prior posts, a brand voice doc)
5. **SME / reviewer comments.** Any feedback from subject-matter experts to fold in?
6. **Anonymization rules.** Any names, clients, products that must be anonymized vs. named?
7. **Locked decisions.** Anything already decided that I should not relitigate (titles, structure, terminology choices)?
8. **Cadence.** Page-by-page (slow, granular), section/chapter (faster, more in your head), or "one big edit list, no walkthrough" (fastest, less interactive)?
9. **Where will edits be applied?** (Google Docs, Word, Markdown file, IDE) — affects how I present diffs

If the user has not done a voice rule conversation before, also ask:
10. **Voice rule preferences.** Default rules from this skill apply (see "Voice rules" below). Anything to add or override?

## Step 2 — Load grounding material

Before producing any edits, load:
- The full source text. For PDFs, use `pypdf` extraction to a staging file. For URLs, use the `defuddle` skill. For Notion/Google Docs, ask the user to export or paste.
- Voice template references (other chapters, prior writing the user wants to match).
- Any decision documents (locked-decisions file, brand voice guide, style guide).
- SME / reviewer comments if provided as a separate file.

Cite the loaded files in the edit-list file's frontmatter so future sessions know what was used.

## Step 3 — Produce the edit-list file

Create a single file: `<source-name>-edits-list.md` in the same folder as the source (or wherever the user wants it). This file is the source of truth.

### Edit-list file template

```markdown
---
title: <Source name> — Edit list
purpose: Page/section-ordered edits for <source>. Source of truth for the copyediting walkthrough.
source_file: <path to source>
voice_template: <paths to voice references>
locked_decisions:
  <key>: <value>
voice_rules:
  - No em-dashes in any new copy
  - No "X, not Y" / "X, rather than Y" / "not just X" antithesis pattern
  - No "actually" as filler
  - No "from X to Y" listing pattern
  - No "Whether you are X or Y" pattern
  - No "in today's [adjective] [noun]"
  - No buzzwords: delve, leverage, navigate, robust, comprehensive, seamless, ensure, fostering, underscores, tapestry, landscape, showcases, highlights, boasts, vital, crucial, pivotal
  - <Plus any user-added rules from intake>
progress_tracking:
  marker_section: "## 📍 Progress marker (auto-updated by Claude during walkthrough)"
  protocol: "Claude maintains the marker after each user response. Move applied items to Applied. Update Currently presenting and Next up. Pending cleanups inside already-applied copy go in their own list so they surface at end."
  resume_instruction: "Read the marker section first on a new or compacted session. Continue from Currently presenting or Next up. Do not re-present items already in Applied unless the user asks to revisit."
last_updated: <date>
---

# <Source name> — Edit list

Working document for the copyediting walkthrough. Edits are <page-ordered | section-ordered | chapter-ordered> so the user can scroll through the source sequentially.

## 📍 Progress marker (auto-updated by Claude during walkthrough)

**Last updated:** <date>
**Cadence:** <page | section | chapter>
**Editor:** User applies in <target editor>

### Applied (verified by user)

- (empty at start)

### Skipped (return at end)

- (empty at start)

### Pending cleanups in already-applied copy

- (empty at start)

### Locked deviations from earlier decisions

- (empty at start)

### Currently presenting

- (set when first page is presented)

### Next up after current

- (queue of upcoming pages/sections)

---

## Voice rules (this pass)

<Detailed bullets, including the Wikipedia AI-tells reference URL: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing >

## Vocabulary swaps (apply throughout)

| Soft / source phrasing | Replacement | Why |
|------------------------|-------------|-----|

## Page-by-page (or section-by-section) edits

### p<N> — <section heading>

**Type:** <reframing | currency | structural | partnership | etc.>
**Old:** <verbatim from source>
**New:** <replacement copy, scrubbed of tells>
**Why:** <one line>

(repeat for each location)

## QA checklist (this pass)

- [ ] No em-dashes in any new copy
- [ ] No "X, not Y" / "X, rather than Y" / "not just X" antithesis pattern
- [ ] No "actually" as filler
- [ ] No "from X to Y" listing pattern
- [ ] No "Whether you are X or Y" pattern
- [ ] (Plus any user-specific checks)

## What this pass does NOT do

- (Boundaries: what is out of scope)
```

## Step 4 — Self-check before presenting

Before showing any replacement copy to the user, scan it for:
- Em-dashes
- Antithesis pattern (`X, not Y` / `rather than` / `not just`)
- "Actually" as filler
- "From X to Y" listing
- "Whether you are X or Y"
- Buzzwords from the rules
- Repetitive parallel structure (triplets stacked on triplets)

Scrub before presenting. If a tell slips through and the user catches it, **fix the source file immediately** (the edit-list file's stored copy), then apologize tersely and re-present. Do not just fix the in-conversation copy and leave the file dirty.

## Step 5 — Walkthrough protocol

For each page (or section, depending on cadence):

1. Present heading: page number + section name
2. List all changes for this page from the edit-list file
3. For each change show:
   - **Type** (reframing / structural / etc.)
   - **Old** (verbatim from source)
   - **New** (paste-ready replacement)
   - **Why** (one line)
4. End with a single prompt: "Reply when applied (or skip / give different version)."

Wait for user response. Then update the marker:
- "applied" → move to Applied list
- "skip" → move to Skipped list with reason
- variation request → produce variation, re-present
- "pause" or end-of-session → leave marker as-is, note time

After every user response, **update the Progress marker section in the edit-list file**. Do not batch; update inline so a compacted session has accurate state.

## Step 6 — Track pending cleanups separately

When you discover an issue in already-applied copy (e.g., a tell that slipped through earlier), do NOT silently re-edit. Surface it to the user, then add to "Pending cleanups in already-applied copy" in the marker. Surface the cleanup queue at the end of the walkthrough so the user can apply them in one batch.

## Step 7 — End-of-walkthrough

When the queue is empty, run the QA checklist with the user. Surface any pending cleanups. If the source has a Table of Contents, deferred pagination, or anything skipped for layout reasons, return to those now.

## Voice rules (default set — Wikipedia: Signs of AI writing)

Reference: https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

The default rules (apply unless the user overrides):

**Punctuation**
- No em-dashes (—) in new copy. Replace with comma, semicolon, colon, period, or restructure.

**Antithesis patterns** (the strongest tell)
- No "X, not Y"
- No "X, rather than Y"
- No "not just X, but Y"
- No "It's not X, it's Y"
- No "instead of Y" inversions when used rhetorically
- Rewrite as positive claims

**Filler and hedge words**
- No "actually" as filler
- No "in today's [adjective] [noun]"
- No "It's important to note that"
- No "stands as a testament to"

**Listing patterns**
- No "from X to Y" enumerations
- No "Whether you are X or Y"
- Watch for forced triplets and stacked parallel structure

**Buzzwords**
delve, leverage, navigate (as metaphor), robust, comprehensive, seamless, seamlessly, ensure (when "make sure" works), fostering, underscores, tapestry, landscape, showcases, highlights, boasts, vital, crucial, pivotal, unlock, elevate, vibrant

**Quoted humans are exempt.** If you are quoting a real person verbatim and their phrase fits an AI-tell pattern, keep the quote and attribute clearly. Do not "fix" attributed quotes.

**Domain technical vocabulary is exempt.** Words like "containerized," "validated," "modular," "reproducibility," "auditability" are domain terms, not buzzwords. The rule of thumb: if a senior practitioner in the field uses the word in a real conversation, it is not a buzzword.

## Workflow improvements to propose at intake

When kicking off a new copyediting job, mention these options up front so the user can opt in:

1. **Voice template extraction.** If the user has 1–3 pieces of writing they like, offer to extract the voice patterns (tone, sentence shape, vocabulary) and include them in the edit-list file as a "Voice template" section. Useful for keeping multiple chapters consistent.

2. **Cleanup ledger.** Maintain a queue of post-application fixes to already-applied copy (e.g., "delete 'actually' on p4"). Surface at end so the user does not have to re-scroll.

3. **Tells audit every N pages.** Every 5 (or user-chosen N) pages, run a quick scan of recently-applied copy and flag anything that slipped through. Catches drift early.

4. **Anonymization registry.** If any names/clients/products need anonymization, keep a registry in the file frontmatter so it stays consistent across the doc.

5. **Locked-decisions file.** If the project has decisions made in earlier sessions or other docs, lock them in the frontmatter so they do not get relitigated.

6. **Companion edit-list.** For long docs that need both structural and voice work, split into two companion files (e.g. `<source>-edits-list.md` for structural/currency/compliance edits and `<source>-<purpose>-pass.md` for the voice reframe). Cross-reference between them and let one own progress tracking.

7. **Output-mode option.** Offer "page-by-page walkthrough" (default), "chapter walkthrough" (faster), or "one big edit list, no walkthrough" (for users who prefer to apply everything in one go).

8. **Diff-only mode for variations.** When producing a re-take of a piece of copy, show only the diff so the user can see what changed without reading the whole paragraph again.

9. **Pre-flight rule confirmation.** Before starting, list the default voice rules and ask: "Anything to add or override?" Lets the user inject project-specific tells (e.g., "no rule of three," "no second-person").

10. **Source-of-truth grounding.** Always read the full source before producing any edits. Do not work from memory or summary.

## Red flags during a walkthrough

- The user catches a tell I missed. Fix the file, not just the chat. Apologize tersely, re-present.
- The user goes quiet for a long stretch. Save state explicitly: ask if they want to pause, and update the marker accordingly.
- The user asks for a "different version" but does not specify what is wrong. Ask what to change before producing the variation.
- The user references an earlier decision I do not see in the file. Ask them to point at it; if it is real, add it to locked_decisions.
- I find myself wanting to do a "while we are here" cleanup beyond the user's intent. Don't. Surgical only.
- The user wants to skip the intake. Push back gently — the questions matter.

## File-naming conventions

- Edit-list file: `<source-name>-edits-list.md` (note the hyphen and plural)
- If a companion file is needed: `<source-name>-<purpose>-pass.md` (e.g., `<name>-engineering-pass.md`)
- Place in the same folder as the source, or in an `assets/` folder if one exists
- Update any project README to link the new file (discoverability)

## Boundaries

- This skill does not produce final-formatted output (PDF, DOCX, etc.). The user applies edits in their target editor; format conversion is a separate step.
- This skill does not skip intake even when context appears pre-loaded.
- This skill does not silently rewrite already-applied copy. Surface the issue, queue the cleanup, and let the user apply in their editor.
- This skill assumes a source document and a defined position for new prose. It does not start from raw notes or fuzzy ideas where the structure has not been decided.