blog_post_production v1.0.0

name: "blog_post_production" description: "Produce a blog post end to end: brief and research, outline, draft, separate editing passes, basic SEO checks, publish checklist, and distribution. Triggers on write a blog post, draft a post, edit my blog draft, plan a blog, blog outline, or publish and promote a post."

Blog Post Production

Purpose

Take a blog post from idea to published and shared, with a process a second person can check. This skill covers general blog craft for any topic. It does not assume a codebase, a product launch, or a news beat. The job is a post that answers one reader question well, reads clean on a phone, and gets shared on purpose after it goes live.

Workflow

1. Write the brief before any draft

Fill the brief in assets/post-brief.md. No brief, no draft. The brief states:

1. Reader: one specific person, what they already know, what they get wrong.
2. Reader question: the single question the post answers, in the words that person would type or say.
3. Promise: one sentence. After reading, the reader can do or decide what.
4. Search intent, if search matters: informational (learn), navigational (find a place), or transactional (buy or act). Match the format to the intent. A how-to for a buyer question fails both readers.
5. Angle: what this post adds that the top three existing posts on the topic do not. One new example, one test, one interview, one dataset, or a clearer order counts. Restating the same points in new words does not.
6. Evidence list: sources, data, screenshots, or first-hand notes the draft will use. Mark each claim that still needs a source.
7. Call to action: one action at the end. Subscribe, try a step, read a linked post, reply. Pick one.

Run Google's Who, How, Why check on the brief itself. Who is writing this and why should a reader trust them. How was it made, including any automation a reader would want disclosed. Why does it exist, to help a reader or only to chase traffic. If the Why answer is only traffic, stop and rework the brief.

2. Research, then outline from the evidence

• Read the sources in the brief first. Take notes as claims with a source link next to each claim. A claim with no source goes on a cut list, not into the draft on hope.
• Read two or three strong posts already ranking or circulating on the topic. Note what question each section answers. Do not copy their order by default.
• Build the outline as a list of reader questions in the order a reader asks them. Each heading becomes one question or one clear job.
• Choose a structure pattern from references/structure-patterns.md: inverted pyramid for news and updates, step order for how-to posts, problem and fix for troubleshooting, comparison for choice posts, story then lesson for experience posts. Name the pattern in the brief.
• Front-load the point. Web reading research reported from Nielsen Norman Group work finds most people scan and read only part of a page, often in an F-shaped pattern. The first two paragraphs must carry the answer, not warm up to it.

Worked outline example, how-to post:

Title (working): Fix a Leaky Kitchen Faucet With One Wrench
Reader question: Why does my faucet drip after I shut it off, and can I fix it myself?
Promise: A reader can stop a common cartridge faucet drip in under an hour.

H2: What causes the drip (worn cartridge, in plain terms)
H2: What you need (short list, with sizes)
H2: Shut off the water first (safety step, before any tools)
H2: Remove the handle and old cartridge (numbered steps, one photo per step)
H2: Fit the new cartridge and test
H2: If it still drips (two checks, then call a plumber)
Close: one call to action, plus a link to the shutoff-valve guide

3. Draft fast, in outline order

• Draft section by section, following the outline. Write the opening last if it stalls the rest.
• Opening rule: first paragraph states the answer or the outcome. Second paragraph states scope: who this helps, what it covers, what it leaves out. No throat-clearing history of the topic before the answer.
• One idea per paragraph. Most paragraphs run one to three sentences on the web.
• Plain language rules from federal plain language guidance: average near 20 words per sentence, active voice, subject near the start of the sentence, common words over formal substitutes (use, not utilize; start, not commence), address the reader as you.
• Put steps in numbered lists, options in bullets, and comparisons in a small table. Lists are for scanning, not decoration.
• Show first-hand evidence where the topic calls for it: a photo from the actual work, a number from your own test, a short quote from a person you spoke to. Label opinion as opinion.
• Leave markers while drafting instead of stopping: [SOURCE?], [PHOTO: step 3], [CHECK SIZE]. Clear every marker before the editing passes end.

4. Run the editing passes, in order, one job per pass

Do not try to fix everything in one read. Each pass has one job. Full checklists are in references/editing-passes.md.

1. Structure pass. Headings alone should tell the story. Read only the title, headings, and first sentence of each section. If that skim makes no sense, reorder or cut sections before touching sentences.
2. Accuracy pass. Check every number, date, name, quote, and claim against its source. Unverifiable means cut it or rewrite it as a clear opinion. Check that links point where the text says they point.
3. Cut pass. Remove any paragraph that does not serve the promise in the brief. Cut filler openers, repeated points, and background the reader did not ask for. A common working target is to cut 10 to 20 percent of a first draft, but the test is function, not a quota: if a sentence earns its place, it stays.
4. Sentence pass. Shorten long sentences, split sentences with two jobs, replace passive voice where the actor matters, swap formal words for plain ones, read the post aloud and fix every place you stumble.
5. Reader pass. Read as the named reader from the brief. Mark every place they would ask "so what" or "how do I know that". Answer, cite, or cut at each mark.

5. Apply basic SEO, without distorting the post

Use references/seo-basics-for-posts.md for the full list. The short version, grounded in Google Search Central guidance:

• Title element: unique, descriptive, concise, in the reader's words. Google sets no fixed character limit; the title gets truncated to fit the device, so put the key words early and the site name last.
• Visible heading (H1): match the title in intent, one per post. Headings below it follow the outline order, one level at a time.
• Meta description: one or two sentences that summarise the post honestly. Write it, and accept that Google may show a snippet from the body instead.
• URL: short, descriptive words separated by hyphens. Keep it stable after publishing.
• Body: use the words readers use, in natural places. No keyword stuffing, no repeated exact phrases in every heading.
• Internal links: link to two or three related posts on the same site where the link helps the reader, with anchor text that describes the target. Add links from older related posts back to the new one after it publishes.
• Images: place them near the text they support, write descriptive alt text for readers who cannot see them, and keep file sizes sensible so the page loads fast on a phone.
• No word count target. Google states it has no preferred word count. Write to the length the question needs, then stop.

6. Run the publish checklist

Run the checker on the draft file, then work through references/publish-and-distribution.md:

python3 ~/workspace/skills/blog-post-production/bin/check_post.py draft.md --title "Fix a Leaky Kitchen Faucet With One Wrench"

The checker reports word count, heading order, long paragraphs, long sentences, leftover markers, and missing frontmatter fields. It warns; it does not pass or fail the post for you. Fix warnings that matter, note any you accept on purpose, then check by eye: preview on a phone width, test every link, confirm the byline and date, confirm any needed automation disclosure, and set the canonical URL if the platform asks for one.

7. Distribute on a plan, then close the loop

• Publish is the midpoint. Work the distribution list in references/publish-and-distribution.md on publish day: site newsletter or feed, one tailored post per social channel you actually use, a note to anyone quoted or linked, and a reply plan for comments in the first day.
• Rewrite the share text per channel. The same copy pasted everywhere reads as spam and fits none of them. Lead each share with a useful line from the post, not the title alone.
• After a week, record what happened in the brief file: views if you have them, replies, links earned, questions readers asked. Turn repeat questions into the next post brief or an update to this one.
• Update a post only when there is a real change: new facts, a fixed error, a better example. Do not change the date alone to look fresh. Google guidance treats date-only changes as no real update.

Output Contract

For a production run, return:

1. The brief, filled, with the structure pattern named and the Who, How, Why check answered.
2. The outline, as headings in order, before the draft.
3. The draft, clean, with no leftover markers, plus a list of claims cut for lack of a source.
4. The editing log: one line per pass, what changed.
5. Publish fields: final title, meta description, URL slug, alt text for each image, internal links added, and the call to action.
6. The distribution plan for publish day, with share text written per channel, and a date to review results.

Operating Rules

1. Every factual claim needs a source the writer checked. Never invent numbers, dates, quotes, or events. Unverifiable means cut it or label it as opinion.
2. One post, one reader question, one promise, one call to action.
3. The answer goes near the top. Burying the lead is a defect, not a style choice.
4. Editing passes stay separate and stay in order. Sentence polish never runs before the structure and accuracy passes.
5. SEO serves the reader's words. No keyword stuffing, no word count target, no date-only refresh.
6. Show first-hand evidence where the topic demands it. A review or how-to with no sign anyone did the work is not ready.
7. Disclose automation or assistance where a reader would reasonably want to know how the post was made.
8. Distribution is part of the job. A post with no share plan is half finished.

References

• Structure patterns: five post shapes, when each fits, and heading skeletons for each.
• Editing passes: the five passes as checklists, with before and after examples.
• SEO basics for posts: title, headings, description, URL, links, and images, tied to Google Search Central guidance.
• Publish and distribution: pre-publish checks, publish-day distribution, and the one-week review.
• Post brief template: the brief to fill before drafting.