Context Blog — rules

These rules apply whenever an agent works on Context Blog content — blog posts, a site or landing page, Instagram posts — for a tenant (one brand, one site, e.g. getmeetly.ai). They sit on top of the Context harness (rules): everything there still holds (usage guide first, grill-me + wayfinder verbatim, one map + one combined gate, per-ticket documents, handoff before stopping). This file adds only what is blog-specific.

1. Two servers, one link

Hold both connections. You carry the link: every piece of content is one Context issue, and its id rides as context_issue_id on every Blog MCP call that accepts one. Call each server's usage_guide once per session, and get_capabilities on the Blog MCP before you rely on a content tool. Context stays thin: there are no server-side loops; every routine runs on the host that owns the workflow.

2. The three forks

Every Context Blog interview opens on three forks. Ask them, recommend, and record the answer in the decision record — never assume.

• WHAT — blog · site / landing page · Instagram — any combination.
• HOW OFTEN — once · recurring, with a cadence per channel.
• OUTPUT tier
  • Artifact — documents on the Context issue; the owner self-publishes.
  • Review & self-publish — Artifact + standing lanes, a schedule and the checker; the owner still publishes.
  • Hosted — Review + published on Context sites at the owner's domain, analytics and the AI-visibility probe.

Credential-less hosts (ChatGPT, claude.ai) can do everything except Instagram publishing and the AI-visibility probe; recommend Claude Code or Codex for the full loop. Say what this host can do as a fact (§8).

3. Label vocabulary

One Context issue per publish, one channel per issue. Native fields first: due = the publish time (publishAt, ISO 8601 with offset), parentId = the tenant epic, issueType: "complex". Labels, exactly these keys:

A locale variant is its own issue, linked relates to the EN master and carrying the same hub:/kind: labels. Title format: <Channel>: <title> (<locale>).

4. Checker gate — maker → blog-checker → human

No draft reaches the owner unchecked. Before any reviewRequest on a content issue, the issue must carry, attached or in its latest update:

1. the draft itself (send_file, docKind: "deliverable" for the final text, draft for intermediates);
2. the checker verdict — the blog-checker pass (facts against the brief, claims policy, voice adjectives, locale, structured data, links) with pass/fail per check and what the maker changed in response;
3. the rendered preview (docKind: "preview", self-contained HTML) or the Blog MCP preview URL;
4. the models used (maker, checker) in the update body and workStats.

Then one post_task_update {state: "in_review", reviewRequest: {reason, blocking: true}} and wait on get_events. Never assume approval. The maker and the checker must not be the same session prompt; a checker run is a separate call with the brief and the draft as its only inputs.

5. Publish gate

• publish (Blog MCP, or a Postiz/Instagram schedule) is called only for an issue whose Context state is done — approved through the gate above. Pass the issue id; the server refuses without it.
• EN master approval cascades: when the EN master is done, its locale variants may be published once their own checker verdict is attached and their state is done — locale variants are approved by the cascade, not by a second human read, unless the owner asked for per-locale review in the decision record.
• Publish at due, never earlier; a missed window is reported in the daily brief and re-slotted, never silently published late.
• Report the live URL on the issue, then complete_tasks with workStats.
• Refresh (kind:refresh) goes through the same gate as new.

6. Keys — names and scope only

Ask for key names and where they are kept; never a value, never "paste it here". If a value appears in chat, do not store, echo or use it — say so, name the key, and ask the user to put it in their host's secret store.

Interactive hosts authenticate to the Blog MCP with OAuth — no key needed.

7. Daily brief first

Any recurring workflow installs the daily-brief skill and its routine before any drafter, publisher or assessment routine, posting to the tenant epic's Daily Brief issue (brief:daily, lane:brief). A missing brief is the outage alert; there is no server-side fallback by design. Routine order: daily brief → drafter → publisher → assessment.

8. Graceful degradation by host

Discover, do not assume: get_capabilities on both servers, and what this host can run. If a Blog MCP tool the skill names is absent from get_capabilities.tools, say "not available yet on this server", attach the payload you would have sent as a document on the issue, and continue.

9. Safety and scope

• No invented facts, numbers, quotes or anecdotes: only what the brief, the owner's writing and fetched sources say; cite the source in the draft's notes. No medical, legal, financial or compliance claims (e.g. HIPAA) the owner did not explicitly approve in the decision record.
• One tenant per session; state it before any write.
• Never publish, schedule or delete outside the gates above; never change sharing of a map through MCP tools.
• Everything the reviewer needs lives on the issue, never only in chat.

Quick reference