菜单
This skill should be used when the user asks to "turn this lab into a blog post", "write a blog post from this module", "generate a blog from my Showroom content", "convert my workshop to a blog", "write a Red Hat Developer blog post", or "create a blog post from my demo".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
This skill should be used when the user asks to "create a catalog", "build a common.yaml", "add a new RHDP lab", "set up a new catalog item", "create an AgnosticV catalog", "build a dev.yaml", "add a catalog entry", or "create a new lab catalog for RHDP".
This skill should be used when the user asks to "validate my catalog", "check my AgnosticV config", "review common.yaml", "validate my RHDP catalog", "check for errors in my catalog", "lint my AgnosticV files", or "verify my catalog before submitting".
This skill should be used when the user asks to "create a demo module", "write a Know/Show demo", "build a presenter demo", "create a Showroom demo", "write a facilitator guide", "build a demo script", or "create a presenter-led demo for RHDP".
This skill should be used when the user asks to "create a lab module", "write a workshop module", "build a Showroom lab", "convert docs to a lab", "write a hands-on exercise", "create an AsciiDoc module", or "turn this documentation into a lab exercise".
This skill should be used when the user asks to "write solve and validate playbooks", "add E2E testing to my lab", "generate solve.yml", "generate validate.yml", "add solve and validate buttons", "set up runtime automation", "add ZT grading to my lab", "set up load testing for my lab", "add Demolition grading", or "configure run_e2e_load_test".
Infrastructure Health Checker — use this when you need to validate that a workload or service DEPLOYED SUCCESSFULLY (pods running, routes accessible, dependencies ready). This is NOT for student E2E lab testing. For student exercise validation (solve/validate buttons), use /ftl:rhdp-lab-validator instead. Triggers on: 'create a validation role', 'build health checks', 'add deployment validation', 'create post-deployment checks', 'validate my deployment', 'check if my workload is healthy'.
| name | showroom:blog-generate |
| description | This skill should be used when the user asks to "turn this lab into a blog post", "write a blog post from this module", "generate a blog from my Showroom content", "convert my workshop to a blog", "write a Red Hat Developer blog post", or "create a blog post from my demo". |
Orchestrates agents to transform completed Red Hat Showroom lab or demo content into blog posts for Red Hat Developer, internal blogs, or marketing platforms.
This skill is an orchestrator. Transformation and review are delegated to agents:
showroom:file-generator (Sonnet) — reads source .adoc files, transforms to blog Markdownshowroom:module-reviewer (Sonnet) — quality check on generated blog postSee @showroom/docs/SKILL-COMMON-RULES.md for source traceability and attribution rules.
Let's set up your blog post. Answer what you know:
Source modules (file paths to completed .adoc modules — can be multiple):
Target platform:
1. Red Hat Developer (developers.redhat.com)
2. Internal Red Hat (Source, Memo, The Stack)
3. Medium / dev.to / Hashnode
4. Marketing / announcement
Blog type:
1. Technical tutorial ("How to...")
2. Product announcement ("Introducing...")
3. Thought leadership ("Why...")
4. Case study / success story
5. Quick start guide
Technical depth:
1. Highly technical (code-heavy, for developers)
2. Moderately technical (balanced)
3. Marketing-focused (business benefits, light on code)
Target word count: 500-800 / 1000-1500 / 2000+ (or leave blank for auto)
Showroom link for "Try it yourself" CTA (optional):
Writing style (optional — skip for standard Red Hat technical blog style):
Describe: "storytelling-first, relatable analogies, humor where appropriate"
OR paste 1-3 paragraphs from a blog post you wrote
OR give a URL to a published post you authored
Saved profile? Point to: ~/.claude/context/my-writing-style.md
Confirm in one line:
📋 Blog plan: [type] for [platform] — [depth] — [word count]
Source: [N modules]
Generating blog post...
Task tool:
subagent_type: showroom:file-generator
prompt: |
TARGET_FILE: <output path, e.g. blog-post.md>
FILE_TYPE: blog
CONTENT_TYPE: <workshop|demo>
LAB_TYPE: <ocp|rhel|vm|ai|unknown>
REPO_PATH: <repo root if known, else none>
FULL_SPEC:
source_files: [<list of .adoc paths>]
blog_type: <tutorial|announcement|thought-leadership|case-study|quick-start>
platform: <redhat-developer|internal|medium|marketing>
technical_depth: <highly-technical|moderately-technical|marketing-focused>
word_count: <500-800|1000-1500|2000+>
showroom_link: <URL or null>
lab_name: <auto-detected from source>
The file-generator agent applies blog-specific quality checks internally. After it returns, verify:
Fix any issues inline before delivering.
✅ Blog post generated: <filename> (<word_count> words)
Quality: 0 Critical, 0 High, N Warnings
[list warnings if any]
Platform guidance:
Red Hat Developer: Submit at developers.redhat.com/write-for-us
Internal: Post to Source or Memo
| Source | Blog type | What changes |
|---|---|---|
| Workshop | Tutorial | Exercises → narrative how-to, keep code |
| Workshop | Quick start | First module only, condensed |
| Demo Know | Announcement | Business value extraction |
| Demo Show | Case study | Capability walkthrough |
| Any | Thought leadership | Patterns + trends, minimal code |
/showroom:create-lab — create workshop content/showroom:create-demo — create demo content/showroom:verify-content — verify content quality