メニュー
Use to revise an existing local Ghost draft section by section with the author, improving formatting, voice, and accuracy. Triggers on "revise this post", "let's go through it section by section", "tighten this draft".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use to create or update the per-author Ghost style guide from all available signals — interview answers, reference docs, and the published corpus — and to fold a newly approved post into it. Triggers on "build my style guide", "update the style guide", "learn my voice from my posts", and is invoked by push-draft after a successful push.
Use to write the first full draft of a Ghost blog post locally, matching the author's style guide, then self-audit it against the anti-pattern checklist. Triggers on "draft a post about X", "write the first draft", "start a new blog post".
Use when first connecting a project to a Ghost site for the ghost plugin, or whenever Ghost credentials are missing/unverified — onboards the Ghost Admin API key, enables the plugin at project level, and verifies the connection. Triggers on "set up ghost", "connect my ghost site", "ghost credentials", "the ghost mcp isn't working".
Use to push a finished local Ghost draft to the Ghost site as a draft (never published) — pull-guards against in-editor edits, uploads the feature image, creates or updates the post, verifies links, and feeds the approved post back into the style guide. Triggers on "push this to ghost", "send the draft to ghost", "publish to ghost as a draft".
Use to write a Ghost blog post end to end, walking the full plan→draft→revise→push flow in one guided pass. Triggers on "write a post about X end to end", "take this from idea to a ghost draft", "guide me through writing a post".
Use when establishing or refining how an author wants to sound before writing Ghost posts, especially with no published corpus yet (cold start) — interviews the author about audience, tone, and admired references, and gathers reference material to seed the style guide. Triggers on "define my voice", "set up my writing style", "I'm starting a new blog", "here are posts I like".
| name | revise-post |
| description | Use to revise an existing local Ghost draft section by section with the author, improving formatting, voice, and accuracy. Triggers on "revise this post", "let's go through it section by section", "tighten this draft". |
You are revising an existing local draft in drafts_dir — no Ghost round-trips. Every change stays on the local filesystem until the author hands off to /ghost:push-draft. Work through each section interactively, one at a time, applying all three axes before moving on.
Read .claude/ghost.local.md and extract:
Read(".claude/ghost.local.md")
Fields you need:
drafts_dir — where local draft .md files live (default blog-posts/drafts).style_guide_path — path to the style guide (default .claude/ghost-style-guide.md).If ghost.local.md does not exist, use the defaults above.
If the author provided a path, use it directly. Otherwise, list the files in drafts_dir and ask the author to confirm which draft to revise:
"I found these drafts in
<drafts_dir>:
<filename1><filename2>Which one should we revise?"
Read the draft file:
Read("<drafts_dir>/<filename>.md")
If the draft file does not exist, stop and tell the author:
"No draft found at
<path>. Run/ghost:draft-postto create one first."
Read the style guide at style_guide_path:
Read("<style_guide_path>")
Parse and internalize all four sections (Stated voice, Observed patterns, Anti-patterns, Provenance log). The style guide governs voice and formatting decisions throughout revision.
If the style guide does not exist, continue the revision but warn the author:
"No style guide found at
<path>. Voice corrections will fall back to generic best-practice prose. Run/ghost:build-style-guideto generate a style-matched guide."
The following anti-patterns govern the voice axis in Phase 5. Keep them active throughout revision.
1a. ALL-CAPS headings
Grep: grep -nE '^#{1,6} [A-Z][A-Z ]{3,}$'
Fix: Convert to sentence case — capitalize only the first word and any proper nouns.
1b. Question-only headings
Grep: grep -nE '^#{1,6} .+\?$'
Fix: Rewrite as a declarative or partially declarative heading.
2. Editorial restatements
Grep: grep -niE '(in other words|to put it simply|what i mean is|what i(''m| am) saying is|let me rephrase|put another way)'
Fix: Delete the restatement and revise the sentence it was clarifying.
3. Hedge words
Grep: grep -niE '\b(just|simply|basically|obviously|of course|clearly|needless to say)\b'
Fix: Delete the hedge word; rewrite the claim more precisely if needed.
4. AI-flavored transitions and filler phrases
Grep: grep -niE '(in conclusion|in summary|to summarize|it(''s| is) worth noting|it(''s| is) important to (note|remember|understand)|delve into|certainly|absolutely|moreover,|furthermore,|additionally,)'
Fix: Delete the phrase; restructure the sentence or paragraph to flow without it.
5. Cleft and focus-frame constructions
Grep: grep -niE '(what (this|that) means is|the thing about .{1,40} is|what(''s| is) (interesting|important|notable) (here|about this) is|the (point|key|takeaway) (here|is that))'
Fix: Delete the frame; state the point directly.
6. Cute closers
Grep: grep -niE '(happy coding|until next time|stay curious|hope this helps|happy (building|shipping|hacking)|that(''s| is) a wrap|catch you (next time|later)|keep (coding|building|hacking))'
Fix: Delete the phrase; replace with a closing line that reinforces the post's main point.
7a. Missing language tag on code fence
Flag any fenced code block whose opening fence has no language tag (a bare triple-backtick with nothing after it).
Fix: Add the correct language tag (typescript, javascript, bash, json, yaml, text).
7b. Code fence lines exceeding 70 characters Flag any line inside a fenced code block longer than ~70 characters (Ghost renders code narrow). Fix: Break long lines using the language's idiomatic line-continuation style.
Split the draft on its Markdown headings (##, ###). Treat the frontmatter block and any content before the first heading as section 0 ("preamble"). Each subsequent heading + its body text is one section.
Build a section list:
Section 0: [preamble / frontmatter]
Section 1: <first heading text>
Section 2: <second heading text>
...
Section N: <last heading text>
Show the list to the author so they know what's coming:
"Here are the sections in this draft: 0. Preamble / frontmatter
- <heading 1>
- <heading 2> ... N.
I'll go through each one and apply formatting, voice, and accuracy checks. Shall I start with section 0?"
Wait for a go-ahead (a "yes" or "start" is enough) before entering the section loop.
For each section in order, run all three axes, then wait for author approval before moving to the next section.
Check and fix all formatting issues in the section:
\ for shell, intermediate variables for TypeScript/JavaScript).```typescript, ```bash, etc.). Never leave a bare ```.<table> block becomes its own clean html card. Use width: 100%; margin: 2em 0, header <tr> border-bottom: 2px solid currentColor, body <tr> border-bottom: 1px solid rgba(128,128,128,0.25) (dropped on the last row), cells padding: 0.65em 1em, numeric columns text-align: right; font-variant-numeric: tabular-nums. If the section has a standalone callout or tip, use a blockquote (>).? and no declarative anchor is forbidden — rewrite as a declarative or partially declarative heading).Run every anti-pattern from the checklist loaded in Phase 3 against the section text:
For each pattern found: fix it in the section text. Do not leave anti-patterns in place and report them — repair first.
If the style guide is available, also check:
Then read the section — don't just grep it. The patterns above are fixed strings; the tells below are rhythm and framing, and they only surface on a read. Read the section out loud: if you wouldn't actually say a sentence, it's a tell. Fix each in place.
Verify every factual claim in the section:
--flag-name — please confirm this is correct before publishing."package.json or similar, check version constraints. If uncertain, flag it.After all three axes, apply the fixes to the section. Show the author a before/after summary:
Section :
Formatting fixes:
- [what was fixed, or "none"]
Voice fixes:
- [pattern name]: [what was fixed, or "none"]
Accuracy flags:
- [claim]: [verified / flagged for author confirmation]
Revised section:
<revised section text>Approve this section, or tell me what to change.
Hold on the current section until the author approves it or requests changes.
After writing an approved section back to the file:
Edit("<drafts_dir>/<filename>.md", <old section text>, <revised section text>)
Then move to the next section and repeat Phase 5 from 5a.
After all sections have been approved, run one final consistency check across the whole draft:
## directly to #### without ### between).title field to match.All per-section Edit() calls in Phase 5 have persisted the approved changes to disk. The draft file is now complete with all revisions applied.
Hand off to push-draft:
"All sections reviewed and approved. Draft saved to
<path>.Run
/ghost:push-draftto publish this draft to Ghost when you're ready."
Do not call any Ghost MCP write tools. The draft stays local until /ghost:push-draft handles the upload.
<drafts_dir>/<filename>.md on the local filesystem only.ghost.local.md is missing: use defaults (drafts_dir: blog-posts/drafts, style_guide_path: .claude/ghost-style-guide.md) and note it./ghost:setup-ghost (to configure the project), /ghost:draft-post (to produce the draft being revised).