Guide you through creating a Red Hat Showroom demo module using the Know/Show structure for presenter-led demonstrations.
---
context: main
model: sonnet
---
Guide you through creating a Red Hat Showroom demo module using the Know/Show structure for presenter-led demonstrations.
Have these ready before running this skill:
**Required:**
- Product documentation or feature descriptions
- URLs to technical guides or demos
- Text describing what to demonstrate
**Helpful to have:**
**Access needed:**
**Use this skill when you want to**:
**Don't use this for**:
**IMPORTANT**: 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**:
```bash
/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**:
- Example: `/create-demo content/modules/ROOT/pages/`
- If not provided, defaults to `content/modules/ROOT/pages/`
- Example: `/create-demo content/modules/ROOT/pages/ --continue content/modules/ROOT/pages/03-module-01-intro.adoc`
- Reads previous module to detect story continuity
**How Arguments Work**:
**CRITICAL RULES**
**Example of WRONG approach**:
```
❌ Asking all at once:
1. Module file name?
2. UserInfo variables?
3. Presentation objective?
4. Number of demos?
```
**Example of CORRECT approach**:
```
✅ Ask sequentially:
Step 2: Complete overall demo story planning
[WAIT for completion]
Step 3.1: Module file name?
[WAIT for answer]
Step 3.2: Reference materials?
[WAIT for answer]
etc.
```
---
**Before generating content, we need access to real Showroom demo examples for quality reference.**
**CRITICAL: This step MUST happen before any content generation to ensure quality matches real Showroom demo standards.**
**Ask the user:**
```
📚 Reference Repository Check
To generate high-quality demo content that matches Showroom standards, I need access to real Showroom demo examples.
Do you have a Showroom repository cloned locally that I can reference for patterns and examples?
Options:
1. Yes - I have a local Showroom repo (Recommended - best quality)
2. No - Clone template to /tmp/ for me
3. Skip - Generate without reference (Not recommended - may need manual rewrites)
Your choice: [1/2/3]
```
**If Option 1 (YES - Local repo):**
```
Great! Please provide the path to your Showroom repository:
Example: ~/work/showroom-content/my-demo
Path:
```
**Validation:**
**Once valid path provided:**
1. Read 2-3 example demo modules from `content/modules/ROOT/pages/*.adoc`
2. Analyze and learn from:
- Know/Show structure and separation
- Business value messaging patterns
- Presenter guidance formatting
- Talk track examples ("What I say", "What I do", "What they should notice")
- Code block formatting and syntax highlighting
- Image and diagram patterns (link=self,window=blank usage)
- Navigation includes and xrefs
- List formatting (blank lines before/after lists)
- External link patterns (^ caret usage)
- Business metrics and ROI presentation
3. Use these patterns as templates for generating new demo content
**If Option 2 (NO - Clone template):**
```
I'll clone the Showroom template repository to /tmp/showroom-reference for you.
This provides standard Showroom demo examples to ensure quality output.
Proceed? [Yes/No]
```
**If Yes:**
```bash
git clone https://github.com/rhpds/showroom-template /tmp/showroom-reference
```
Then:
1. Read example demo modules from `/tmp/showroom-reference/content/modules/ROOT/pages/*.adoc`
2. Analyze demo patterns (same as Option 1)
3. Use for content generation
**If No or clone fails:**
**If Option 3 (Skip):**
```
⚠️ WARNING: Generating without reference repository
Without real Showroom demo examples, the generated content:
This is the issue reported: "Module 2 is crap, requires manual rewrite with actual showroom docs"
Are you sure you want to skip reference repository? [Yes/No]
```
**If Yes:** Proceed with generic templates, but add note in final output warning about potential quality issues
**If No:** Go back to Option 1 or 2
**Why This Step Matters:**
Before this fix:
After this fix:
**Store reference path for later use:**
---
**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**:
---
**SKIP THIS STEP IF**:
**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:
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**:
---
Now for this specific module:
1. **Module file name**:
- Module file name (e.g., "03-demo-intro.adoc", "04-platform-demo.adoc")
- Files go directly in `content/modules/ROOT/pages/`
- Pattern: `[number]-[topic-name].adoc`
2. **Reference materials** (optional but recommended):
- URLs to Red Hat product documentation
- Marketing materials, solution briefs
- Local files (Markdown, AsciiDoc, PDF)
- Pasted content
- **Better references = better business value extraction**
- If not provided: Generate from templates and common value propositions
3. **UserInfo variables** (optional, for accurate showroom content):
- **I must ask the user:**
```
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.
```
4. **Target audience**:
- Sales engineers, C-level executives, technical managers, developers
5. **Business scenario/challenge**:
- Auto-detect from previous module (if exists)
- Or ask for customer scenario (e.g., "RetailCo needs faster deployments")
6. **Technology/product focus**:
- Example: "OpenShift", "Ansible Automation Platform"
7. **Number of demo parts**:
- Recommended: 2-4 parts (each with Know/Show sections)
8. **Key metrics/business value**:
- Example: "Reduce deployment time from 6 weeks to 5 minutes"
9. **Diagrams, screenshots, or demo scripts** (optional):
- Do you have architecture diagrams, demo screenshots, or scripts?
- If yes: Provide file paths or paste content
- I'll save them to `content/modules/ROOT/assets/images/`
- And reference them properly in Show sections
If UserInfo variables weren't already provided in 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:
**If NO** (fallback):
I'll use common placeholder variables:
**Alternative**: Clone collections from AgV catalog
**Result**: 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**:
```asciidoc
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"]
```
**For architecture diagrams**:
**For demo scripts or commands**:
```asciidoc
[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**:
**Recommended image naming for demos**:
**Clickable Images (Links)**:
If an image should be clickable and link to external content, use `^` caret to open in new tab:
```asciidoc
// 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:**
**Verification criteria to read and apply DURING generation:**
1. `.claude/prompts/enhanced_verification_demo.txt` - Complete demo quality checklist
2. `.claude/prompts/redhat_style_guide_validation.txt` - Red Hat style rules
3. `.claude/prompts/verify_technical_accuracy_demo.txt` - Technical accuracy for demos
4. `.claude/prompts/verify_accessibility_compliance_demo.txt` - Accessibility requirements
5. `.claude/prompts/verify_content_quality.txt` - Content quality standards
**How I use these:**
**IMPORTANT: Use Reference Repository from Step 0**
Before generating ANY demo content, refer back to the reference repository demo examples from Step 0:
1. **Read reference demo examples again** if needed to refresh patterns
2. **Match Know/Show structure** from real Showroom demos
3. **Apply learned patterns** to new demo content:
- Know sections match reference business messaging style
- Show sections follow reference presenter guidance patterns
- Talk tracks ("What I say", "What I do") match reference format
- Business metrics and ROI presentation follows reference examples
- Code block formatting follows reference style
- Image references use same patterns (link=self,window=blank)
- List formatting matches reference (blank lines before/after)
- External links follow reference pattern (^ caret for new tabs)
**This ensures generated demo content matches real Showroom demo quality instead of generic templates.**
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**:
```asciidoc
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**:
```asciidoc
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**:
```asciidoc
**Prerequisites:**
In this module, you will...
```
❌ **WRONG - Text runs together when rendered**:
```asciidoc
**Prerequisites:**
In this module, you will...
```
**Required blank lines**:
1. Blank line after bold heading (`**Text:**`) or colon (`:`)
2. Blank line before first list item
3. Blank line after last list item (before next content)
**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**:
```asciidoc
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**:
```asciidoc
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**:
```asciidoc
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**:
```asciidoc
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**:
```asciidoc
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**:
```asciidoc
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)**:
```asciidoc
✅ 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**:
```asciidoc
=== Know
**Business Challenge:**
=== 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**:
```asciidoc
=== 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:**
```
**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**:
```asciidoc
= OpenShift Platform Demo
**What This Demo Covers**
This demonstration shows how Red Hat OpenShift accelerates deployment cycles:
```
❌ **WRONG - Learner language**:
```asciidoc
= OpenShift Platform Demo
**What You'll Learn**
In this workshop, you will learn how to:
```
**For 01-overview.adoc (Presenter Prep - if generating first demo)**:
✅ **CORRECT - Full business context for presenters**:
```asciidoc
= 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
== Common Customer Questions
**"How does this work with our existing tools?"**
→ Emphasize Jenkins integration path and existing tool enhancement
```
**Key Rules**:
1. index.adoc → Use "What This Demo Covers" (NOT "What You'll Learn")
2. index.adoc → Keep it brief (navigation hub)
3. index.adoc → No detailed problem statements
4. 01-overview.adoc → Complete business context for presenter preparation
5. 01-overview.adoc → Include all business benefits and customer Q&A
6. Never use "you will learn", "hands-on", "exercises" in demos
**CRITICAL: Demo Talk Track Separation**:
Demo modules MUST separate presenter guidance from technical steps:
**Required structure** for each Show section:
```asciidoc
=== 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**:
```asciidoc
== Part 1 — Accelerating Application Deployment
=== Know
_Customer challenge: Deployment cycles take 6-8 weeks, blocking critical business initiatives._
**Business Impact:**
**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
* Username: {user}
* Password: {password}
* Git Repo: `https://github.com/example/nodejs-ex`
* Application name: `retail-checkout`
* Deployment: Create automatically
* 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"]
* Click the route URL
* Demonstrate the live application
* Highlight the automatic scaling capability
"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:
```asciidoc
=== 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**:
```asciidoc
** 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**:
1. **Write files using Write tool** - Don't output full file contents to user
2. **Show brief confirmations only** - "✅ Created: file.adoc (X lines)"
3. **Provide summary at end** - List what was created, not the full content
4. **Never output entire demo content** - Files are already written
5. **Keep total output under 5000 tokens** - Brief summaries only
**Output Format**:
```
✅ Demo Module Generation Complete
**Files Created**:
**Demo Structure**:
**Assets**:
**Presenter Notes**:
**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:
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)**:
1. Read ALL previous modules to extract:
- All business value points and ROI metrics
- All references cited in each module
- Key technical capabilities demonstrated
- Competitive differentiation points
2. Ask about references:
**First, extract all references from previous modules:**
- Read all module files (index.adoc, 01-overview.adoc, 02-details.adoc, 03-module-01-*.adoc, etc.)
- Extract all external links found in the content
- Identify reference materials provided during module creation (Step 3 question 2)
- Compile a comprehensive list with:
- URL
- Link text/title
- Which module(s) referenced it
**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:
```
3. Detect highest module number (e.g., if last module is 05-module-03, conclusion will be 06-conclusion.adoc)
4. Generate conclusion module using the embedded template below
5. Customize the template with Know/Show structure:
- File: `0X-conclusion.adoc` (where X = next sequential number)
- **Know**: Business impact recap, ROI summary, competitive advantages
- **Show**: Demo capabilities recap, technical highlights
- Next steps: Workshops, POC, deep dives
- **References**: Consolidated references from all modules (REQUIRED)
- Call to action for decision makers and technical teams
- Q&A guidance with common questions
6. Update nav.adoc with conclusion entry at the end
7. Provide brief confirmation
**If user answers NO (more modules to come)**:
**Embedded Demo Conclusion Template**:
```asciidoc
= 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:
**ROI and Value**
The solution demonstrated today delivers:
**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:
== 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)::
**Phase 2: Pilot** (Weeks 3-6)::
**Phase 3: Production** (Months 2-3)::
=== Resources
**Documentation**:
**Workshops and Training**:
**Support and Community**:
== 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:
== 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
=== Red Hat Resources
=== Customer Success Stories
=== Industry Research and Analysis
**Guidelines for References section**:
== Thank You
Thank you for your time and attention. We're excited to help you {{ primary_value_proposition }}.
**Contact Information**:
---
**Demo**: {{ demo_name }} +
**Presented**: {localdate} +
**Platform**: Red Hat Showroom
```
**Conclusion Module Naming**:
**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)
Module 2: Business Continuity & ROI (15 min)
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: Reference materials? → https://www.redhat.com/en/technologies/cloud-computing/openshift
Q3: Target audience details? → C-level (using overall)
Q4: Business scenario? → "RetailCo" (using overall story)
Q5: Technology? → "OpenShift Container Platform"
Q6: Demo parts? → 3
Q7: Key metrics? → "8 weeks → 10 minutes" (using overall)
Q8: 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: Reference materials? → https://www.redhat.com/en/technologies/cloud-computing/openshift/openshift-ai
Q3: Target audience? → C-level executives
Q4: Business scenario? → "TechCorp needs faster AI model deployment"
Q5: Technology? → "Red Hat OpenShift AI"
Q6: Demo parts? → 3
Q7: Key metrics? → "Weeks to hours for model deployment"
Q8: 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:]
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:**
=== Show
"This is how OpenShift AI eliminates infrastructure delays..."
[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
```
Good Know sections include:
**Business Challenge**:
**Current vs Desired State**:
**Stakeholder Impact**:
**Value Proposition**:
Good Show sections include:
**Clear Instructions**:
**Expected Outcomes**:
**Business Callouts**:
**Presenter Tips**:
Every demo module will have:
**Executive Audience**:
**Technical Audience**:
**Sales Engineers**:
**Templates used**:
**Agents invoked**:
**Files created**:
**Files modified** (with permission):
Leave a review
No reviews yet. Be the first to review this skill!
# Download SKILL.md from killerskills.ai/api/skills/showroomcreate-demo-9ugqb6/raw