Blog

Blog Writer

This skill transforms source content into SEO and AEO optimized blog posts. It supports five blog types, each with its own structure, word count, and CTA pattern.

Step 1: Select Blog Type

Before generating any content, ask the user:

What type of blog post do you need?

| Type | Best For | Target Length | |------|----------|---------------| | Feature announcement | Release notes, changelog, new capability | 800 to 1,200 words | | Product launch | New product, major release, rebrand | 1,200 to 1,800 words | | Thought leadership | Opinion piece, industry POV, contrarian take | 1,500 to 2,500 words | | Cookbook/tutorial | How-to guide, integration walkthrough, code example | 1,500 to 3,000 words | | Report conversion | Whitepaper, case study, research report → blog | 1,000 to 1,500 words | | News analysis | Breaking news, vulnerability disclosure, industry incident → expert take | 1,000 to 1,800 words |

Wait for the user to select before proceeding.

---

Authority Content Standard

Before gathering inputs, confirm the source content meets the Authority Content bar. Authority Content is what earns distribution on X, rankings on Google via LinkedIn Pulse, and citations from LLMs.

Authority Content must include at least one of:

• An original framework or model
• A contrarian take backed by data or direct experience
• A detailed breakdown of something the author actually built, tested, or measured
• A case study with specific numbers attached

It must not be:

• A repackaged "10 tips" listicle
• A summary of what everyone else is already saying
• Generic advice without a specific point of view

If the source content doesn't meet this bar, flag it: "This content reads as [generic/listicle/summary]. Authority Content needs a stronger point of view to earn algorithmic distribution and LLM citations. Can you share the original data, frameworks, or contrarian angle behind this?"

---

Step 2: Gather Inputs

Read from repo automatically:

| File | What to extract | |------|-----------------| | docs/inputs/product_brief.md | Product name, capabilities, limitations (for accuracy) | | docs/inputs/messaging_positioning.md | Positioning, value props, pain points | | docs/inputs/target_personas.md | Audience context, technical level, job titles |

Read these files BEFORE asking for additional inputs.

Then ask the user:

1. Source content — Provide the source material:

• File path (Markdown or PDF)
• URL to fetch
• Or paste the content directly

1. Target keyword — (Optional) What keyword should this post target? If not provided, suggest one based on the content.

1. Internal link domain — What domain should I pull internal links from? (e.g., beyondidentity.com/blog or docs.example.com)

1. Disclosure needed? — Does this post require a disclosure statement? (e.g., "Full disclosure: I work at [Company]")

1. Distribution surfaces — Which surfaces are you publishing to?

• [ ] Website/blog only
• [ ] Website + LinkedIn Pulse
• [ ] Website + X article
• [ ] All three (tri-publish)

If tri-publish or platform variants selected, generate platform-specific versions in Step 4.

Wait for answers before proceeding.

---

Step 3: Research and Context

Based on the blog type, perform targeted research:

For all types:

• Fetch 2 to 3 pages from the user's internal link domain to identify linking opportunities

For news analysis:

• WebSearch for the original source: the vulnerability disclosure, research paper, incident report, or news article
• Fetch the primary source in full (not just the headline)
• WebSearch for 2 to 3 additional takes or reactions from credible voices (security researchers, analysts, practitioners on X or LinkedIn)
• WebSearch for prior incidents, data points, or trends that contextualize why this news matters
• Check if your product brief addresses the problem space (for natural product tie-in, not forced)

For thought leadership:

• WebSearch for supporting evidence, recent statistics, or counterarguments
• Find reputable sources published within the last 2 to 3 years

For cookbooks/tutorials:

• WebSearch for current best practices, common pitfalls, related tools
• Verify any version numbers or API references are current

For report conversions:

• Read the full source document
• Identify the 3 to 5 most compelling findings to highlight

---

Step 4: Generate Blog Post

Generate the complete blog post following the type-specific structure below.

---

Blog Type Structures

Feature Announcement (800 to 1,200 words)

# [Feature Name]: [Benefit Statement]

**TLDR:** [2 to 3 sentences summarizing the feature and why it matters]

## The Problem

[What pain point does this feature solve? Who feels it?]

## Introducing [Feature Name]

[What the feature does. Be specific. Show, don't tell.]

[VISUAL: Screenshot or diagram of the feature in action]

## How It Works

[Technical explanation. Include code snippet if applicable.]

```[language]
// Example code with comments explaining each step

Use Cases

Each use case must highlight a DIFFERENT capability or behavior of the feature. If two use cases make the same point (e.g., "ephemeral credentials" applied to two different contexts), merge them into one or replace the duplicate with a use case that shows a distinct aspect of the feature.

[Use Case 1]

[Specific scenario where this feature helps. Emphasize the distinct capability exercised here.]

[Use Case 2]

[A different scenario that exercises a different aspect of the feature than Use Case 1.]

[VISUAL: Architecture diagram or workflow showing the feature in context]

Getting Started

[How to enable/access the feature. Link to docs.]

FAQ

[Question 1 phrased as user would ask]

[Direct answer first. Then elaborate.]

[Question 2]

[Answer]

[Question 3]

[Answer]

---

[CTA: Try it now / Read the docs / See it in action]

**CTA pattern:** Direct to docs or product, action-oriented

---

### Product Launch (1,200 to 1,800 words)

```markdown
# [Product Name]: [Positioning Statement]

**TLDR:** [3 to 4 sentences covering what it is, who it's for, and the key differentiator]

## The Shift

[What changed in the market to make this product necessary? The provocative insight.]

## What [Old Approach] Gets Wrong

[Why the status quo no longer works. Be specific about the failure mode.]

[VISUAL: Comparison table or diagram showing old vs new approach]

## Introducing [Product Name]

[Product description. What it is, what it does, where it fits.]

[VISUAL: Product screenshot or marketecture diagram]

## Key Capabilities

### [Capability 1]
[What it does and why it matters. Map to a specific pain point.]

### [Capability 2]
[Same structure]

### [Capability 3]
[Same structure]

## Proof

[Customer results or early adopter feedback. Use only approved testimonials.]

> "[Quote from customer]" — [Name], [Title] at [Company]

[VISUAL: Results chart or customer logo grid]

## Getting Started

[How to try it. Pricing context if relevant. Link to demo or signup.]

## FAQ

### [Question about pricing/availability]
[Answer]

### [Question about migration/compatibility]
[Answer]

### [Question about security/compliance]
[Answer]

### [Question about support/SLA]
[Answer]

---

**[CTA: Request a demo / Start free trial / Talk to sales]**

CTA pattern: Lead generation focused, offer next step in buyer journey

---

Thought Leadership (1,500 to 2,500 words)

# [Provocative Thesis Statement]

**TLDR:** [3 to 4 sentences stating the argument and its implications]

## The Conventional Wisdom

[What most people believe. Steel-man the opposing view.]

## Why That's Wrong

[Your contrarian take. Be specific about what the conventional wisdom misses.]

[VISUAL: Data chart or framework diagram supporting your argument]

## The Evidence

### [Evidence Point 1]
[Specific data, example, or case study. Cite source with hyperlink.]

### [Evidence Point 2]
[Same structure]

### [Evidence Point 3]
[Same structure]

## The Counterargument

[Acknowledge the strongest objection to your thesis. Address it directly.]

## What This Means

[Implications for the reader. What should they do differently?]

### For [Role 1]
[Specific implications]

### For [Role 2]
[Specific implications]

## The Path Forward

[Actionable recommendations. Be specific.]

[VISUAL: Maturity model, decision framework, or action checklist]

## FAQ

### [Question challenging the thesis]
[Defend with evidence]

### [Question about applicability]
[Scope the argument appropriately]

### [Question about next steps]
[Provide actionable guidance]

---

**[CTA: Related resource / Subscribe for more / Join the discussion]**

CTA pattern: Soft CTA, build relationship, encourage engagement

---

Cookbook/Tutorial (1,500 to 3,000 words)

# How to [Achieve Specific Outcome] with [Tool/Product]

**TLDR:** [What you'll build/achieve and the key steps involved]

## What You'll Learn

- [Outcome 1]
- [Outcome 2]
- [Outcome 3]

## Prerequisites

- [Requirement 1 with version number if applicable]
- [Requirement 2]
- [Access/permissions needed]

## Step 1: [Action Verb] [Object]

[Explanation of what this step accomplishes]

```[language]
// Step 1: [Description]
// This code does [explanation]
[code]

[VISUAL: Screenshot showing expected result after this step]

Step 2: [Action Verb] [Object]

[Explanation]

```[language] // Step 2: [Description] // Note: [Important caveat or tip] [code]

## Step 3: [Action Verb] [Object]

[Continue pattern for all steps]

## Testing Your Implementation

[How to verify it works. Include test commands or expected output.]

```[language]
// Verify the setup
[test code]

Expected output:

[expected output]

Troubleshooting

[Common Error 1]

Symptom: [What the user sees] Cause: [Why it happens] Fix: [How to resolve]

[Common Error 2]

[Same structure]

Next Steps

• [Related tutorial 1]
• [Advanced topic to explore]
• [Community resource]

FAQ

[Question about prerequisites]

[Answer]

[Question about alternatives]

[Answer]

[Question about production readiness]

[Answer]

---

[CTA: Try the advanced tutorial / Explore more integrations / Join the community]

**CTA pattern:** Continue the learning journey, link to related content

---

### News Analysis (1,000 to 1,800 words)

This blog type amplifies breaking security research, vulnerability disclosures, or industry incidents. You are the analyst, not the researcher. Your value-add is the technical breakdown, the pattern recognition across incidents, and the actionable guidance. Credit the original source prominently.

```markdown
# [Named Technique or Finding]: [What It Means for Your Audience]

**TLDR:** [2 to 3 sentences: what was discovered, by whom, and why your audience should care]

## The Discovery

[What was found and who found it. Credit the original researcher or team by name with a link to the primary source. Summarize the disclosure factually. Include dates, affected systems, and scope.]

> "[Key quote from the original researcher or advisory]" — [Source](URL)

## How It Works

[Technical breakdown of the attack, vulnerability, or finding. Explain the mechanism step by step as if the reader needs to assess whether they are affected. Use diagrams, code snippets, or configuration examples where they clarify the explanation. You are translating the research for practitioners, not restating the headline.]

```[language]
// Example showing the vulnerable pattern or attack mechanism
[code or config]

[VISUAL: Attack flow diagram or architecture showing the affected components]

Who Is Affected

[Specific systems, configurations, or deployment patterns that are vulnerable. Help the reader assess their own exposure. Be precise: name the frameworks, versions, cloud services, or architecture patterns.]

| Affected | Not Affected | |----------|-------------| | [Specific system/config] | [Specific system/config] | | [Specific system/config] | [Specific system/config] |

The Pattern

[Connect this finding to 2 to 3 prior incidents, disclosures, or trends. This section is your original analytical contribution. Show the reader this is not a one-off but part of a structural problem in how the industry builds or deploys.]

| Date | Finding | Researcher/Source | Impact | |------|---------|-------------------|--------| | [Date] | [Prior finding 1] | [Who] | [What happened] | | [Date] | [Prior finding 2] | [Who] | [What happened] | | [Date] | [Current finding] | [Who] | [What happened] |

What to Do About It

[Actionable remediation guidance. Be specific: configurations to change, tools to deploy, policies to implement. If your product addresses this problem, include it as one recommendation among several. Do not make the section a product pitch.]

Immediate (this week)

• [Action 1 with specific steps]
• [Action 2 with specific steps]

Strategic (this quarter)

• [Action 1]
• [Action 2]

FAQ

[Question about severity or scope]

[Direct answer first. Then context.]

[Question about whether reader is affected]

[Help them assess with specific indicators.]

[Question about remediation]

[Actionable steps.]

---

[CTA: Subscribe for future analysis / Related technical resource / Product capability if directly relevant]

**CTA pattern:** Newsletter or content subscription first. Product tie-in only when the finding maps directly to a capability. The reader came for the analysis, not a demo.

**Authority Content note:** News analysis meets the Authority Content bar when it adds context the original disclosure does not provide: a pattern across findings, a technical breakdown for a different audience than the original, or specific remediation guidance. Restating the news with a product pitch appended does not meet the bar.

---

### Report/Case Study Conversion (1,000 to 1,500 words)

```markdown
# [Key Finding]: [What We Learned from [Report/Study Name]]

**TLDR:** [The headline finding and its significance in 2 to 3 sentences]

## The Big Picture

[Context for the report. Why was this research conducted? What question did it answer?]

## Key Finding #1: [Finding Statement]

[Evidence from the report. Include specific numbers.]

[VISUAL: Chart or data visualization from the report]

> "[Compelling quote from the report]"

## Key Finding #2: [Finding Statement]

[Same structure]

## Key Finding #3: [Finding Statement]

[Same structure]

## What This Means for [Audience]

[Practical implications. What should readers do with this information?]

### Immediate Actions
- [Action 1]
- [Action 2]

### Strategic Considerations
- [Consideration 1]
- [Consideration 2]

## Methodology Note

[Brief description of how the research was conducted. Builds credibility.]

## FAQ

### [Question about methodology]
[Answer]

### [Question about applicability]
[Answer]

### [Question about accessing full report]
[Answer]

---

**[CTA: Download the full report / See how [Product] addresses these findings]**

CTA pattern: Gate the full content, offer product connection

---

Platform Variants

If the user selected LinkedIn Pulse or X article variants, generate these after the main blog post.

---

LinkedIn Pulse Variant

LinkedIn Pulse articles are indexed by Google (DR 98) and cited by LLMs at 4 to 5x the rate of a year ago. Optimize for search and LLM extractability.

Differences from website version:

• Add a **LinkedIn SEO title:** field (can differ from H1, max 100 chars, front-load keyword)
• Add a **LinkedIn meta description:** field (under 160 chars, keyword-rich)
• Add a **LinkedIn CTA:** at the end — drive comments, not clicks. Example: "What's your experience with [topic]? Drop it in the comments."
• Add an **Author bio line:** at the end: [Name], [Title] at [Company]. Verifiable pro

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: j1ngg
• Source: j1ngg/tech-marketing-framework
• License: MIT

Install and usage instructions live in the source repository linked above.