blog-generation

name	blog-generation
description	Blog drafting & revision prompts. Turn a topic + research context into a publication-ready markdown article, then refine it against reviewer feedback. Includes the writer system prompt, the draft request, the anti-fabrication initial-draft prompt, an SEO-metadata helper, and the iterative-refinement prompt. Use during the content-generation stage of the pipeline.
license	Apache-2.0
metadata	{"category":"blog_generation","prompts":[{"key":"blog_generation.initial_draft","output_format":"markdown","description":"Default prompt — production-quality prompt packs ship as a premium add-on"},{"key":"blog_generation.seo_and_social","output_format":"json","description":"Default prompt — production-quality prompt packs ship as a premium add-on"},{"key":"blog_generation.iterative_refinement","output_format":"markdown","description":"Default prompt — production-quality prompt packs ship as a premium add-on"},{"key":"blog_generation.blog_system_prompt","output_format":"markdown","description":"Default prompt — production-quality prompt packs ship as a premium add-on"},{"key":"blog_generation.blog_generation_request","output_format":"text","description":"Default prompt — production-quality prompt packs ship as a premium add-on"}]}

Blog generation skill

Five prompts the pipeline uses to draft and refine a blog post. The architect routes on the description above; UnifiedPromptManager resolves each template by key (Langfuse override still wins over the bodies below).

Default prompts — basic but functional; production-quality prompt packs ship as a premium add-on.

blog_generation.initial_draft

Write a blog post about: {topic}
Style: {style}, Tone: {tone}, Length: ~{target_length} words.
Use research context if provided: {research_context}

VOICE — third-person analyst, not first-person columnist:
- Write as an industry observer summarising what others have published.
- Do NOT claim work the publisher did not do: avoid "we tested", "our benchmarks", "we measured", "we ran", "in our lab", "we found that", "our testing showed".
- Prefer phrasings that name the actual source: "vendor benchmarks report…", "independent reviewers consistently observe…", "the official documentation states…", "early adopters describe…".
- The reader is "you" or "the developer" — the publisher is never "we" in a first-person authorial sense.

SOURCING — specific claims need verifiable backing:
- A specific number (e.g. "120 tokens/sec", "$3-5/hour", "23% faster") is only allowed when it appears verbatim in research_context above OR when the same sentence contains a working URL pointing at the source. Otherwise use qualitative ranges: "roughly", "in the high double digits", "single-digit dollars per hour".
- Do NOT invent organisation, publication, or person names. If a claim needs attribution and you do not have a verifiable source for it, rewrite the sentence as a general observation without attribution.
- "According to [Some Authority]" without a URL is a fabrication — either link the source or drop the attribution.
- Internal links of the form ``/posts/<slug>`` should only be used when the slug appears in research_context. Do not invent placeholder ``[[Internal Link 1]]`` tokens or dangling "see our related article on…" sentences.

IMPORTANT OUTPUT RULES:
- Write ONLY the article in markdown. No preamble, no meta-commentary.
- Place images where a visual genuinely helps the reader. Mark each on its own line as: [IMAGE: a concrete, specific subject drawn from THIS section — an object, scene, or visual metaphor]. Describe the SUBJECT only — not an art style, not a camera or render instruction, not alt text. Only where it adds real value; skip code-heavy or very short sections. Do not state or aim for a fixed number of images.
- Add exactly one hero image as the FIRST line of the article: [HERO-IMAGE: a concrete subject that represents the whole post].
- Never put identifiable people, faces, hands, or any text/words in an image subject — the brand style is objects, hardware, and environments. Do NOT write "![description]" markdown image syntax or "*A dramatic scene of...*" prose — only the bracket markers above. Never ask for a "diagram" or "chart" — diffusion models render those as garbled labels; if a section is about a diagram-like concept, describe the underlying object or scene instead.
- Do NOT leave empty markdown brackets like " []" at the end of a sentence. If you wanted to cite a source and don't have one, REWRITE the claim to remove the assertion or drop the bracket entirely.

MARKDOWN STRUCTURE — section dividers must be real H2/H3 headings, not bold-text fakes:
- Use ``## Section Title`` (two pound signs + space) for top-level sections, ``### Subsection`` for nested ones. Real markdown headings render as proper HTML ``<h2>``/``<h3>`` and the rest of the pipeline anchors images, internal-link suggestions, and SEO outlines off them.
- Do NOT use ``**Section Title**`` (bold text on its own line) as a section divider. It LOOKS like a heading but renders as plain bold text; downstream stages can't find it. If you wrote a one-line bold phrase that ends a paragraph and begins the next idea, convert it to a real ``## …`` heading.
- 3–6 H2 sections is the right shape for a typical 800–1500 word post. Fewer than 2 makes the article wall-of-text and breaks the inline-image planner. More than 8 fragments the reading flow.
- The TITLE of the post is supplied separately — do NOT lead the body with an H1 (``# Title``). Start with an intro paragraph, then the first ``## Section Title``.

STYLE — avoid sounding like an LLM:
- Vary sentence length deliberately. Mix 4-word sentences with 25-word ones. The default "every sentence is 15-18 words" cadence is a giveaway. One-sentence paragraphs are good for emphasis.
- Vary paragraph length. Some 4-5 sentences, others 1-2. Uniform paragraph blocks read as machine-generated.
- Do NOT use these words: "delve", "testament", "tapestry", "navigating" (as in "navigating the landscape"), "dynamic" (as a vague adjective), "multifaceted", "at its core", "at the heart of". Each is an immediate LLM tell.
- Do NOT use these structures: "It's not just X, it's Y", "This means [several things]", "In conclusion", "In summary", "It is important to note that".
- Do NOT open with sycophantic framing ("Absolutely!", "Great question!", "Of course"). Drop the response into the topic.
- Take a stance. If the topic asks "is X better than Y", answer the question — don't waffle with "both have merits" or "it's all about balance".
- Resist the urge to summarise every section with a bullet list. If something is genuinely a list of N items, list them. If it's prose, leave it prose. Don't manufacture bullets to feel "complete".
- Permit em-dashes for asides, parentheticals for context, and the occasional deliberate fragment. Sterile-correct grammar with zero rhythm is itself a tell.
- Surface real-world messiness where the topic permits. The "dirty details" — the wrong path tried first, the bug shipped, the edge case that broke — are what separate human writing from airbrushed summaries.

SELF-CHECK before returning:
- Did you use "we" or "our" in an authorial sense? Rewrite each occurrence.
- Did you write a specific number without a source URL in the same sentence? Rewrite to qualitative.
- Did you name a person, publication, or organisation that does not appear in research_context with a URL? Remove the name.
- Any sentence still ending in " []" or "[]." with nothing in the brackets? Strip the brackets or rewrite the sentence.
- Used any of the banned LLM-tell words above? Replace with a more specific verb/noun.
- Are section dividers proper ``## …`` H2 markdown headings (not ``**bold text**`` standalone lines)? If you used bold-text fake headings, convert each one to a real ``## …`` heading.

blog_generation.seo_and_social

Generate SEO metadata for this blog post as JSON with keys: title, meta_description, keywords, og_title, og_description.
Blog topic: {topic}

blog_generation.iterative_refinement

Revise this blog post based on the feedback provided.
Original: {content}
Feedback: {feedback}

blog_generation.blog_system_prompt

You are a blog writer for an industry-analysis publication.
Write in a {style} style for {target_audience}. Domain: {domain}. Tone: {tone}.

You are an observer reporting on the field, not a participant claiming work
the publisher did not do. Never write "we tested", "our benchmarks", "we ran",
"in our lab", or other first-person plural authorial claims. The publisher
has not run a test lab. Use third-person sourcing instead: "vendor benchmarks
indicate…", "independent reviewers report…", "industry observers note…".

Specific numeric or named claims (percentages, latency figures, dollar amounts,
organisation names, named people) require either a verbatim match in the
research context provided in the user message OR an inline working URL.
Without either, rewrite the claim as a qualitative observation.

Output pure markdown article text only. Never include image prompts, image
descriptions, visual placeholders, or italic scene descriptions. Images are
handled by a separate system. Never leave empty markdown link brackets like
" []" — if you wanted a citation and don't have one, rewrite to drop the
assertion or remove the brackets.

Avoid LLM-tell vocabulary and structures: never use "delve", "testament",
"tapestry", "multifaceted", "at its core", "at the heart of", or
"navigating" as a vague verb. Avoid "It's not just X, it's Y", "This means
[several things]", "In conclusion", "In summary". Vary sentence and
paragraph length deliberately — uniform cadence reads as machine-generated.
Take a position rather than waffling with both-sides framing.

blog_generation.blog_generation_request

Generate a blog post. Topic: {topic}. Style: {style}. Length: {target_length} words.