---
name: blog-power
description: Write, structure, check and publish an article on a business's blog through the powers.now Blog power. Use when a person asks to write, draft, edit, structure, check, publish or unpublish a blog post, an article or a piece for their site, or asks what their blog says. The power validates with deterministic gates, versions, renders the page and the files agents read, and never calls a model; you write, the person approves.
---

# The Blog power

A post is one record: title, summary, Markdown body, a knowledge graph (typed entities with `sameAs`
links, edges, topics), claims that each cite a citation, the questions the article answers, three to
five takeaways, the actions a reader takes next. The same record renders as the page on the
business's own link, the writing card inside this chat and the files agents read (the feed, the
entries, the Markdown twin, llms.txt). Your job is the writing and the structure; the power's job is
the gates, the versions, the rendering and the syndication. A person approves; you never do.

## When to use this skill

- "Write about X", "draft a post on X", "turn these notes into an article".
- "Structure this", "add sources", "what questions does this answer".
- "Check the post", "why does the brand gate fail", "fix the SEO".
- "Publish it", "take it down", "what is on the blog", "find the post about X".

## Where the power is

- The blog: `{base}` (for powers.now: `https://dev.powers.now/blog/`). Guide: `{base}llms.txt`.
- The connector (MCP, Streamable HTTP): `{base}mcp`. As a guest it reads; the owner appends
  `?key=<owner key>` to the server URL to write. `references/connector.md` has the steps per host.
- No connector: `references/no-connector.md`: read the feed and the entries, then hand the person
  the deep link `{base}new?title=&summary=&bodyMd=&brief=` that pre-fills the editor for them to
  save, check, approve and publish.

## The procedure

1. **Brief.** Ask, or read from the conversation: audience, intent, the angle, what must be true,
   which sources to use. Write it into `brief` (never published). One paragraph.
2. **Research with citations.** Every factual claim needs a source you can link: the business's own
   pages, a standard's page, documentation. Note the URL, the title, the publisher, the date you read
   it and the sentence that supports the claim. No invented numbers, no synthetic data.
3. **Draft in the business's voice.** `create_post {title, summary, bodyMd, brief}` or
   `update_post`. Title 30 to 70 characters. Summary 70 to 170 (it is the meta description). Body in
   Markdown with sections starting at `##` (the title is the H1); short declaratives; second person;
   no exclamation marks in headings; none of the business's banned words (`brand.banned` in the
   manifest; for powers.now: seamless, leverage, unlock, cutting-edge, best-in-class, AI-powered,
   revolutionize). Every image carries alt text.
4. **Structure.** Call `suggest_structure {id}` for the deterministic extraction, then refine it
   with one `update_post`:
   - `graph.nodes`: the real entities (`Organization`, `Person`, `Product`, `Place`, `Concept`,
     `Event`) with a `sameAs` link each (the organisation's home page, the standard's page, the
     product's page); `graph.edges` for the relations; `graph.topics` (one to twelve).
   - `citations`: `{id, url, title, publisher, accessedAt, quote}` for every source.
   - `claims`: `{id, text, citationIds, status: "supported"}` for every factual claim; a claim without
     a citation fails the claims gate.
   - `questions`: at least two `{question, answer}` a reader or an assistant would ask; direct answers.
   - `takeaways`: three to five one-line answers an assistant can quote.
   - `actions`: what the reader does next (the business's default is set; add a `read` link when useful).
   `references/fields.md` has every shape.
5. **Check.** `check_post {id}` runs the gates and stores the report. Fix what fails, check again.
   `references/gates.md` says what each gate wants. A green check moves the draft to `needs_review`.
6. **Ask the person to approve.** Say: "Every gate is green. Approve it in the card or at
   `{base}edit/<slug>`." Do not call `approve_post`; it is refused for the assistant, and the
   power says so.
7. **Publish.** Once the post is `approved`: `publish_post {id}`. The answer carries the canonical
   URL; the feed entry is written; a run is recorded. Give the person the URL. `unpublish_post`
   reverses.

## Rules

- Read before you write: `get_post` gives the revision; every `update_post` carries it and a fresh
  `requestId`. A stale write is rejected; read again and decide, never revert a person's edit.
- A published post is a person's to edit; do not `update_post` it (unpublish first, or ask).
- Say what the gates said; do not claim a post is published until `publish_post` answered with the URL.
- Two runs count against the business's allowance: `suggest_structure` and `publish_post`. Reads,
  drafts, checks and the person's clicks never do.

## Tools, in one line each

`describe_ui` · `list_posts {status?, topic?}` · `get_post {id}` · `create_post {title, summary?, bodyMd?, brief?}` ·
`update_post {id, revision, requestId, patch}` · `suggest_structure {id}` · `check_post {id}` · `approve_post` (person only) ·
`publish_post {id}` · `unpublish_post {id}` · `search_posts {query}` · `export_post {id, format: markdown | feed}`.