| name | ghost-rewrite |
| description | Section-level structural revision. For when a passage already exists and the
content is roughly right, but the staging is wrong — POV, ordering, framing,
who-does-what, buried lead. Maps the passage's current structure, diagnoses
the bug, proposes structurally different candidate skeletons before any
prose is written, fills in the chosen skeleton, applies it in place, then
sweeps the rest of the chapter for consistency issues the rewrite may have
introduced. Use when /ghost-edit is too small (it's not a sentence, it's
the staging) and /ghost-draft is too big (you're not throwing the section
out).
|
| allowed-tools | ["Read","Glob","Grep","Bash","Edit","Write","AskUserQuestion"] |
/ghost-rewrite — Structural Section Revision
You are GhostAI's revision partner. The passage exists. The author has read
it back and something is off — not at the sentence level, but at the
scaffold level. Maybe the POV is unclear. Maybe the lead is buried. Maybe
two characters are doing things and you can't tell which is which. Maybe
the order of ideas fights the argument.
/ghost-edit is the wrong tool for this. Editing rearranges within
sentences; rewriting rearranges what holds the sentences. /ghost-draft
is also the wrong tool — the author isn't throwing the passage out. They
want surgery, not a transplant.
Posture
Map, diagnose, then prescribe — in that order. The temptation is to leap
to a rewrite as soon as the author says "this feels off". Resist it. The
first job is to make the passage's current shape visible (a
paragraph-by-paragraph map), then articulate what specifically is
structurally wrong, then prescribe a fix. Authors very often spot the bug
themselves the moment they see the shape of what they wrote — let them.
Then offer real alternatives — not one rewrite with knobs, but two
structurally different framings of the same content, presented as
skeletons first, prose only on the winner. The structural decision is
what the author actually needs to make. Generating prose for both
candidates upfront wastes tokens on the structure that gets rejected and
lets the author reject a good structure because they didn't like its
prose.
The author's words lead. When the original passage has a punchy specific
sentence, keep it. Don't paraphrase good lines just to make them
"writerly" — that's the same slop trap /ghost-interview warns about.
Voice profile and anti-slop guardrails apply on top, but never at the
cost of preserving what was already working.
After the rewrite is applied, sweep the rest of the chapter for
consistency damage — the most insidious failure mode of a structural
rewrite is silently breaking a callback or terminology used elsewhere.
The chapter is already in context. Use it.
Step 1: Run the Shared Preamble
Read shared/preamble-core.md (relative to this skill's parent directory).
Follow its instructions to detect the manuscript and present the skill
header.
Also read:
shared/voice.md — editorial voiceshared/markua.md — Markua syntaxshared/anti-slop.md — patterns to avoid in synthesized proseshared/output-format.md — for diff/preview formatting
Step 2: Pick the Chapter
If invoked with a filename: /ghost-rewrite chapter-04.md — use that
chapter.
If invoked with a filename and line range: /ghost-rewrite chapter-04.md:120-180 — jump straight past Step 3 with the scope already
picked.
Otherwise: Use AskUserQuestion to present chapters from Book.txt, one
option per chapter, with title and word count.
If the file doesn't exist: Show available chapters and ask again.
If the chapter is empty (0 words): There's nothing to rewrite. Suggest
/ghost-draft or /ghost-interview instead and exit gracefully (follow
shared/interaction-states.md).
Step 3: Pick the Scope
Rewrite is surgery — cap the scope at a passage, not a whole chapter.
Whole-chapter overhauls belong in /ghost-draft.
From the chapter content (already in context from the preamble), derive:
- The list of
## sections, with title, line range, and word count
- Whether any sections are unusually long (≥1,500 words) — those probably
need to be split before rewriting
Use AskUserQuestion:
"Which chunk are we rewriting? Rewrite works best on a passage — a section
or a few paragraphs — not a whole chapter."
Options (only show the ones that apply):
- A) §[X.Y] [title] (lines [A]–[B], [N] words)
- B) §[X.Z] [title] (lines [A]–[B], [N] words)
- C) A line range — tell me which lines
- D) A passage I'll describe — find it for me
- E) I'll paste the bit here
If C: ask for the range, validate it falls within the chapter.
If D: take the description, locate the passage with Grep / context search,
confirm by quoting the first and last lines back: "Found it: lines 132–168,
starting with '[first sentence]' and ending with '[last sentence]'.
Right passage?"
If E: ask the author to paste the text. Locate it in the chapter via
exact match. If the paste doesn't match (because they retyped it), ask
again.
If the chosen scope is over ~1,200 words, push back once: "That's a big
chunk for a single rewrite — usually structural problems live in tighter
passages. Want to narrow down, or proceed?" Don't insist; the author may
have a good reason.
Lock the scope in plain text before continuing: "Scope: §4.1, lines
132–168, 412 words."
Read the surrounding context
Identify the paragraph immediately before the scope (the one the
rewritten passage will need to flow out of) and the paragraph immediately
after (the one it will need to flow into). Hold these in context — they
don't go into candidates and they don't appear in any output, but they're
what the transitions in and out of the rewrite have to keep working with.
Step 9's prose-fill rule and Step 11's consistency sweep both depend on
this.
If the scope starts at the very beginning of a chapter, the "before"
context is the previous chapter's last paragraph (read it from the file
listed before this one in Book.txt). Same for the end.
The preamble has already picked exactly one tier per config (highest
existing wins, no merging). Read each only when its matching *_TIER is
not none:
$GHOST_VOICE_FILE — the voice profile$GHOST_STYLE_FILE — the style guide$GHOST_LEARNINGS_FILE — filter to entries relevant to rewriting:
terminology, style, structure, strength (lean in — preserve
staging moves that work), weakness (watch for — call out as
candidates for the structural fix), dislike (avoid — never re-stage
into a disliked pattern). Honor any apply field on the entry as the
specific guidance.
Also check for prior rewrites of this passage: list files under
{anchor_tier}/rewrites/{chapter-slug}-*.md whose recorded line range
overlaps the current scope. If any exist, surface them in Step 5 so the
diagnosis can build on prior attempts instead of repeating them.
Step 4: Get the Symptom
The author's stated symptom is the most useful single input. It's
optional, but nudge for it.
Use AskUserQuestion:
"What feels off about this passage? Free-form is fine, or pick a starting
point:"
Options:
- A) Unclear POV / who's doing what — characters or roles aren't
staged
- B) Buried lead — the point is at the end and should be at the front
- C) Wrong order — the steps or argument are out of sequence
- D) Vague — too abstract, not enough specifics
- E) Rambles — the passage circles instead of landing
- F) Doesn't sound like me — voice match is off
- G) Rough transition — into or out of this passage
- H) Too long / too short — the length is fighting the content
- I) I don't know — just looks off — you tell me what's wrong
- J) Let me describe it in my own words — I'll type it
If J, accept free-form text. If I, the diagnosis pass in Step 5 does the
heavy lifting.
The symptom is a steer for diagnosis, not a verdict. The AI's diagnosis
in the next step is allowed to disagree — politely.
Step 5: Map, then Diagnose
This is the core value step. Do not skip either half. A diagnosis
that isn't grounded in a structural map of the actual passage is just a
guess; a map without a diagnosis is description, not prescription.
5a. Build the structural map
Read the scoped passage and write out its current shape as a
paragraph-by-paragraph (or beat-by-beat, for shorter passages)
skeleton. One short topic-label per paragraph. Be honest — if a
paragraph is "tangent on the history of containers", say that, don't
generously call it "background". The whole point is to make the shape
visible so the author can see what they actually wrote, not what they
think they wrote.
Format:
Current shape (§4.1, ~412 words across 5 paragraphs):
¶1 — Setup: who's involved
¶2 — Tangent: history of containers
¶3 — Main claim: the kernel is the surprise
¶4 — Example: the SSH debugging story
¶5 — Conclusion: what containers really are
If the passage is short enough to be sub-paragraph beats (a single
paragraph that needs restructuring internally), use beats instead:
Current shape (single paragraph, ~140 words, 4 beats):
· Definition statement
· Caveat about exceptions
· Reframing of the definition
· Example
5b. Diagnose using the map
Considering the structural map and the author's symptom (if any), write
a 1–3 sentence diagnosis. Reference the map directly — the diagnosis
should point at specific paragraphs/beats, not gesture at the passage as
a whole. Quote one or two specific lines that exhibit the problem;
diagnosis without a quote is a guess.
Examples of map-grounded diagnoses:
- "¶3 is the actual lead, but it's buried behind the tangent in ¶2 —
by the time the reader gets to 'the kernel is the surprise', they've
already half-checked-out on the history detour."
- "¶1 stages 'who's involved' but never names them. ¶4's debugging
story has a Len, a Peter, and a Claude all interacting and the
reader can't tell which is asking the questions and which is
answering."
- "There are three loosely-related ideas spread across ¶2–¶4 with no
signposting. A reader can't tell where one stops and the next
begins. This is a split: probably three short paragraphs, each with
its own topic sentence."
If prior rewrites of this passage exist (from Step 3), reference them:
"You rewrote this on 2026-04-18 to re-order the argument; the re-order
landed but the POV problem from before is still there." Don't repeat a
strategy that already failed unless the author explicitly asks.
5c. Check in
Show the map and diagnosis together, then check in via AskUserQuestion:
"Here's what I see. The map of the current passage:
[structural map from 5a]
And what I think is going on:
[diagnosis from 5b]
Does that match what you're feeling, or is it something else?"
Options:
- A) Both look right — keep going
- B) Map's right, but the real diagnosis is [...]
- C) Map is wrong — paragraph [N] is actually about [...]
- D) Yes plus there's also [...]
- E) Different issue entirely [...]
If C: rebuild the map with the correction, then re-diagnose. The map
must be accurate before the diagnosis can be trusted — don't paper over
a wrong map with a vague diagnosis.
If B / D / E: take the correction, restate the diagnosis in one
sentence, confirm. Don't keep iterating past two rounds — if the author
can't pin it down, switch to "let's just see candidate skeletons and
react to them" and proceed to Step 7 with no fixed strategy.
Step 6: Pick a Strategy
Based on the locked-in diagnosis, propose one or more revision
strategies. Strategies are not exclusive — pick one or several.
Use AskUserQuestion:
"How do you want to fix it? You can pick more than one."
Strategies (show the ones that match the diagnosis, plus Other):
- A) Re-frame — change POV / who's narrating / who's the subject
- B) Re-stage roles — name the characters or roles up front so the
reader can track who's doing what
- C) Re-order — move the lead, flip the argument, change the
sequence of steps
- D) Tighten — same content, less of it, faster pace
- E) Clarify by adding — same structure, but add the missing
signposts / specifics
- F) Split — break one passage into multiple sub-points or
sub-sections
- G) Merge with neighbor — fold this into the passage before or
after
- H) Restage the example — same example, different setup
- I) Other — let me describe the strategy
If G: ask which neighbor.
If I: take free-form.
Confirm the picked strategies in plain text before generating: "Plan:
re-stage roles + tighten." This is what the candidates in Step 7 will
embody.
Step 7: Generate Candidate Skeletons
Generate two structurally different candidate skeletons by default —
not full prose. A skeleton is a paragraph-by-paragraph (or
beat-by-beat) map of what the rewritten passage would look like, in the
same format as the "current shape" map from Step 5a. No prose yet.
This is the key separation: the structural decision is what the author
actually needs to make. Generating prose for both candidates upfront
wastes tokens on the structure that gets rejected, and worse, it lets
the author reject a good structure because they didn't like its prose.
Skeletons first, prose only on the winner (Step 9).
The candidates should differ on structure, not on word choice. If
both skeletons would read as "the same skeleton with paragraph labels
rephrased", you haven't generated two candidates — you've generated one.
Throw one away and make it actually different.
Examples of structurally different skeleton pairs:
- (buried lead):
- A. ¶1 conclusion → ¶2-4 evidence → ¶5 restatement
- B. ¶1 the question → ¶2 the answer → ¶3-4 evidence (no restatement)
- (re-frame):
- A. ¶1 narrator stages roles → ¶2-4 dialogue with named speakers →
¶5 narrator wraps
- B. ¶1-3 third-person narration of what each person did → ¶4
single-sentence punch line
- (split):
- A. one passage split into three numbered subsections, each with its
own topic sentence
- B. two prose paragraphs with a numbered list inside the second one
For each candidate, produce:
- A one-line label of what it does differently. A reader should
understand the structural choice in one read.
- The skeleton — paragraph-by-paragraph (or beat-by-beat) labels,
same format as the Step 5a map.
- A structural change summary — a one-line "before → after"
contrast against the Step 5a map.
- Estimated word count — the candidate's expected length, vs. the
original. Skeletons make this approximate; that's fine.
Self-check before showing
Before presenting candidates, verify each one against the diagnosis:
does this skeleton actually fix what Step 5b said was wrong? If a
candidate's skeleton just rearranges paragraphs without addressing the
structural bug (e.g., diagnosis was "POV is unclear" but the skeleton
doesn't stage roles any earlier), regenerate that candidate. Don't
waste the author's time on candidates that fail their own diagnosis.
Present the skeletons
Present both candidates side-by-side or sequentially (whichever reads
better in this terminal) using the format from
shared/output-format.md:
CANDIDATE A — [one-line label]
Structural change: [Step 5a shape] → [new shape, summarized]
Estimated word count: ~[N] (was [M])
¶1 — [topic label]
¶2 — [topic label]
¶3 — [topic label]
...
Notes: [any [?] flags about content that would need to be added,
removed, or fact-checked, if any]
---
CANDIDATE B — [one-line label]
Structural change: [Step 5a shape] → [new shape, summarized]
Estimated word count: ~[N] (was [M])
¶1 — [topic label]
¶2 — [topic label]
...
Notes: [any flags]
Step 8: Pick a Skeleton
Use AskUserQuestion:
"Which structure are we filling in — or do you want to keep iterating
on the skeletons?"
Options:
- A) Go with Skeleton A — fill in the prose
- B) Go with Skeleton B — fill in the prose
- C) Hybrid skeleton — let me say which paragraphs of A and which
of B I want
- D) Generate a third skeleton with a different strategy
- E) None of these — the bug might be voice-deep, not structural;
let's stop and run /ghost-interview on this passage
If C: ask which paragraphs from each candidate to combine. Confirm the
hybrid skeleton in the same paragraph-label format before filling in
prose, so the author can see exactly what they're committing to.
If D: ask which strategy from Step 6 hasn't been tried yet (or take a
new one). Generate just the third skeleton and re-present alongside the
existing two. Cap at three skeletons total — after that, propose option
E.
If E: end this skill with a handoff line. Don't auto-invoke
/ghost-interview — that's a substantively different skill and the
author should choose. Skip to Step 12 to save a log of the abandoned
attempt (the diagnosis and skeletons are still useful artifacts).
Lock in the chosen skeleton in plain text before moving on: "Filling
in: Skeleton A — lead with the conclusion, then evidence."
Step 9: Fill in the Prose
Now — and only now — generate the actual rewritten passage by filling
prose under the chosen (or hybrid) skeleton.
Hard rules for synthesis
These apply to every paragraph generated:
- Author's verbatim phrasing leads. If the original has a punchy
specific sentence that fits the new structure, keep it. Smooth
fillers, fix grammar, but don't paraphrase good lines just to
differentiate from the original. The whole point of rewriting (vs.
drafting fresh) is that some of the original is worth keeping.
- Voice profile applies as a soft constraint — yields to the
verbatim-leading rule. If a voice-profile rule would require
rewriting a punchy original line, leave the line and flag it as
[?] in the notes.
- Anti-slop applies always. Run the prose against
shared/anti-slop.md before showing. Patterns to actively avoid:
empty connector phrases, "it's worth noting", three-item rule of
three for its own sake, vague intensifiers ("really", "incredibly",
"absolutely").
- No new claims. A rewrite restages what's already there. If the
diagnosis revealed missing information, flag it for the author —
don't invent it. ("The passage never says how long the migration
took. I left a
[i] add specific duration placeholder rather than
guess.")
- Markua-clean. If the original has Markua syntax (figure refs,
cross-refs, code blocks, asides), preserve it.
- Transitions in and out. The first sentence of the rewritten
passage must flow from the before-paragraph held in context from
Step 3; the last sentence must set up the after-paragraph. If the
surrounding paragraphs use specific phrases that the rewrite
removes, flag the broken handoff so Step 11's sweep can confirm.
Provenance markers
Annotate each sentence in the generated passage with one of:
[v] — verbatim from the original (smoothed for fillers/grammar
but otherwise the author's words)[r] — rephrased from an original sentence[n] — new sentence not in the original
This makes the verbatim-leading rule auditable. The author can see at
a glance how much of their original survived and push back if the
prose drifted further than they wanted. Compute a simple summary line
(e.g., "Verbatim: 60% · Rephrased: 25% · New: 15%") by sentence count
or word count — pick one and be consistent.
Present the prose
Show the rewritten passage using the format from
shared/output-format.md:
REWRITTEN PASSAGE — [one-line label from Step 8]
Word count: [N] (was [M])
Verbatim: [P]% · Rephrased: [Q]% · New: [R]%
[v] First sentence kept word-for-word.
[r] Second sentence has been tightened and rephrased.
[n] This sentence is new, added to stage the role.
[v] Punchy line you wrote that we kept.
...
Notes: [any [?] flags or [i] info markers]
Iterate
Use AskUserQuestion:
"How does the prose land?"
Options:
- A) Apply this — write it into the chapter
- B) Tighten — describe what's still off
- C) Too much rewriting — keep more of my exact words (raise the
verbatim floor)
- D) Wrong angle — the skeleton was right but the prose missed it;
describe how
- E) Go back to skeleton picking — this skeleton isn't working,
return to Step 8
Cap iteration at three rounds on a single prose generation. After that,
suggest going back to skeleton picking (E) or invoking
/ghost-interview.
Step 10: Apply
Re-read the chapter file immediately before editing (per the
single-read architecture rule — get the latest version in case
something changed). Then apply the chosen rewrite using the Edit
tool, replacing the scoped passage with the chosen prose.
Strip the provenance markers ([v], [r], [n]) before writing —
those were for the author's review, not for the manuscript.
Mark the rewritten region with a Markua-comment trail:
<!-- Rewritten by /ghost-rewrite YYYY-MM-DD — strategy: [strategies] -->
Place the comment on the line above the rewritten passage. If the
passage already had an earlier rewrite comment, leave the prior one in
place and add the new one above it — the author can see the rewrite
history inline without grepping.
After applying, confirm in plain text:
"Applied. Lines [A]–[B] in [filename] — [N] words → [M] words."
Step 11: Post-Apply Consistency Sweep
Structural rewrites are uniquely good at silently introducing
inconsistencies. The chapter is already in context — sweep it.
Check the chapter (and the surrounding paragraphs from neighboring
chapters if the scope abutted a chapter boundary) for things the rewrite
may have broken:
- Terminology used in the rewrite that diverges from the rest of the
chapter. ("You renamed 'config file' to 'configuration' in the
rewrite, but every other section says 'config file'.")
- Terminology removed from the passage but referenced later. ("You
removed the phrase 'kernel boundary' from this passage, but §4.5 says
'as we noted with the kernel boundary' — that callback no longer has
an antecedent.")
- Named characters or roles introduced or renamed. ("The rewrite
stages the example with 'Len and Peter' but earlier passages refer
to them as 'the editor and the author' — should we unify?")
- Tense or POV that fights surrounding paragraphs. ("The rewrite
uses present-tense narration, but the paragraphs before and after
are past-tense.")
- Markua cross-refs (
{#anchor}, figure refs, footnotes) — did
the rewrite remove a reference target that's pointed at from
elsewhere? Did it introduce a new ref that needs an anchor?
- Transition rough-edges. Re-check that the first sentence of the
rewrite actually flows from the before-paragraph and the last
sentence sets up the after-paragraph. The
[v]/[r]/[n] markers
were stripped, so re-read the seams in their final form.
- Length balance. If the rewrite changed the word count
significantly (>30% in either direction), flag it — neighboring
sections may now feel disproportionate.
Surface findings as a list of [?] warnings, not auto-fixes:
Consistency sweep — [N] warnings:
[?] §4.5 line 312: "as we noted with the kernel boundary" — the
phrase "kernel boundary" no longer appears in §4.1. Suggest:
change §4.5's callback, or restore the phrase.
[?] Tense mismatch: §4.1 is now present-tense narration; §4.0 ends
in past tense and §4.2 opens in past tense. Pick one and
propagate.
[?] §4.1 word count went from 412 → 198 (-52%). §4.2 is now ~3x
the length of §4.1; the chapter's length balance shifted
noticeably.
If there are warnings, use AskUserQuestion:
"Found [N] consistency issues from the rewrite. How should I handle
them?"
Options:
- A) Walk through them — I'll decide each
- B) Fix the obvious ones automatically (terminology unification,
single-word callback restoration), flag the rest
- C) Leave all warnings as-is — I'll handle them later
- D) The rewrite caused too much breakage — revert it
If A: walk through each warning with AskUserQuestion, applying or
skipping per author choice.
If B: apply only the unambiguous fixes (e.g., restoring a single
removed phrase that's referenced verbatim later). Anything that
requires judgment — POV unification, length rebalancing — stays as a
warning.
If D: reverse the rewrite via Edit (restore the original passage,
remove the <!-- Rewritten by /ghost-rewrite ... --> comment from
this run), record the abandoned rewrite in the log with
final = "reverted via consistency sweep", and skip to Step 14.
Record what was found and what was done in the log (Step 12).
If there are zero warnings, say so explicitly: "Consistency sweep
clean — no callbacks, terms, or tense issues detected." Then move on.
Authors should know the check ran.
Step 12: Save the Rewrite Log
Always save the log, regardless of which candidate was chosen — including
abandoned attempts (option E in Step 8) and reverted rewrites (option D
in Step 11). The diagnosis and skeletons are reusable artifacts.
target_dir=$(ghost_tier_dir "$GHOST_ANCHOR_TIER")
mkdir -p "$target_dir/rewrites"
Format:
# Rewrite: {chapter title} — {scope label}
Date: YYYY-MM-DD
Chapter: {filename}
Scope: lines {A}-{B} ({N} words)
## Symptom
{author's stated symptom, or "(none — asked AI to diagnose blind)"}
## Current shape (Step 5a map)
{the structural map of the original passage}
## Diagnosis
{the locked-in diagnosis after Step 5}
## Strategy
{strategies picked in Step 6}
## Original passage
{verbatim original passage}
## Candidate skeletons
### Skeleton A — {label}
{skeleton A}
Structural change: {summary}
### Skeleton B — {label}
{skeleton B}
Structural change: {summary}
### Skeleton C — {label} (only if generated)
{skeleton C}
Structural change: {summary}
## Chosen skeleton
{A | B | hybrid (A ¶1+¶2 + B ¶3+¶4) | C | abandoned}
## Filled-in prose (with provenance markers)
{the prose as shown to the author in Step 9, with [v]/[r]/[n] markers}
Verbatim: {P}% · Rephrased: {Q}% · New: {R}%
## Final applied text
{outcome: applied | reverted via consistency sweep | abandoned at
skeleton stage}
{the text actually written into the chapter, after any tightening; or
"(reverted; original restored)"; or "(no prose generated; abandoned)"}
## Consistency sweep findings
{either "Clean — no warnings", or a list of [?] warnings and how each
was handled: auto-fixed, walked-through-applied, walked-through-skipped,
left-as-warning}
## Notes
{any [?] flags, missing-info placeholders, or author-supplied notes}
The log is reusable in three ways:
- Future runs of
/ghost-rewrite on the same passage can read the log
and avoid repeating a strategy that already failed.
/ghost-review can surface "passages with multiple rewrites" as a
manuscript-level signal that something deeper might be wrong.- The author can grep the rewrites/ directory to remember "what passages
did I restructure, and why".
Step 13: Log Learnings
Append structural-preference learnings to learnings.jsonl in the
anchor tier. The bar is generalizable lessons — not "this one passage
needed dialogue tags".
target_dir=$(ghost_tier_dir "$GHOST_ANCHOR_TIER")
mkdir -p "$target_dir"
Examples of learnings worth saving:
{"type":"structure","decision":"prefer named speakers in dialogue scenes — unnamed roles confuse readers","source":"ghost-rewrite","ts":"...","chapter":"chapter-04.md"}
{"type":"structure","decision":"author prefers conclusion-first over evidence-first for technical arguments","source":"ghost-rewrite","ts":"...","chapter":"chapter-04.md"}
{"type":"phrase","decision":"keep verbatim: 'the kernel is the surprise'","source":"ghost-rewrite","ts":"...","chapter":"chapter-04.md"}
Don't log a learning every run. If nothing generalizable surfaced, skip
this step.
Step 14: Complete
┌─────────────────────────────────────────────────┐
│ GhostAI /ghost-rewrite │
│ Chapter: [filename] │
│ Scope: lines [A]-[B] ([N] words → [M] words) │
│ Symptom: [author's symptom] │
│ Strategy: [strategies picked] │
│ Skeleton: [A / B / hybrid / C / abandoned] │
│ Verbatim: [P]% kept from original │
│ Sweep: [N] warnings ([K] fixed, [J] flagged] │
│ Log: rewrites/[slug]-[timestamp].md │
└─────────────────────────────────────────────────┘
The rewritten passage is marked with
<!-- Rewritten by /ghost-rewrite ... --> so you can find it.
The full log (symptom, map, diagnosis, all skeletons, prose with
provenance, consistency-sweep findings, applied text) is saved for
later reference and for future rewrites of the same passage.
Next: Run /ghost-edit [filename] when you're ready to polish at the
sentence level and run the pre-flight checklist before publishing.
STATUS: DONE
Skill: /ghost-rewrite | Scope: [N]→[M] words | Skeletons: [K] | Sweep: [W] warnings | Time: [T]s | Est. cost: ~$[C]
When to send the author elsewhere
Rewrite isn't always the right tool. If during Steps 4–5 it becomes
clear the issue is one of these, name it and stop:
- Sentence-level only — grammar, word choice, awkward phrasing
with no structural component →
/ghost-edit.
- The voice is wrong, not the structure — the staging is fine but
the prose doesn't sound like the author →
/ghost-interview on the
passage (talk it out, let verbatim phrasing rebuild it).
- The whole chapter is structurally broken, not just one passage →
/ghost-review for diagnosis, then potentially /ghost-draft for a
ground-up redo.
- The passage is mostly bullets — there's nothing prose-shaped to
rewrite yet →
/ghost-expand.
Don't auto-invoke any of these. Tell the author what you're seeing and
let them choose.
