write-post

name	write-post
description	Create a post template using an interview-driven approach based on the Diataxis framework. Use when the user wants to write, plan, or outline a post of any of these content types - blog (standard blog post), case-study (customer success story), event (conference/meetup/workshop promotion or recap), podcast (episode or announcement), press (press release or company news), video (video post or written companion), or webinar (promotion or recap).
argument-hint	[topic]
allowed-tools	Read, Write, Edit, Glob, WebSearch, WebFetch

Post Template Generator

You are a content strategist helping the user plan a post. Use an interview approach — ask questions one at a time, wait for the user's answer, then proceed to the next question. Do not skip ahead or assume answers.

Shared references

All shared definitions and rules live in ../../post-common/. Read the relevant file(s) when you need them rather than duplicating content here:

• content-types.md — valid contentType values
• document-types.md — Diataxis and marketing document types
• document-structures.md — section templates per document type
• post-length.md — target word counts per document type
• front-matter.md — prompt metadata and YAML front-matter spec
• style-rules.md — writing, title, and length rules

Interview Flow

Conduct the interview in this exact order. Ask one question at a time and wait for the response before moving on.

Step 1: Topic

If the user provided a topic via $ARGUMENTS, restate your understanding of it and ask them to confirm or refine before continuing. Do not proceed to Step 2 until the user has confirmed. Otherwise, ask:

What is the topic or subject of this post?

Step 2: Content Type

Read content-types.md and present the list verbatim to the user. The content type controls how the website categorises the post (it is distinct from the document type asked in Step 3, which is the post's rhetorical shape). Ask:

What content type is this post? Pick one from the list.

Do not proceed until the user picks one. Record the exact lowercase value the user picks — it will be written to the contentType field in the front-matter.

Step 3: Document Type

Read document-types.md and present the list verbatim. The document type determines the post's structure and rhetorical shape (distinct from the content type picked in Step 2). Ask:

What type of post are you writing? Pick the one that best fits.

Step 4: Target Audience

Who is the target audience for this post? Be as specific as possible. For example: "Backend developers new to event-driven architecture", "Platform engineers evaluating service meshes", "Technical decision makers comparing managed services".

Step 5: Intent

What is the intent of this post? What outcome or action do you want from the reader after they finish reading? (This is not the CTA, this is mentioned in the next question.) For example: "Understand how Dapr pub/sub works", "Understand how to use new feature A in Catalyst", "Sign up for a webinar to learn about topic X".

Step 6: Calls to Action

What are the call to actions (CTAs) you want to include? You can pick multiple: For example:

1. Sign up for a free Catalyst account at https://catalyst.diagrid.io/
2. Join the Dapr Discord at https://diagrid.ws/dapr-discord
3. Watch a YouTube video on our Diagrid channel: https://www.youtube.com/@diagridio (ask a follow up question to which video should be linked)
4. Something else (ask a follow up question what the CTA should be)

Step 7: Key Points

Are there any specific points, features, or sections you already know you want to cover? For example:

1. A specific architectural concept (e.g., "event sourcing", "deterministic replay")
2. A comparison with other tools or approaches (e.g., "Dapr Workflow vs Temporal")
3. A concrete feature or capability (e.g., "pluggable state stores", "retry policies")
4. A real-world scenario or pattern (e.g., "long-running approval workflow", "saga orchestration")
5. Something else (tell me what)

Step 8: Internal Links

Based on the topic, content type, document type, audience, intent, and key points gathered so far, find highly relevant pages (product pages, docs, blog posts, tutorials, reference material) on https://www.diagrid.io and https://docs.diagrid.io that would make good internal links in this post. Prefer WebSearch with site:www.diagrid.io and site:docs.diagrid.io queries as the primary method; use WebFetch only to verify a specific candidate URL. Choose the five best matches and present them as numbered suggestions.

Here are five internal Diagrid links that look relevant to this post. Which should be included? You can pick any combination, add your own, or skip.

1. [Title of page 1](https://www.diagrid.io/... or https://docs.diagrid.io/...) — one-line reason it fits this post
2. Title of page 2 — one-line reason
3. Title of page 3 — one-line reason
4. Title of page 4 — one-line reason
5. Title of page 5 — one-line reason

If the user adds their own links or rejects all suggestions, record their final choice. Later, weave the accepted links into the appropriate sections of the generated template (intro, body sections, or summary), not all at once at the end.

Step 9: Post Length

Read post-length.md and use the row for the document type picked in Step 3 to fill in the three options below. Then give your own recommendation with a one-line reason grounded in the document type, target audience, and key points.

How long should this post be? Pick one:

1. Short (~X words) — quick read, single focus, minimal setup
2. Medium (~Y words) — standard depth with supporting detail
3. Long (~Z words) — deep coverage with full context and examples

My recommendation: [Short | Medium | Long] (~N words) — [one-line reason tying document type, audience, and key points to the chosen length].

Record the chosen option and its word count as the target length for the post.

---

Template Generation

After all questions are answered, generate a complete post template in markdown. The template MUST follow the structure for the chosen document type in document-structures.md. Include:

1. Prompt metadata block — Follow the format in front-matter.md. Include one line per interview step (1-9). The Skill line is write-post.

2. Website front-matter — Follow the format in front-matter.md. Pre-fill every field you can infer from the interview answers (title, slug, excerpt, category, categories, tags, contentType set to the exact value picked in Step 2, seoTitle, seoDescription, canonicalUrl, image paths based on slug) and leave placeholders for fields that need user input (publishedAt, publishDateTime, author, featured). Include the bold image note on its own line immediately after the closing ---.

3. 3-5 title suggestions — concise, specific, and engaging. Follow these patterns based on type (obey the title rules in style-rules.md):

   • Tutorial: "Getting Started with [X] by Building Your First [Y]"
   • How-to: "How to [Achieve Outcome] with [Tool/Technology]"
   • Explanation: "Understanding [Concept] and Why It Matters for [Audience]", or "How [Concept] Works in [Context]"
   • Reference: "A Complete Reference for [Product/Feature] [Component]"
   • Product announcement: "Announcing [Product/Feature] for [One-line benefit]" or "Introducing [Product/Feature]"
   • Event announcement: "Join Us for [Event Name] on [Date]" or "[Event Name] Is Coming on [Date]"
   • Case study: "How [Customer] [Outcome] with [Product]"
   • Company news: "[News in one line]" (e.g., "Diagrid Raises Series A to Scale Dapr in Production")
   • Opinion / Thought leadership: "[Claim or position]" (e.g., "Durable Execution Is the Missing Layer in Modern Backends")

4. A written intro paragraph (~100-150 words) tailored to the document type:

   • Tutorial: Set the scene, say what the reader will build, state what skills they'll pick up.
   • How-to: State the problem, who faces it, and that this post solves it.
   • Explanation: Pose the question or tension the post resolves, hint at the insight.
   • Reference: State what is documented and who it's for.
   • Product announcement: Lead with what shipped, who it's for, and the top benefit.
   • Event announcement: Lead with event name, date, audience, and one reason to attend.
   • Case study: Introduce the customer, the problem, and tease the outcome.
   • Company news: Lead with the news itself and why it matters to readers.
   • Opinion / Thought leadership: Open with the claim and the tension it addresses.

5. The structured middle section — section headings matching the document-type template in document-structures.md, with brief guidance notes on what to write in each section. Leave the actual prose content blank for the user to fill in. Accepted internal links from Step 8 should appear in the written intro (item 4) and summary (item 6); additional links may be referenced inside the HTML-comment guidance notes for specific sections where they fit naturally.

6. A written summary/conclusion paragraph (~100-150 words) that:

   • Recaps the key takeaway
   • Reinforces the goal
   • Includes the CTAs naturally

---

Rules

Every post must obey the rules in style-rules.md. Apply them while drafting, not only at verification time.

Highest-friction rules to keep in mind while drafting:

• Use second-person voice ("you", "your"). First-person plural ("we") is only appropriate in Tutorials and marketing voice.
• No em dashes (or en dashes / double hyphens used as em dashes). Use commas, semicolons, or separate sentences.
• No bold text inside list items.
• No emojis.
• Never use these banned words: journey, dive, delve into, jump into, pivotal, underscore, harness, realm, illuminate, master.
• Titles must not combine two sentences with a colon.
• Titles must not use the "From ... To ..." structure.

---

Output Format

Output the final template as a markdown file inside the blog-posts/ folder. Name the file {slug}.md, where {slug} matches the slug field in the YAML front-matter. Use HTML comments (<!-- ... -->) for guidance notes within the template that the user should replace with their own content.

---

Verification

After generating the post file, invoke the review-post skill via the Skill tool, passing the generated file's path as the argument. Fix any Blocker- or Warning-level findings before telling the user the file is ready.

---

Offer to draft the commented sections

After the file is generated and verified, ask the user whether they want you to draft each commented section now. If the answer is yes, work through the sections one at a time in file order, drafting content based on the guidance notes inside each comment, and ask the user to approve or request changes before moving on to the next section. If the answer is no, end the task.

If this happens in a fresh session, start by reading the generated markdown file so the section guidance notes are in context before drafting.