planned-content git:20261001.4a48249A

Immutable. This exact content never changes and is served at /api/v1/blob/4ffe272babc6fa42.

---
name: planned-content
description: Assess current coverage, then draft only useful, fact-grounded planned content.
---

1. Read the exact brief, buyer intent, action, destination and verification requirements in
   the run context. Separate observed product facts from keyword opportunity hypotheses.
2. Read the project writing guide when present. Use its rhythm, structure and editorial
   preferences without treating style as factual evidence. Explicit direction can refine
   expression but cannot override output ownership or invent claims.
3. Inspect relevant durable context and current authoritative public sources. For existing
   pages, understand their purpose before proposing replacement copy. Preserve supported
   capabilities and useful information; do not turn a documentation update into a sales essay.
4. Decide whether the brief is still worth executing. Compare actual current coverage, not
   merely matching keywords. Record the reader gain and bounded change, or a supported
   already-covered assessment. Missing evidence and a brief needing revision are distinct
   no-draft outcomes, not successful coverage. Do not invent a contribution to fill the calendar.
   Preserve unrelated page content on updates; a small addition never licenses deleting the
   rest of the API reference. Never replace one planned item with another inside this run.
5. For a justified draft, develop one clear contribution for the buyer. Prefer concrete mechanisms and examples to
   promotional claims. Mark hypothetical examples as hypothetical. Avoid repetitive SEO
   introductions, keyword stuffing, invented experience and unsupported promises.
6. Edit the draft for clarity, transitions, useful headings and a proportionate conclusion.
   Cite factual claims near the supporting links. Sources that merely mention a topic do not
   establish product behavior, pricing or outcomes.
7. Keep the article clean. Put source frontmatter, editorial judgment and requirement accounting in the separate
   generation-notes file. Missing factual evidence means omitting or qualifying claims, not
   inventing them or starting an unbounded research loop. Live product testing is outside this
   writing workflow: no credentials, accounts, registration or real sends. Carry even explicit
   live-test requests in older briefs as optional follow-ups, not draft blockers. Distinguish
   documentation-grounded examples and local checks from examples actually executed live.
   Review concerns article copy only; no-draft assessments have no approval or delivery.
   The companion notes are available as internal context.


Before broad research, inspect the exact destination and nearest competing page. If they already
answer the intent, save an already-covered assessment immediately; do not pay for a replacement
article. For a genuine gap, save an argument outline in the declared generation-notes file
before writing: buyer decision, direct answer, the project's positioning (from the files in
`content_draft.positioning`, never the plan's), proof, objection, next step.
Use that outline to remove tangents. Reuse verified project evidence and read focused excerpts
before whole files. Record dated official competitor facts in the notes. Compare total costs on
like-for-like usage and distinguish customer-owned from provider-operated hardware. Never infer
missing capability from silence. Keep notes and process details outside customer-facing copy.