Menu
Guide you through creating a Red Hat Showroom demo module using the Know/Show structure for presenter-led demonstrations.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run comprehensive quality verification on workshop or demo content using Red Hat standards and validation agents.
Generate AgnosticV catalog description from lab or demo content for RHDP provisioning.
Guide you through creating a single Red Hat Showroom workshop module from reference materials (URLs, files, docs, or text) with business storytelling and proper AsciiDoc formatting.
Transform completed Red Hat Showroom lab modules or demo content into blog posts for Red Hat Developer, internal blogs, or marketing platforms.
| name | create-demo |
| description | Guide you through creating a Red Hat Showroom demo module using the Know/Show structure for presenter-led demonstrations. |
Guide you through creating a Red Hat Showroom demo module using the Know/Show structure for presenter-led demonstrations.
Use this skill when you want to:
Don't use this for:
/create-lab/blog-generate/verify-contentIMPORTANT: This skill follows shared contracts defined in .claude/docs/SKILL-COMMON-RULES.md:
See SKILL-COMMON-RULES.md for complete details.
Demos use a different format than workshops:
This separates what presenters need to understand (business value) from what they need to do (technical demonstration).
This skill supports optional command-line arguments for faster workflows.
Usage Examples:
/create-demo # Interactive mode (asks all questions)
/create-demo <directory> # Specify target directory
/create-demo <directory> --new # Create new demo in directory
/create-demo <directory> --continue <module> # Continue from specific module
Parameters:
<directory> - Target directory for demo files
/create-demo content/modules/ROOT/pages/content/modules/ROOT/pages/--new - Flag to create new demo (generates index + overview + details + module-01)--continue <module-path> - Continue from specified previous demo module
/create-demo content/modules/ROOT/pages/ --continue content/modules/ROOT/pages/03-module-01-intro.adocHow Arguments Work:
/create-demo with no argumentsCRITICAL RULES
Example of WRONG approach:
❌ Asking all at once:
1. Module file name?
2. Do you need AgV help? [1/2/3/4]
3. UserInfo variables?
4. Presentation objective?
5. Number of demos?
Example of CORRECT approach:
✅ Ask sequentially:
Step 2.5: Do you need AgV help? [1/2/3/4]
[WAIT for answer]
[If answer is 3, complete ENTIRE AgV workflow]
[If answer is 1 or 2, proceed to Step 3]
Step 3.1: Module file name?
[WAIT for answer]
Step 3.2: Reference materials?
[WAIT for answer]
etc.
Check if user invoked skill with arguments.
Pattern 1: /create-demo <directory> --new
Parsing arguments: "<directory> --new"
✓ Target directory: <directory>
✓ Mode: Create new demo
✓ Will generate: index.adoc → 01-overview → 02-details → 03-module-01
Validating directory...
[Check if directory exists, create if needed]
Skipping: Step 1 (mode already known: NEW demo)
Proceeding to: Step 2 (Plan Overall Demo Story)
Pattern 2: /create-demo <directory> --continue <module-path>
Parsing arguments: "<directory> --continue <module-path>"
✓ Target directory: <directory>
✓ Mode: Continue existing demo
✓ Previous module: <module-path>
Validating directory...
[Check if directory exists]
Reading previous module: <module-path>
[Extract story, business context, progression]
Skipping: Step 1 (mode already known: CONTINUE)
Skipping: Step 2 (story detected from previous module)
Proceeding to: Step 3 (Module-Specific Details)
Pattern 3: /create-demo <directory>
Parsing arguments: "<directory>"
✓ Target directory: <directory>
Validating directory...
[Check if directory exists]
Skipping: Target directory question
Proceeding to: Step 1 (still need to ask: new vs continue)
Pattern 4: /create-demo (no arguments)
No arguments provided.
Using interactive mode.
Target directory: Will use default (content/modules/ROOT/pages/)
Proceeding to: Step 1 (Determine Context)
Argument Validation:
--continue but module path invalid, fall back to asking for story recapSKIP THIS STEP IF:
--new flag in arguments (already know: NEW demo)--continue <module> in arguments (already know: EXISTING demo)CRITICAL: DO NOT read any files or make assumptions before asking this question!
First, ask the user:
Let's get started! I'll help you create amazing demo content.
Are you creating a new demo or continuing an existing one?
1. 🆕 Creating a NEW demo (I'll help you plan the whole story)
2. ➡️ Continuing an EXISTING demo (I'll pick up where you left off)
3. 🤔 Something else (tell me what you need)
What's your situation? [1/2/3]
ONLY AFTER user answers, proceed based on their response.
SKIP THIS STEP IF: User provided <directory> as argument
Ask the user:
Where should I create the demo files?
Default location: content/modules/ROOT/pages/
Press Enter to use default, or type a different path:
Validation:
If continuing existing demo:
Great! Let's plan your demo together. I'll ask you a few questions to understand what you're trying to achieve.
IMPORTANT: Ask these as conversational, open-ended questions. Do NOT provide multiple choice options.
Question 1 - The Big Picture:
What's the main message you want to deliver in this demo?
Think about: What should your audience remember after seeing this?
Example: "Show how OpenShift accelerates application deployment for enterprises"
Your answer:
Question 2 - Know Your Audience:
Who will be watching this demo?
Examples: C-level executives, Sales engineers, Technical managers, Partners
Your audience:
And what matters most to them right now? (their business priorities)
Examples: Cost reduction, faster time-to-market, competitive advantage
Their priorities:
Question 3 - The Transformation Story:
Let's create the before-and-after narrative.
What's the customer challenge you're solving?
What's painful about their current state?
What does the ideal future state look like?
Your story:
Question 4 - Customer Scenario:
What company or industry should we feature in this demo?
Examples: "RetailCo" (retail), "FinanceCorp" (banking), "HealthTech" (healthcare)
Or create your own!
Company/industry:
What specific business challenge is driving urgency for them?
Their urgent challenge:
Question 5 - Show the Impact:
What quantifiable improvements will you highlight?
Examples:
- "6 weeks → 5 minutes deployment time"
- "80% reduction in infrastructure costs"
- "10x faster developer productivity"
Your key metrics:
Question 6 - Timing:
How long should the complete demo take?
Typical options: 15min, 30min, 45min
Your target duration:
Then I'll recommend:
You can:
IMPORTANT: This is optional assistance. First ask if user needs help.
⚠️ ADVANCED USERS / RHDP DEVELOPERS ONLY
AgnosticV catalog configuration is for:
Most content creators can skip this - AgV is only needed if you're provisioning infrastructure for your demo.
Initial question:
Quick question about infrastructure setup! 🏗️
Do you need help configuring AgnosticV (the RHDP provisioning system)?
⚠️ Heads up: This is for RHDP developers/advanced users only.
Most content creators should skip this.
1. ⏭️ Skip this (I'll handle it or it's already set up)
2. 🆘 Yes, help me create a new catalog
3. ❓ What's AgnosticV? (explain it to me)
What's your situation? [1/2/3]
If user chooses option 2 (YES to AgV help):
Step A: Get AgV Directory Path (REQUIRED)
Q: What is your AgnosticV repository directory path? (REQUIRED)
This directory is my reference library for:
- Searching existing catalogs by name or keywords
- Learning catalog patterns and structures
- Copying/basing new catalogs on existing ones
- Understanding workload configurations
Example: /Users/username/work/code/agnosticv/
Your AgV path: [Enter full path]
Why REQUIRED: The AgV directory IS the reference material for all catalog work.
Step B: Ask if User Knows Similar Catalog (Recommended)
Q: Do you know of an existing catalog that could be a good base for your demo?
Providing a catalog name helps me:
- Find the closest match faster
- Show you exactly what's available
- Use it as a template if creating new
Options:
- Yes, I know one → Enter display name or slug
- No / Not sure → I'll search by keywords
If YES (user knows catalog name):
If NO/Not sure:
Step C: Complete AgV Workflow
See .claude/docs/SKILL-COMMON-RULES.md section "AgnosticV Configuration Assistance" for complete details.
If creating new catalog, I'll ask:
Git workflow - Pull main, create branch (BEFORE generating files):
Q: Preparing git workflow...
Running in AgV directory:
1. git checkout main
2. git pull origin main
3. git checkout -b {{ catalog_slug }}
UUID Generation (REQUIRED BEFORE file creation):
Q: Please generate a unique UUID for this catalog.
Run one of these commands:
macOS/Linux:
uuidgen
OR
Python (any platform):
python3 -c 'import uuid; print(uuid.uuid4())'
Paste the generated UUID here: [paste UUID]
Validation: Must be standard UUID format (XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)
Example: 5ac92190-6f0d-4c0e-a9bd-3b20dd3c816f
NOT valid: gitops-openshift-2026-01 (this is not a UUID!)
Showroom Repository Detection (REQUIRED for showroom content):
Q: Detecting showroom repository from current directory...
Running: git -C $(pwd) remote get-url origin
Found: {{ git_remote_url }}
{% if SSH format %}
Converting SSH to HTTPS:
SSH: git@github.com:rhpds/showroom-name.git
HTTPS: https://github.com/rhpds/showroom-name.git
{% endif %}
Using showroom repo: {{ https_url }}
Confirm this is correct? [Yes/No/Enter different URL]
If no git remote found:
⚠️ No git remote found in current directory.
Please provide your showroom repository URL (HTTPS format):
Example: https://github.com/rhpds/showroom-agentic-ai-llamastack.git
Your showroom repo URL: [Enter URL]
AgV Directory Selection:
Q: Which directory should I create the catalog in?
Options:
1. agd_v2/ (Recommended - most demos)
2. openshift_cnv/ (For CNV-based infrastructure)
Your choice? [1/2]
Demo-specific defaults:
Workload selection - Based on demo abstract and technology keywords
Generate catalog files - Using UUID and showroom repo URL collected above
Testing confirmation - Ask user to test in RHDP Integration before proceeding
Step D: AgV Testing Confirmation (REQUIRED if creating new)
Q: Have you tested the AgV catalog in RHDP Integration?
Options:
1. Yes, tested and working → Proceed to Step 3
2. No, I'll test it first → Pause workflow
3. Skip testing (not recommended) → Proceed with warning
Your choice? [1/2/3]
CRITICAL: Do NOT proceed to Step 3 until AgV workflow is complete or user confirms skip.
If user chooses option 1 (NO AgV help):
Now for this specific module:
Module file name:
content/modules/ROOT/pages/[number]-[topic-name].adocReference materials (optional but recommended):
UserInfo variables (optional, for accurate showroom content):
Q: Do you have access to a deployed environment on demo.redhat.com or integration.demo.redhat.com?
If YES (RECOMMENDED - easiest and most accurate):
Please share the UserInfo variables from your deployed service:
1. Login to https://demo.redhat.com (or integration.demo.redhat.com)
2. Go to "My services" → Your service
3. Click "Details" tab
4. Expand "Advanced settings" section
5. Copy and paste the output here
This provides exact variable NAMES like:
- openshift_cluster_console_url
- openshift_cluster_admin_username
- gitea_console_url
- [custom workload variables]
CRITICAL: I will use these to know WHICH variables exist, NOT to replace them with actual values!
Variables will stay as placeholders: {openshift_cluster_console_url}
Showroom replaces these at runtime with actual deployment values.
If NO:
Q: Would you like to use placeholder attributes for now?
If YES:
I'll use placeholders: {openshift_console_url}, {user}, {password}
You can update these later when you get Advanced settings.
If NO (RHDP internal team only):
I can extract variables from AgnosticV repository if you have it cloned locally.
This requires AgV path and catalog name.
Note: Less reliable than Advanced settings.
Target audience:
Business scenario/challenge:
Technology/product focus:
Number of demo parts:
Key metrics/business value:
Diagrams, screenshots, or demo scripts (optional):
content/modules/ROOT/assets/images/If UserInfo variables weren't already provided in Step 2.5 or Step 3, I'll ask for them now.
RECOMMENDED: Get from Deployed Environment (Primary Method)
I'll ask: "Do you have access to a deployed environment on demo.redhat.com or integration.demo.redhat.com?"
If YES (recommended):
Please share the UserInfo variables from your deployed service:
1. Login to https://integration.demo.redhat.com (or demo.redhat.com)
2. Go to "My services" → Find your service
3. Click on "Details" tab
4. Expand "Advanced settings" section
5. Copy and paste the output here
This shows all available variables like:
openshift_cluster_console_url → For showing presenter where to log inopenshift_api_server_url → For API demonstrationsopenshift_cluster_admin_username → For admin access demosopenshift_cluster_admin_password → For demo credentialsgitea_console_url → For Git server demosgitea_admin_username, gitea_admin_password → For Gitea accessIf NO (fallback): I'll use common placeholder variables:
{openshift_console_url}{openshift_api_url}{user}{password}{bastion_public_hostname}Alternative: Clone collections from AgV catalog
common.yaml from user-provided AgV pathagnosticd_user_info tasksdata: sectionsResult: I'll use these in Show sections for precise presenter instructions with actual URLs and credentials.
If you provided visual assets or scripts:
For presenter screenshots:
content/modules/ROOT/assets/images/image::console-developer-view.png[Developer Perspective - What Presenters Will See,link=self,window=blank,align="center",width=700,title="Developer Perspective - What Presenters Will See"]
link=self,window=blank to make images clickableFor architecture diagrams:
content/modules/ROOT/assets/images/retail-transformation-architecture.pnglink=self,window=blank for clickable imagesFor demo scripts or commands:
[source,bash]
----
oc new-app https://github.com/example/nodejs-ex
----
[NOTE]
====
**Presenter Tip:** Emphasize how this single command eliminates 3-5 days of manual setup.
====
For before/after comparisons:
before-manual-deployment.png, after-automated-deployment.pngRecommended image naming for demos:
customer-challenge-overview.png, transformation-roadmap.pngstep-1-login-console.png, step-2-create-project.pngdeployment-success.png, metrics-dashboard.pngbefore-state.png, after-state.pngClickable Images (Links):
If an image should be clickable and link to external content, use ^ caret to open in new tab:
// Using image macro with link attribute
image::customer-success-story.png[Case Study,600,link=https://www.redhat.com/case-study^]
// Using link macro around image
link:https://www.redhat.com/case-study^[image:customer-success-story.png[Case Study,600]]
Critical: Clickable images linking to external URLs MUST use ^ caret to open in new tab, preventing audience from losing demo context.
Based on your references, I'll:
Reference Tracking (for conclusion generation):
CRITICAL: I MUST read all these files BEFORE generating content to ensure output meets all standards.
Templates to read:
.claude/templates/demo/03-module-01.adoc.claude/templates/demo/01-overview.adocVerification criteria to read and apply DURING generation:
.claude/prompts/enhanced_verification_demo.txt - Complete demo quality checklist.claude/prompts/redhat_style_guide_validation.txt - Red Hat style rules.claude/prompts/verify_technical_accuracy_demo.txt - Technical accuracy for demos.claude/prompts/verify_accessibility_compliance_demo.txt - Accessibility requirements.claude/prompts/verify_content_quality.txt - Content quality standardsHow I use these:
I'll create a module with Know/Show structure:
CRITICAL: Image Syntax Enforcement:
When generating ANY image reference in the demo content, you MUST include link=self,window=blank:
✅ CORRECT - Always use this format:
image::filename.png[Description,link=self,window=blank,width=700]
image::diagram.png[Architecture,link=self,window=blank,align="center",width=800,title="System Architecture"]
❌ WRONG - Never generate images without link parameter:
image::filename.png[Description,width=700]
image::diagram.png[Architecture,align="center",width=800]
Why: This makes images clickable to open full-size in new tab, preventing presenters from losing their place.
CRITICAL: AsciiDoc List Formatting Enforcement: When generating ANY list in the demo content, you MUST include blank lines before and after the list:
✅ CORRECT - Always use proper spacing:
**Prerequisites:**
* OpenShift 4.18 or later
* Admin access to cluster
* Terminal with oc CLI
In this module, you will...
❌ WRONG - Text runs together when rendered:
**Prerequisites:**
* OpenShift 4.18 or later
* Admin access to cluster
* Terminal with oc CLI
In this module, you will...
Required blank lines:
**Text:**) or colon (:)Why: Without blank lines, Showroom renders lists as plain text, causing content to run together and become unreadable.
CRITICAL: Content Originality - No Plagiarism: All generated content MUST be original. Never copy from external sources without proper attribution.
✅ CORRECT - Original with attribution:
According to link:https://kubernetes.io/docs/...[Kubernetes documentation^],
Kubernetes is "an open-source system for automating deployment." Red Hat OpenShift
extends Kubernetes with enterprise features including integrated CI/CD and security.
❌ WRONG - Copied without attribution:
Kubernetes is an open-source system for automating deployment, scaling,
and management of containerized applications.
Prohibited:
Required:
CRITICAL: No Em Dashes: Never use em dashes (—). Use commas, periods, or en dashes (–) instead.
✅ CORRECT:
OpenShift, Red Hat's platform, simplifies deployments.
The process is simple. Just follow these steps.
2020–2025 (en dash for ranges)
❌ WRONG - Em dash used:
OpenShift—Red Hat's platform—simplifies deployments.
The process is simple—just follow these steps.
Why: Follows Red Hat Corporate Style Guide and improves readability.
CRITICAL: External Links Must Open in New Tab:
All external links MUST use ^ caret to open in new tab, preventing loss of place.
✅ CORRECT - External links with caret:
According to link:https://docs.redhat.com/...[Red Hat Documentation^], OpenShift provides...
See the link:https://www.redhat.com/case-study[RetailCo case study^] for details.
❌ WRONG - Missing caret:
According to link:https://docs.redhat.com/...[Red Hat Documentation], OpenShift provides...
See the link:https://www.redhat.com/case-study[RetailCo case study] for details.
Internal links (NO caret):
✅ CORRECT - Internal navigation without caret:
Navigate to xref:03-next-module.adoc[Next Module] to continue.
See xref:02-overview.adoc#problem[Problem Statement] section.
Why: External links without caret replace current tab, causing presenters/learners to lose their place. Internal xrefs should NOT use caret to keep flow within the demo/workshop.
CRITICAL: Bullets vs Numbers - Know vs Show: Knowledge sections use bullets (*). Task/step sections use numbers (.).
✅ CORRECT - Bullets for knowledge, numbers for tasks:
=== Know
**Business Challenge:**
* Manual deployments take 8-10 weeks
* Security vulnerabilities discovered too late
* Infrastructure costs are too high
=== Show
**What I do:**
. Log into OpenShift Console at {openshift_console_url}
. Navigate to Developer perspective
. Click "+Add" → "Import from Git"
. Enter repository URL and click Create
❌ WRONG - Mixed up bullets and numbers:
=== Know
**Business Challenge:**
. Manual deployments take 8-10 weeks ← WRONG (should be bullets)
. Security vulnerabilities discovered too late
. Infrastructure costs are too high
=== Show
**What I do:**
* Log into OpenShift Console ← WRONG (should be numbers)
* Navigate to Developer perspective
* Click "+Add" → "Import from Git"
Rule:
Why: Bullets indicate information to absorb; numbers indicate sequential actions to perform.
CRITICAL: Demo Language - NO Learner Language: Demos are presenter-led, NOT learner-focused. Use the correct terminology.
For index.adoc (Navigation Hub - if generating first demo):
✅ CORRECT - Presenter-focused:
= OpenShift Platform Demo
**What This Demo Covers**
This demonstration shows how Red Hat OpenShift accelerates deployment cycles:
* Self-service developer platform capabilities
* Automated CI/CD pipeline integration
* Built-in security and compliance features
* Business ROI and cost reduction metrics
❌ WRONG - Learner language:
= OpenShift Platform Demo
**What You'll Learn**
In this workshop, you will learn how to:
* Deploy applications to OpenShift
* Create CI/CD pipelines
* Configure security policies
For 01-overview.adoc (Presenter Prep - if generating first demo):
✅ CORRECT - Full business context for presenters:
= Demo Overview and Presenter Preparation
== Background
ACME inc is a retail company facing Black Friday deadlines with 10-week deployment cycles.
They need to accelerate feature delivery to remain competitive.
== Problem Breakdown
**Challenge 1: Slow deployment cycles** - Manual processes take 8-10 weeks
**Challenge 2: Security vulnerabilities** - 200+ CVEs discovered monthly
**Challenge 3: Infrastructure costs** - $2M annually on underutilized servers
== Solution Overview
Red Hat OpenShift provides self-service platform with automated security.
== Business Benefits
* 95% faster deployments (10 weeks → 30 minutes)
* 80% reduction in security vulnerabilities
* 60% lower infrastructure costs
== Common Customer Questions
**"How does this work with our existing tools?"**
→ Emphasize Jenkins integration path and existing tool enhancement
Key Rules:
CRITICAL: Demo Talk Track Separation: Demo modules MUST separate presenter guidance from technical steps:
Required structure for each Show section:
=== Show
**What I say**:
"We're seeing companies like yours struggle with 6-8 week deployment cycles. Let me show you how OpenShift reduces that to minutes."
**What I do**:
. Log into OpenShift Console at {console_url}
. Navigate to Developer perspective
. Click "+Add" → "Import from Git"
**What they should notice**:
✓ No complex setup screens
✓ Self-service interface
✓ **Metric highlight**: "This used to take 6 weeks, watch what happens..."
**If asked**:
Q: "Does this work with our existing Git repos?"
A: "Yes, OpenShift supports GitHub, GitLab, Bitbucket, and private Git servers."
Q: "What about security scanning?"
A: "Built-in. I'll show that in part 2."
Labs should NOT include talk tracks - labs are for hands-on learners, not presenters.
For each demo part:
Know Section:
Show Section:
Example Structure:
== Part 1 — Accelerating Application Deployment
=== Know
_Customer challenge: Deployment cycles take 6-8 weeks, blocking critical business initiatives._
**Business Impact:**
* Development teams wait 6-8 weeks for platform provisioning
* Black Friday deadline in 4 weeks is at risk
* Manual processes cause errors and rework
* Competition is shipping features faster
**Value Proposition:**
OpenShift reduces deployment time from weeks to minutes through self-service developer platforms and automated CI/CD pipelines.
=== Show
**Optional visual**: Before/after deployment timeline diagram showing 6-8 weeks vs 2 minutes
* Log into OpenShift Console at {openshift_console_url}
* Username: {user}
* Password: {password}
* Navigate to Developer perspective → +Add
* Select "Import from Git" and enter:
* Git Repo: `https://github.com/example/nodejs-ex`
* Application name: `retail-checkout`
* Deployment: Create automatically
* Click "Create" and observe:
* Build starts automatically
* Container image is built
* Application deploys in ~2 minutes
image::deployment-progress.png[Deployment in Progress,link=self,window=blank,align="center",width=700,title="Deployment in Progress"]
* **Business Value Callout**: "What used to take your team 6-8 weeks just happened in 2 minutes. Developers can now deploy independently without waiting for infrastructure teams."
* Show the running application:
* Click the route URL
* Demonstrate the live application
* Highlight the automatic scaling capability
* Connect to business outcome:
"This self-service capability means your development team can meet the 4-week Black Friday deadline and ship updates daily instead of quarterly."
Optional Visual Cues (Recommended):
Add lightweight visual guidance without forcing asset creation:
=== Show
**Optional visual**: Architecture diagram showing component relationships
**Optional slide**: Customer pain points - 6-8 week deployment cycles
**Optional visual**: Before/after comparison of manual vs automated workflow
[...presenter actions follow...]
Cue Examples:
Guidelines:
I'll automatically run:
I'll automatically add the module to content/modules/ROOT/nav.adoc - this is REQUIRED for the module to appear in the Showroom sidebar.
What I'll add:
* xref:<module-file>[<Module Number>. <Module Title>]
** xref:<module-file>#part-1[Part 1: <Title>]
** xref:<module-file>#part-2[Part 2: <Title>]
Note: Without this nav.adoc entry, your demo won't be accessible in Showroom!
CRITICAL: Manage Output Tokens to Prevent Overflow
Token Management Rules:
Output Format:
✅ Demo Module Generation Complete
**Files Created**:
- content/modules/ROOT/pages/demo-01-platform-value.adoc (312 lines)
- content/modules/ROOT/nav.adoc (updated)
**Demo Structure**:
- Know sections: 4 (business context, pain points, value props, ROI)
- Show sections: 3 (technical demonstrations)
- Presenter tips: 8
- Business metrics: 5 quantified benefits
- Troubleshooting scenarios: 4
**Assets**:
- Diagrams needed: 3 placeholders (architecture, before/after, ROI chart)
- Screenshots needed: 2 placeholders (UI demonstrations)
- Dynamic attributes used: {openshift_console_url}, {demo_app_url}
**Presenter Notes**:
- Estimated presentation time: 25 minutes
- Business talking points included in each Know section
- Technical demo scripts in each Show section
- Pause points for questions marked
**Next Steps**:
1. Review demo: content/modules/ROOT/pages/demo-01-platform-value.adoc
2. Prepare diagrams for business context sections
3. Capture screenshots for technical demonstrations
4. Practice demo flow and timing
5. Run: verify-content to check quality
6. Create next module: create-demo (continuing existing demo)
**Note**: All files have been written. Use your editor to review them.
What NOT to do:
What TO do:
After delivering the final module, ask if this is the last module:
Q: Is this the last module of your demo?
If YES, I will now generate the mandatory conclusion module that includes:
- Business impact recap and ROI summary
- Competitive advantages demonstrated
- ALL REFERENCES used across the entire demo
- Next steps for evaluation, pilot, and production
- Call-to-action for technical teams and decision makers
- Q&A guidance
If NO, you can continue creating more modules, and I'll generate the conclusion when you're done.
Is this your last module? [Yes/No]
If user answers YES (this is the last module):
Read ALL previous modules to extract:
Ask about references:
First, extract all references from previous modules:
Then ask the user:
Q: How would you like to handle references in the conclusion?
I found these references used across your demo modules:
1. https://www.redhat.com/... [Red Hat OpenShift Platform] - Used in: Modules 1, 3
2. https://docs.redhat.com/... [Product Documentation] - Used in: Module 2
3. https://customers.redhat.com/... [Customer Success Story] - Used in: Module 1
{{ additional_references_if_found }}
Options:
1. Use these references as-is (I'll organize them by category)
2. Let me provide additional references to include
3. Let me curate the reference list (add/remove specific items)
Your choice? [1/2/3]
If option 1: Use extracted references, organize by category
If option 2: Ask user to provide additional references:
Q: Please provide additional references to include in the conclusion.
Format: URL and description, one per line
Example:
https://www.redhat.com/... - Red Hat solution brief
https://customers.redhat.com/... - Customer case study
Your additional references:
If option 3: Ask user which references to keep/remove/add:
Q: Let's curate the reference list.
Current references:
{{ numbered_list_of_references }}
Options:
- Type numbers to REMOVE (e.g., "3, 5, 7")
- Type "add" to add new references
- Type "done" when finished
Your action:
Detect highest module number (e.g., if last module is 05-module-03, conclusion will be 06-conclusion.adoc)
Generate conclusion module using the embedded template below
Customize the template with Know/Show structure:
0X-conclusion.adoc (where X = next sequential number)Update nav.adoc with conclusion entry at the end
Provide brief confirmation
If user answers NO (more modules to come):
Embedded Demo Conclusion Template:
= Demo Conclusion and Next Steps
*Presenter Note*: Use this concluding section to wrap up the demonstration, reinforce key messages, and provide clear next steps for the audience.
== Summary
=== Know
**Business Impact Recap**
You've just seen how {{ product_name }} addresses the critical business challenges we discussed:
* **{{ business_challenge_1 }}**: Solved with {{ solution_1 }}
* **{{ business_challenge_2 }}**: Solved with {{ solution_2 }}
* **{{ business_challenge_3 }}**: Solved with {{ solution_3 }}
**ROI and Value**
The solution demonstrated today delivers:
* {{ roi_metric_1 }} - {{ benefit_1 }}
* {{ roi_metric_2 }} - {{ benefit_2 }}
* {{ roi_metric_3 }} - {{ benefit_3 }}
**Competitive Advantages**
What sets this apart:
. {{ differentiator_1 }}
. {{ differentiator_2 }}
. {{ differentiator_3 }}
=== Show
**What We Demonstrated**
In this demo, you saw:
. ✅ {{ demo_capability_1 }}
. ✅ {{ demo_capability_2 }}
. ✅ {{ demo_capability_3 }}
. ✅ {{ demo_capability_4 }}
**Key Technical Highlights**
The most impressive technical capabilities:
* **{{ technical_highlight_1 }}**: {{ why_it_matters_1 }}
* **{{ technical_highlight_2 }}**: {{ why_it_matters_2 }}
* **{{ technical_highlight_3 }}**: {{ why_it_matters_3 }}
== Next Steps for Your Organization
=== Immediate Actions
Help your audience get started:
. **Try It Yourself**: {{ workshop_url }} - Hands-on workshop based on this demo
. **Request POC**: {{ poc_contact }} - Proof of concept in your environment
. **Schedule Deep Dive**: {{ schedule_url }} - Technical architecture session
=== Recommended Path
**Phase 1: Evaluate** (Weeks 1-2)::
* Attend hands-on workshop
* Review technical documentation
* Assess fit for your use cases
**Phase 2: Pilot** (Weeks 3-6)::
* Deploy proof of concept
* Test with representative workloads
* Measure performance and ROI
**Phase 3: Production** (Months 2-3)::
* Roll out to production environment
* Train teams
* Scale across organization
=== Resources
**Documentation**:
* link:{{ product_docs_url }}[{{ product_name }} Documentation^]
* link:{{ architecture_guide_url }}[Architecture Guide^]
* link:{{ best_practices_url }}[Best Practices^]
**Workshops and Training**:
* link:{{ workshop_url }}[Hands-on Workshop^] - Based on this demo
* link:{{ training_url }}[{{ product_name }} Training^]
**Support and Community**:
* link:{{ community_url }}[Community Forums^]
* link:{{ support_url }}[Enterprise Support^]
* link:{{ blog_url }}[Technical Blog^]
== Call to Action
*Presenter Guidance*: Tailor this section based on your audience (technical vs executive, evaluation vs purchase stage).
=== For Technical Teams
**Ready to build?**
. Access the hands-on workshop: {{ workshop_url }}
. Clone the demo repository: {{ demo_repo_url }}
. Join the community: {{ community_url }}
=== For Decision Makers
**Ready to transform your operations?**
. Schedule a custom demo: {{ custom_demo_url }}
. Request ROI analysis: {{ roi_analysis_contact }}
. Speak with an architect: {{ architect_contact }}
== Questions and Discussion
*Presenter Note*: Leave 5-10 minutes for Q&A. Common questions and answers:
**Q: How long does deployment take?**::
A: {{ deployment_time }} with our guided process. Proof of concept can be running in {{ poc_time }}.
**Q: What's the learning curve?**::
A: {{ learning_curve }}. Workshop participants are productive within {{ productivity_time }}.
**Q: Integration with existing tools?**::
A: {{ integration_summary }}. We support {{ integration_list }}.
**Q: Support and SLAs?**::
A: {{ support_summary }}. Enterprise support includes {{ sla_details }}.
== Presenter Action Items
*For Sales Engineers / Solution Architects*: Follow these steps after the demo:
=== Immediate Follow-up (Within 24 hours)
. **Send Demo Recording**: Email recording link with key timestamps
. **Share Resources**: Send links to documentation, workshop, and trial access
. **Schedule Next Meeting**: Book follow-up for deeper technical discussion or POC planning
. **Internal Notes**: Log demo feedback, questions asked, and objections in CRM
=== Within One Week
. **Proposal or ROI Analysis**: Send customized proposal based on their requirements
. **Technical Deep Dive**: Offer architecture review session with specialist
. **POC Proposal**: Outline proof-of-concept scope, timeline, and success criteria
. **Connect with Product Team**: Loop in product specialists if needed
=== Qualification Checkpoints
Based on this demo, assess:
* **Budget**: Do they have budget allocated or need justification?
* **Timeline**: When do they need to make a decision?
* **Authority**: Who else needs to be involved in the decision?
* **Need**: Is this a critical priority or nice-to-have?
== References
**CRITICAL**: This section consolidates ALL references used across the entire demo.
Read all previous modules and extract every reference cited, then organize them by category:
=== Product Documentation
* link:{{ product_docs_url }}[{{ product_name }} Documentation^] - Used in: Modules {{ modules_list }}
* link:{{ feature_docs_url }}[{{ feature_name }} Guide^] - Used in: Modules {{ modules_list }}
=== Red Hat Resources
* link:{{ redhat_resource_1 }}[{{ resource_title_1 }}^] - Used in: Module {{ module_number }}
* link:{{ solution_brief_url }}[{{ solution_brief_title }}^] - Used in: Module {{ module_number }}
=== Customer Success Stories
* link:{{ customer_story_1 }}[{{ customer_name_1 }} Case Study^] - Used in: Module {{ module_number }}
* link:{{ customer_story_2 }}[{{ customer_name_2 }} Success Story^] - Used in: Module {{ module_number }}
=== Industry Research and Analysis
* link:{{ analyst_report_url }}[{{ analyst_report_title }}^] - Market research
* link:{{ industry_study_url }}[{{ study_title }}^] - Industry benchmarks
**Guidelines for References section**:
- Group references by category (Product Docs, Red Hat Resources, Customer Stories, Research)
- Include which module(s) used each reference
- ALL external links must use `^` caret to open in new tab
- Provide brief context for each reference (what it covers)
- Ensure ALL references from ALL modules are included
== Thank You
Thank you for your time and attention. We're excited to help you {{ primary_value_proposition }}.
**Contact Information**:
* Sales: {{ sales_contact }}
* Technical: {{ technical_contact }}
* Support: {{ support_contact }}
---
**Demo**: {{ demo_name }} +
**Presented**: {localdate} +
**Platform**: Red Hat Showroom
Conclusion Module Naming:
0X-conclusion.adoc (sequential number, e.g., 06-conclusion.adoc)= Demo Conclusion and Next Steps* xref:0X-conclusion.adoc[Conclusion and Next Steps]Content to Include (ALL REQUIRED):
CRITICAL: The References section MUST include every reference used across all demo modules, organized by category (Product Docs, Red Hat Resources, Customer Stories, Research).
User: Create a demo showing OpenShift value for C-level executives
Skill: Excellent! Since this is a new demo, let me gather the overall story first.
**Overall Demo Planning:**
Q: Are you creating a new demo or continuing an existing demo?
A: Creating a new demo
Q: What's the overall message?
A: "Show how OpenShift reduces time-to-market and operational costs for enterprises"
Q: Target audience?
A: C-level executives (CTO, CIO) evaluating platform modernization
Q: What are their business priorities?
A: - Reduce operational costs
- Faster feature delivery to stay competitive
- Risk mitigation (security, compliance)
Q: Business transformation story?
A: Current state: Manual deployments take 6-8 weeks, blocking business initiatives
Desired state: Self-service platform enabling daily deployments
Q: Customer scenario?
A: "RetailCo" - Retail company facing Black Friday deadline with current 10-week deployment cycles
Q: Key metrics to showcase?
A: - 8 weeks → 10 minutes deployment time
- 80% reduction in infrastructure costs
- 95% reduction in security vulnerabilities
Q: Demo duration?
A: 30 minutes total
**Recommended Demo Flow:**
Based on your goals, I recommend 2 modules:
Module 1: Platform Value & Developer Experience (15 min)
- Know: RetailCo's deployment challenge, business impact
- Show: Self-service deployment demonstration
- Proof point: 8 weeks → 10 minutes
- Story: Developer empowerment, IT team efficiency
Module 2: Business Continuity & ROI (15 min)
- Know: Cost structure, security posture improvements
- Show: Auto-scaling, built-in security scanning
- Proof point: 80% cost reduction, 95% fewer vulnerabilities
- Story: Strategic platform investment ROI
Does this flow work for you, or adjustments needed?
User: Perfect! Create Module 1.
Skill: Great! Now let me gather details for Module 1...
Q1: Module file name? → "03-platform-value.adoc"
Q2: AgnosticV catalog item? → "ocp4_workload_demo"
Q3: Reference materials? → https://www.redhat.com/en/technologies/cloud-computing/openshift
Q4: Target audience details? → C-level (using overall)
Q5: Business scenario? → "RetailCo" (using overall story)
Q6: Technology? → "OpenShift Container Platform"
Q7: Demo parts? → 3
Q8: Key metrics? → "8 weeks → 10 minutes" (using overall)
Q9: Diagrams? → Architecture diagram: ~/diagrams/retail-platform.png
[Generates Module 1 with RetailCo story]
[Sets up story arc for Module 2]
✓ Created: content/modules/ROOT/pages/03-platform-value.adoc
✓ Story established: RetailCo's platform modernization journey
✓ Business metrics integrated throughout
✓ Module flow documented for Module 2
✓ Ready for Module 2 (will auto-continue story)
User: Create demo Module 1 for OpenShift using:
https://docs.openshift.com/container-platform/4.14/
Skill: I'll create that demo module. Let me ask questions...
[asks if new demo or continuing]
[if new demo: asks overall story questions]
[asks module-specific questions]
[generates module with business story]
[validates with agents]
✓ Created: content/modules/ROOT/pages/03-platform-demo.adoc
✓ Presenter notes included
✓ Screenshot guide provided
✓ Navigation updated
User: Create demo for OpenShift AI value proposition. I have:
- Architecture diagram: ~/diagrams/ai-platform-architecture.png
- Before/after workflow diagrams
Skill: Excellent! Let me gather details...
Q1: Module file name? → "03-ai-platform-demo.adoc"
Q2: AgnosticV catalog item? → "ocp4_workload_rhods_demo"
Q3: Reference materials? → https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-ai
Q4: Target audience? → C-level executives
Q5: Business scenario? → "TechCorp needs faster AI model deployment"
Q6: Technology? → "Red Hat OpenShift AI"
Q7: Demo parts? → 3
Q8: Key metrics? → "Weeks to hours for model deployment"
Q9: Diagrams/screenshots? → Yes:
- Architecture: ~/diagrams/ai-platform-architecture.png
- Before workflow: ~/diagrams/before-manual-ml.png
- After workflow: ~/diagrams/after-automated-ml.png
Skill: Perfect! Processing diagrams and creating demo...
[Saves diagrams to assets/images/]
→ ai-platform-architecture.png
→ before-manual-ml.png
→ after-automated-ml.png
[Generates demo with:]
- Part 1 Know section includes architecture diagram
- Part 1 Show section references the architecture
- Part 2 Know section uses before/after comparison
- Each diagram has business-focused captions
- Presenter tips for discussing diagrams
Example output:
```asciidoc
== Part 1 — AI Platform Overview
=== Know
_TechCorp's data scientists wait weeks for infrastructure, delaying critical AI initiatives._
image::ai-platform-architecture.png[Red Hat OpenShift AI Platform Architecture,link=self,window=blank,align="center",width=800,title="Red Hat OpenShift AI Platform Architecture"]
**Current Challenge:**
* 2-3 weeks to provision ML infrastructure
* Manual environment setup prone to errors
* Inconsistent tooling across teams
=== Show
* Show the architecture diagram and explain:
"This is how OpenShift AI eliminates infrastructure delays..."
* Log into OpenShift AI Dashboard at {rhods_dashboard_url}
[NOTE]
====
**Presenter Tip:** Point to the architecture diagram as you navigate the UI.
Show how the platform maps to the architectural components.
====
✓ Created: content/modules/ROOT/pages/03-ai-platform-demo.adoc ✓ 3 diagrams saved and referenced appropriately ✓ Before/after comparison integrated in Know section ✓ Presenter notes tied to visual elements
## Know Section Best Practices
Good Know sections include:
**Business Challenge**:
- Specific customer pain point
- Current state with metrics
- Why it matters now (urgency)
**Current vs Desired State**:
- "Now: 6-8 week deployment cycles"
- "Goal: Deploy multiple times per day"
**Stakeholder Impact**:
- Who cares: "VP Engineering, Product Managers"
- Why: "Missing market windows, losing to competitors"
**Value Proposition**:
- Clear benefit statement
- Quantified outcome
- Business language, not tech jargon
## Show Section Best Practices
Good Show sections include:
**Clear Instructions**:
- Numbered steps
- Specific UI elements ("Click Developer perspective")
- Exact field values to enter
**Expected Outcomes**:
- What presenters should see
- Screenshots of key moments
- Success indicators
**Business Callouts**:
- Connect each technical step to business value
- Use phrases like "This eliminates..." or "This reduces..."
- Quantify where possible
**Presenter Tips**:
- Common questions to expect
- Troubleshooting hints
- Pacing suggestions
## Tips for Best Results
- **Specific metrics**: "6 weeks → 5 minutes" not "faster deployments"
- **Real scenarios**: Base on actual customer challenges
- **Visual emphasis**: Demos need more screenshots than workshops
- **Business language**: Executives care about outcomes, not features
- **Story arc**: Build narrative across parts
## Quality Standards
Every demo module will have:
- ✓ Know/Show structure for each part
- ✓ Business context before technical steps
- ✓ Quantified metrics and value propositions
- ✓ Clear presenter instructions
- ✓ Image placeholders with descriptions
- ✓ Business value callouts during Show
- ✓ External links with `^` to open in new tab
- ✓ Dynamic variables as placeholders (not replaced with actual values)
- ✓ Target audience appropriate language
- ✓ Red Hat style compliance
## Common Demo Patterns
**Executive Audience**:
- More Know, less Show
- Focus on business outcomes
- High-level demonstrations
- Emphasize strategic value
**Technical Audience**:
- Balanced Know/Show
- Show depth and capabilities
- Include architecture discussions
- Technical credibility focus
**Sales Engineers**:
- Detailed Show sections
- Competitive differentiators
- Objection handling
- ROI calculations
## Integration Notes
**Templates used**:
- `.claude/templates/demo/03-module-01.adoc`
- `.claude/templates/demo/01-overview.adoc`
**Agents invoked**:
- `workshop-reviewer` - Validates structure
- `style-enforcer` - Applies Red Hat style
**Files created**:
- Demo module: `content/modules/ROOT/pages/<module-file>.adoc`
- Assets: `content/modules/ROOT/assets/images/`
**Files modified** (with permission):
- `content/modules/ROOT/nav.adoc` - Adds navigation entry