| name | blog-generate |
| description | Transform completed Red Hat Showroom lab modules or demo content into blog posts for Red Hat Developer, internal blogs, or marketing platforms. |
Blog Generator
Transform completed Red Hat Showroom lab modules or demo content into blog posts for Red Hat Developer, internal blogs, or marketing platforms.
When to Use
Use this skill when you want to:
- Convert workshop modules into developer blog posts
- Transform demo content into product announcements
- Create marketing content from technical labs
- Repurpose Showroom content for broader audiences
Don't use this for:
- Creating new lab content → use
/create-lab - Creating new demo content → use
/create-demo - Editing existing blog posts → use technical-editor agent
Shared Rules
IMPORTANT: This skill follows shared contracts defined in .claude/docs/SKILL-COMMON-RULES.md:
- Reference enforcement (REQUIRED)
- Source traceability (REQUIRED for trust and attribution)
- Failure-mode behavior (stop if cannot proceed safely)
Blog generation does NOT directly create lab content, so some shared rules (version pinning, navigation updates, image paths) apply only to source modules.
See SKILL-COMMON-RULES.md for complete details.
Workflow
Step 1: Identify Source Content
I'll ask you:
Source modules:
- Which completed modules to base the blog on?
- Provide file paths (e.g.,
workshop/openshift-pipelines/03-module-01.adoc) - Can combine multiple modules into one blog
Source type:
- Workshop module (hands-on lab)
- Demo module (presenter-led)
- Both (combined perspective)
Step 2: Determine Blog Parameters
I'll ask:
Target platform:
- Red Hat Developer blog (developers.redhat.com) → Markdown
- Internal Red Hat blogs (Source, Memo, The Stack) → Markdown or AsciiDoc (will ask)
- Marketing/announcement format (product launches) → Markdown
- Medium, dev.to, Hashnode → Markdown
- Custom/Other → Markdown (default)
Output format (auto-selected based on platform):
- Markdown (.md) - DEFAULT for all platforms except specific internal use cases
- AsciiDoc (.adoc) - Only if explicitly needed for internal Red Hat tooling
Blog type:
- Technical tutorial ("How to...")
- Product announcement ("Introducing...")
- Thought leadership ("Why...")
- Case study/success story
- Quick start guide
Technical depth:
- Highly technical (code-heavy, for developers)
- Moderately technical (balanced, for technical managers)
- Marketing-focused (business benefits, light on code)
Blog parameters:
- Desired word count (500-800 / 1000-1500 / 2000+)
- Include code samples? (Yes / Minimal / No)
- Target audience level (Beginner / Intermediate / Advanced)
Step 3: Read Source Content
I'll:
- Read all specified module files
- Extract key concepts, procedures, commands
- Identify business value propositions
- Note technical highlights
- Capture screenshots/diagrams to reference
Step 4: Transform Content
Based on source type and target, I'll transform:
Workshop → Developer Blog:
- Convert step-by-step exercises → narrative "how to" flow
- Keep technical depth and code samples
- Add context and explanation
- Include "Try it yourself" CTA with Showroom link
Demo → Product Announcement:
- Extract business value from Know sections
- Highlight capabilities from Show sections
- Emphasize customer benefits
- Include competitive differentiators
Workshop → Marketing Blog:
- Focus on "what you can achieve" not "how to do it"
- Minimize technical steps
- Emphasize business outcomes
- Use executive-friendly language
Demo → Thought Leadership:
- Extract patterns and best practices
- Industry trends and challenges
- Strategic perspectives
- Minimal code, maximum insights
Step 5: Generate Blog Structure
DEFAULT OUTPUT FORMAT: Markdown (.md)
I'll create a blog post with:
For Technical Blogs (Markdown format):
# Building Cloud-Native CI/CD Pipelines with OpenShift Pipelines
> **Summary**: Learn how to create production-ready CI/CD pipelines using Tekton on OpenShift in under 30 minutes.
## Introduction
If you've struggled with complex Jenkins configurations or brittle CI/CD scripts, OpenShift Pipelines offers a cloud-native alternative. Built on Tekton, it brings Kubernetes-native CI/CD to your workflows with declarative pipelines that scale with your applications.
In this tutorial, you'll learn how to:
- Create reusable Tekton tasks
- Build complete CI/CD pipelines
- Integrate with Git repositories
- Deploy applications automatically
## What You'll Build
By the end of this tutorial, you'll have a working pipeline that:
- Builds container images from source code
- Runs automated tests
- Deploys to OpenShift automatically
Let's dive in.
## Creating Your First Tekton Task
Tekton tasks are the building blocks of pipelines. Here's how to create a simple build task:
\`\`\`yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-app
spec:
steps:
- name: build
image: maven:3.8
script: |
mvn clean package
\`\`\`
Apply this to your cluster:
\`\`\`bash
oc apply -f build-task.yaml
\`\`\`
This creates a reusable task that can be referenced in any pipeline. What makes this powerful is the ability to chain multiple tasks together...
## Building a Complete Pipeline
Now let's combine multiple tasks into a production-ready pipeline:
\`\`\`yaml
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: build-and-deploy
spec:
tasks:
- name: build
taskRef:
name: build-app
- name: test
taskRef:
name: run-tests
runAfter:
- build
- name: deploy
taskRef:
name: deploy-to-openshift
runAfter:
- test
\`\`\`
The `runAfter` fields ensure tasks execute in the correct order...
## Next Steps
You've built a working CI/CD pipeline with OpenShift Pipelines. From here, you can:
- Add Git triggers for automatic builds
- Integrate security scanning
- Create multi-environment pipelines
## Try It Yourself
Want hands-on practice? Try the complete workshop: [OpenShift Pipelines Workshop](https://showroom.example.com/pipelines)
## Resources
- [OpenShift Pipelines Documentation](https://docs.openshift.com/pipelines/)
- [Tekton Official Site](https://tekton.dev)
- [Example Pipelines Repository](https://github.com/...)
---
**About this tutorial**: This post is based on a hands-on workshop created for Red Hat field demonstrations. [Try the full lab on Red Hat Showroom](https://showroom.example.com/pipelines).
---
**Tags**: OpenShift, CI/CD, Tekton, Kubernetes, DevOps
**Author**: [Your Name]
**Published**: [Date]
For Marketing Blogs:
# [Benefit-Focused Title]
**Introduction**:
- Business challenge hook
- What this means for readers
- Value proposition
**The Challenge**:
- Current state pain points
- Industry context
- Why change is needed
**The Solution**:
- Product/capability overview
- Key benefits (not features)
- Customer success snippets
**Business Impact**:
- Quantified outcomes
- Strategic advantages
- ROI considerations
**Getting Started**:
- Simple next steps
- Resources available
- Support options
**CTA**:
- Request demo
- Try it yourself
- Contact sales
**Metadata**:
- Executive-friendly title
- SEO-optimized description
- Product tags
Step 6: Apply Platform-Specific Formatting
Red Hat Developer Blog (developers.redhat.com):
- Format: Markdown (.md)
- Code blocks with triple backticks and syntax highlighting
- Developer-focused tone
- Technical accuracy paramount
- Community engagement encouraged
- Example code blocks:
\`\`\`bash oc create deployment my-app --image=myimage:latest \`\`\` \`\`\`yaml apiVersion: apps/v1 kind: Deployment \`\`\`
Medium, dev.to, Hashnode:
- Format: Markdown (.md)
- Platform supports standard Markdown
- Add cover images (suggest or use from lab)
- Engage with canonical URLs
- Use platform-specific tags
Internal Red Hat Blogs (Source, Memo):
- Format: Markdown (.md) DEFAULT
- Format: AsciiDoc (.adoc) - Only if team requires it (will ask)
- Red Hat product naming standards
- Internal links to resources
- Team/org specific context
Marketing/Announcement Format:
- Format: Markdown (.md)
- Business language
- Minimal jargon
- Visual emphasis (suggest infographics in Markdown:
) - Customer success quotes
- Lead generation CTAs
- SEO-optimized headings
Step 7: Validate and Deliver
I'll:
- Run technical-editor agent for tone and clarity
- Run style-enforcer agent for Red Hat standards
- Verify all code samples are complete
- Check links and references
- Validate Markdown syntax
- Add source traceability attribution (REQUIRED - see below)
Source Traceability (REQUIRED):
Every blog must include attribution to prevent over-claiming and confusion about authoritative docs vs narrative content.
For Red Hat Developer Blog:
---
**About this tutorial**: This post is based on a hands-on workshop created for Red Hat field demonstrations. [Try the full lab on Red Hat Showroom](https://showroom.example.com/...).
For Internal Blogs:
---
**Source**: Adapted from the "OpenShift Pipelines" demo used in customer technical briefings.
For Marketing Blogs:
---
**About**: This article is based on technical demonstrations shown at Red Hat Summit and customer events.
Rules:
- Always include at end of blog, before tags/metadata
- Link to full lab if publishing externally
- Use "adapted from" or "based on" language, not "official documentation"
You'll get:
- Complete blog post file in Markdown (.md) - ready to publish
- Metadata section (title, description, tags, author)
- Image reference list (what visuals to create/include)
- SEO recommendations
- Platform submission checklist
- Code blocks properly formatted with syntax highlighting
Output location: blog-posts/<topic-slug>.md
If AsciiDoc requested (rare):
- Output:
blog-posts/<topic-slug>.adoc - Only when specifically needed for internal tooling
Transformation Examples
Example 1: Workshop → Developer Tutorial
Source (workshop exercise):
== Exercise 1: Create Tekton Pipeline
. Create a task definition:
+
[source,yaml]
----
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-app
----
. Apply the task:
+
[source,bash]
----
oc apply -f task.yaml
----
Output (blog narrative):
## Building Your First CI/CD Pipeline with Tekton
Tekton Pipelines brings cloud-native CI/CD to OpenShift. Instead of wrestling with
complex Jenkins configurations, you can define your entire build process as
Kubernetes-native resources.
Let's start by creating a simple build task. In Tekton, tasks are reusable building
blocks that define a series of steps:
\`\`\`yaml
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-app
spec:
steps:
- name: build
image: maven:3.8
script: |
mvn clean package
\`\`\`
Apply this task to your cluster with `oc apply -f task.yaml`, and you've just
created your first reusable CI/CD component. What makes this powerful is...
Example 2: Demo → Product Announcement
Source (demo Know section):
=== Know
_Customer challenge: Deployment cycles take 6-8 weeks, blocking critical business initiatives._
**Business Impact:**
* Development teams wait 6-8 weeks for platform provisioning
* Manual processes cause errors and rework
Output (marketing blog):
## Accelerating Time-to-Market with OpenShift
For many organizations, application deployment isn't just slow—it's a strategic
bottleneck. We've seen development teams wait 6 to 8 weeks just to provision
infrastructure, turning agile development into waterfall delivery.
OpenShift eliminates this bottleneck through self-service developer platforms that
reduce deployment time from weeks to minutes. Your developers get the infrastructure
they need when they need it, without manual ticket-and-wait processes...
Example Usage
User: Create a developer blog from my OpenShift Pipelines workshop modules:
workshop/openshift-pipelines/03-module-01.adoc
workshop/openshift-pipelines/04-module-02.adoc
Skill: I'll transform those modules into a developer blog. Let me ask...
Q1: Source modules? → [already provided]
Q2: Source type? → Workshop modules
Q3: Target platform? → Red Hat Developer blog
Q4: Blog type? → Technical tutorial
Q5: Technical depth? → Highly technical (for developers)
Q6: Word count? → 1500-2000 words
Q7: Include code samples? → Yes, comprehensive
Q8: Audience level? → Intermediate
[Reads both modules]
[Extracts: Tekton tasks, pipeline definitions, execution steps]
[Transforms exercises into narrative flow]
[Generates:]
✓ Created: blog-posts/openshift-pipelines-tutorial.md
✓ Format: Markdown for Red Hat Developer
✓ Length: ~1800 words
✓ Includes: 5 code examples, 3 screenshot references
✓ CTA: Links back to full Showroom workshop
✓ Metadata: Title, tags, description included
Tips for Best Results
For Technical Blogs:
- Keep code samples complete and tested
- Explain the "why" not just "what"
- Progressive disclosure (simple → complex)
- Link to full lab for hands-on practice
For Marketing Blogs:
- Lead with business value
- Use customer language, not product features
- Quantify outcomes where possible
- Include visual elements (suggest infographics)
General:
- One blog per major topic (don't combine unrelated modules)
- Maintain consistent voice throughout
- SEO-friendly titles and descriptions
- Platform-appropriate CTAs
Transformation Patterns
Workshop Exercise → Tutorial Section
Pattern:
- Introduce the capability (what and why)
- Show the implementation (code/commands)
- Explain the outcome (what it does)
- Connect to larger context (why it matters)
Don't:
- List steps 1, 2, 3 without narrative
- Include every verification command
- Use "Now we will..." repeatedly
Do:
- Tell a story with the code
- Explain decisions and tradeoffs
- Highlight insights and best practices
Demo Know Section → Blog Value Prop
Pattern:
- State the business challenge
- Quantify the pain (metrics)
- Introduce the solution
- Emphasize the transformation
Don't:
- Use generic marketing speak
- Overstate capabilities
- Skip the "why it matters"
Do:
- Use specific, credible numbers
- Connect to industry trends
- Show customer perspective
Quality Standards
Every generated blog will have:
- ✓ Engaging title (SEO-friendly)
- ✓ Strong introduction hook
- ✓ Narrative flow (not instructional steps)
- ✓ Platform-appropriate tone
- ✓ Complete code samples (if technical)
- ✓ Clear CTAs
- ✓ Metadata (title, description, tags)
- ✓ Red Hat style compliance
- ✓ Proper product naming
Platform-Specific Guidelines
Red Hat Developer:
- Developer-to-developer tone
- Hands-on and practical
- Open source friendly
- Community engagement focus
- Link to GitHub/docs generously
Internal Blogs (Source/Memo):
- Red Hat employee context
- Internal project references OK
- Team collaboration emphasis
- Process and culture relevant
Marketing:
- Executive language
- Business benefit focus
- Customer success stories
- Lead generation optimized
- Competitive positioning
Integration Notes
Agents invoked:
technical-editor- Refines tone and claritystyle-enforcer- Applies Red Hat standards
Output format:
- Markdown (.md) - DEFAULT for all platforms
- AsciiDoc (.adoc) - Only if explicitly needed (rare, internal Red Hat use only)
Why Markdown:
- Universal support: Red Hat Developer, Medium, dev.to, Hashnode, GitHub
- Easy to write and edit
- Excellent code block support with syntax highlighting
- Standard for blog platforms
- SEO-friendly
- Platform-agnostic
Output location:
- Default:
blog-posts/<topic-slug>.md - Example:
blog-posts/openshift-pipelines-tutorial.md - User can specify custom path