| name | prepublish |
| description | Review a new blog post before publishing. Finds the latest post by its dated path under `src/posts/`, then spell-checks and offers content suggestions — without touching tone. |
Prepublish blog post review
Run this right before pushing a new post. Blog posts live in src/posts/YYYY/MM/DD/ as .md files.
Step 1 — Find the post
Do NOT use git to figure out which post is newest. Use the dated path under src/posts/ — sort highest year → month → day and pick the most recent .md file.
A reliable command: find src/posts -type f -name '*.md' | sort -r | head -5. The first entry is the latest post; the rest are there in case there's a tie or the user wants to pick another.
If multiple .md files share the newest date directory, ask the user which one. Otherwise, confirm in one line ("Reviewing path/to/post.md — sound right?") before proceeding.
Step 2 — Spell check
Read the post and surface misspellings. Ignore code blocks, fenced code, inline code, URLs, and proper nouns the user clearly intended (product names, people, libraries).
Present findings as a short list: word → suggestion (line N). Don't auto-edit. Ask which corrections to apply, then apply them with Edit.
Step 3 — Content review
Read the post end-to-end and give feedback focused on substance, not tone:
- Things that sound stupid or unclear — sentences that don't land, claims that need backing, awkward logic jumps.
- Gaps worth filling — missing context a reader would want, an example that would help, a link the user usually includes (docs, repo, related post).
- Factual / technical accuracy — flag anything that looks wrong or outdated. If the post references code, check it makes sense.
- Loose ends — TODO markers, "fill this in", broken-looking links, placeholder text.
Do NOT comment on tone, voice, snark level, casual phrasing, or stylistic choices. The user likes their voice; leave it alone.
Present feedback as a numbered list grouped by category. Keep each item to one or two sentences. Don't rewrite paragraphs — point at the issue and let the user decide.
When you look at the front matter, if you see banner_image set to 'welcome2018.jpg', flag that as a mistake and suggest updating it to a more relevant image.
Step 4 — Apply changes
Ask which suggestions to act on. Apply only what's confirmed. Then stop — the user handles the actual publish/push.
