# Blog Post > Write one long-form blog post end to end -- keyword selection, structure, draft, and a mechanical check before publishing. Use for "write a blog post", "turn this into an article", "find a keyword for this", "what should I title this", "draft the post for this topic", or when handed a brief, a link pile, or notes and asked to make an article out of it. Also handles the handoff prompt when the post will be pasted into a CMS editor by another tool. Instagram carousels are carousel-post; verifying the facts first is topic-brief. - Skill: `chanuk0/blog-post` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add chanuk0/blog-post` - Raw SKILL.md: https://api.skillmd.com/api/skills/chanuk0/blog-post/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: chanuk0 (https://skillmd.com/u/chanuk0) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/chanuk0/blog-post --- # Blog Post Builds one post. The post is both **an asset that earns search traffic** and **the place your social links land**, and those two readers behave very differently — `references/writing-rules.md` opens with how to serve both in one page. ## Mode | Request | Mode | | --- | --- | | The post will be pasted into a CMS editor by a browser agent | **handoff** | | Everything else | **draft package** | ## Procedure ### 1. Topic and keyword Get the source material. Prefer a `topic-brief` output; otherwise the links, text, or files the user provides. **If there is no input, do not invent one** — ask. Read `references/keyword.md` and choose a focus keyword and title candidates. If the user supplies a keyword, it is fixed as the primary — don't second-guess it. Titles are a promise first; verified keywords get bundled in only where they read naturally. ### 2. Facts and status Take facts from primary sources only: the official page, the public notice, the regulation, the disclosure, the first-party document. Benchmarks and search results are for structure and keyword research — **never** for eligibility, amounts, deadlines, or steps. Values you can't confirm come out. If the post walks someone through applying for something, **actually open the official site** and confirm the menu names, the order of steps, what they need to hand, and how they know it worked. If you couldn't verify a deep link, use the site's home page in the call to action — and start the walkthrough from that same first screen. Label every key value: `in force` / `passed, not yet in effect` / `announced, not final` / `under discussion` / `unsupported`. If you see any sign of a revision, amendment, new scheme, or second round, read `references/status.md` and go find a **separate** source for the current rules and for the change. Interrogate any number that's making the rounds. Is it the actual rate, or a blended figure, or the maximum, or one worked example? Name it correctly. ### 3. Structure Read `references/patterns.md`. Choose **one** primary pattern and add only the supporting modules you need. Don't blend two patterns — if they overlap, pick based on what the reader does after reading, and keep that pattern's ending. ### 4. Draft in three passes Read `references/voice.md`, then `references/writing-rules.md`. 1. **Fact map** — every claim gets a value, a status, a checked-on date, and a primary source. 2. **Reader-decision map** — what they'll misunderstand, what they're deciding between, what changes by situation, what to do now versus later. 3. **Sentences** — connect the first two maps in the voice from `voice.md`. **Do not start by writing finished sentences.** That produces either a list of facts in paragraph form or friendliness with nothing underneath. For posts about money, tax, policy, or public programs, use the disclosure templates in `writing-rules.md`: a short scope note at the top, a detailed one at the bottom carrying the checked-on date and who decides what. Don't repeat generic disclaimers mid-article. ### 5. Check ```bash python scripts/check_post.py --pattern --title "" --keywords "<verified,keywords>" ``` Add `--slug` once the slug is set, `--featured <path>` if you made a lead image, and `--handoff <file>` in handoff mode. Those three fail in different places from the body HTML, so they're checked separately. For a draft you haven't written to a file, pipe the HTML and pass `-` as the path. ```bash cat draft.html | python scripts/check_post.py - --pattern <pattern> --title "<title>" ``` Both commands assume you're in this skill's folder. From elsewhere, call `python skills/blog-post/scripts/check_post.py ...`. **"Couldn't find the script" and "failed the check" are different outcomes — report them differently.** Fix and rerun until it passes. **If you didn't actually run it, write `not run` and why — never `passed`.** The script only sees what a script can see; finish by reading the draft against the quality bar in `references/writing-rules.md` yourself. ### 6. Output Produce the mode's output, below. ## Conflict order 1. Facts verified against primary sources, their status, user instructions, safety 2. The reader-centered voice in `voice.md` 3. The primary pattern's ending and its supporting modules 4. Markup, disclosure, and ad rules in `writing-rules.md` 5. Any individual example's phrasing Examples demonstrate principles. Never reuse an example's figures, claims, or personal anecdotes as if they were facts. ## Search visibility Public posts are indexable by default. Do not put `noindex`, `no-index`, or any search-exclusion instruction into the body, the SEO fields, or the handoff prompt unless the user explicitly asks for it. **Publishing and indexing are different axes.** "Save it as a draft" defers publication; it does not mean "hide from search". Don't expand a hold-off instruction into an index block — in most CMSs the robots setting is stored per post and survives until publication. Never damage a sentence for SEO. You control exactly four fields: - One focus keyword - A natural title carrying verified keywords - The meta description - The slug — rules in the `Slug` section of `references/keyword.md`. Never leave a non-ASCII title as the URL If the research supports it, bundle three to five verified keywords into the title naturally. If that reads badly, drop to one or two and say why. Don't then sprinkle those words through the body. If your CMS shows an SEO score, measure it in the browser. Raise it by adjusting the title, meta, slug, links, and image alt text — never by padding the body or stuffing keywords. If you didn't measure it, call it a target, not a result. ## Output -- draft package 1. Primary pattern / supporting modules used / why / benchmarks read 2. Title, focus keyword, meta description, slug - Which keywords are bundled into the title, and the evidence for each - If fewer than three, say whether it was readability or weak evidence 3. Body HTML 4. Lead image — an actual file, or a source you have permission to use, plus alt text and attribution. Follow the `Lead image spec` in `writing-rules.md`; don't invent a new style per post 5. In-body image plan — position / content / source / alt text 6. Calls to action and links — official sources, internal link positions 7. Short promo message, if the post is going out on a channel 8. Check results — script output plus anything held back on facts, status, or upload ## Output -- handoff Use the template in `references/handoff.md` verbatim. Fill the bracketed slots and change nothing else. **Don't compose the prompt freehand** — when it varies per post, instructions go missing, and missing instructions become publishing accidents. Check the prompt itself before you hand it over: ```bash python scripts/check_post.py <html> --pattern <pattern> --title "<title>" \ --keywords "<keywords>" --slug "<slug>" --featured <image> --handoff <prompt file> ``` Never invent a URL, never call a failed upload a success, and never instruct anything to publish without the user's explicit go-ahead. ## Boundaries - Publish only when the user explicitly asks. - Don't turn a post into personalized legal, financial, medical, or investment instructions. - Verified information, real product names, neutral comparisons, worked examples, general decision criteria, and official links are all fine.