Blog Rewrite Skill

Produces a revised version of an engineering blog draft by applying every fix surfaced by [[ape-review-blog]]. The review is the source of truth for what to change; this skill executes the fixes and writes the result to a new file.

How to Run

1. Identify the source blog file the user is referring to. It must be a path on disk. If the user only pasted text, ask them for the file path before continuing -- the rewrite needs a real file to suffix.
2. Check whether ape-review-blog has already run on this exact file earlier in the current conversation and the file has not changed since. Signals that the review is already available: the flavour string and a stream of **required** / **suggested** findings followed by Ape done. appear in the transcript, against the same path. If so, reuse those findings directly -- do not re-run the review, do not re-print the findings. Skip straight to step 4.
3. Otherwise, invoke the ape-review-blog skill on that file and let it produce its findings end-to-end. Do not skip checks, do not summarise findings, do not collapse the review into a shorter form. The review must run as it normally would.
4. Apply every finding -- both required and suggested -- to the original text. Use the Fix: line from each finding as the replacement. For findings that describe an action rather than a literal replacement (reorderings, paragraph splits, bridging sentences, removing formatting), perform that action faithfully in the new draft.
5. Write the rewritten post to a new file alongside the original, with -ape appended to the stem. For example, post.md becomes post-ape.md, 2026-05-distributed-locks.md becomes 2026-05-distributed-locks-ape.md. Never overwrite the original. If a file with the -ape.md suffix already exists, overwrite it -- this is a regenerated rewrite, not a second variant.
6. Print the path of the new file at the end.

If the user explicitly asks to "re-review" or "review again before rewriting", treat that as an override and run the review fresh in step 3 even if a prior review exists.

Rules for the Rewrite

• Apply every finding from the review. Do not cherry-pick. If the review flagged it, fix it.
• For [VERIFY] numbers, leave the number as-is in the rewritten draft but add an inline HTML comment <!-- VERIFY: confirm number is correct --> next to it. For numbers also tagged [CONFIRM PUBLIC + CORRECT], the comment is <!-- VERIFY: confirm number is correct AND cleared for public disclosure -->.
• For [LINK NEEDED] hyperlinks, wrap the relevant phrase in a markdown link with the placeholder URL [LINK NEEDED], so the author can spot and fill them in.
• Preserve the author's voice, facts, and structural intent. The rewrite tightens and corrects the draft; it does not reinterpret it. Never invent numbers, systems, or details that were not in the original.
• Keep code blocks, fenced examples, and genuine quotations untouched unless the review explicitly flagged them.
• Expand contractions, strip decorative formatting, and remove tutorial-style instruction wherever the review called them out.
• If two findings touch the same sentence, merge their fixes into one rewritten sentence rather than applying them sequentially.

Output Structure

If the review has not been run yet for this file in the current conversation, run ape-review-blog first and let its full output stream as normal -- flavour string, findings, and Ape done. line included. Then continue with the rewrite section below.

If a prior review for this file is already in the transcript, skip the review output entirely and open with a single line acknowledging the reuse:

Ape is reusing the earlier review for this file.

Either way, before writing the file, print a short separator and a one-line note that the rewrite is starting:

---
Ape is rewriting the post with every fix applied.

Then write the new file. Do not print the rewritten post inline; the file is the deliverable.

Close with a single line naming the new file:

Rewrite written to <path>-ape.md.