Skip to main content
ClaudeWave
EN, English
Skill3.2k repo starsupdated 12d ago

pr-demo

The pr-demo skill provides a complete workflow for creating terminal recording demonstrations as GIF files for pull request documentation. It covers environment setup, scripting, recording with asciinema, converting to GIF using agg or SVG using svg-term-cli, and validation approaches. Use this skill when you need to visually demonstrate CLI commands or features in GitHub PRs with polished, embedded video content under file size limits.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/mikeyobrien/ralph-orchestrator /tmp/pr-demo && cp -r /tmp/pr-demo/.claude/skills/pr-demo ~/.claude/skills/pr-demo
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# PR Demo Creation

## Overview

Create polished terminal demos for PRs using asciinema recordings converted to GIF. The workflow: **script → record → convert → embed**.

## Tool Selection

| Goal | Tool Chain | Output |
|------|------------|--------|
| CLI demo for GitHub PR | asciinema → agg | GIF (< 5MB) |
| Smaller file needed | asciinema → svg-term-cli | SVG (< 500KB) |
| TUI screenshot | tmux → freeze | SVG/PNG |

**Default choice:** asciinema + agg (best compatibility, GitHub renders GIFs natively)

## Prerequisites

```bash
# Install tools (macOS)
brew install asciinema
cargo install --git https://github.com/asciinema/agg
npm install -g svg-term-cli  # Optional: for SVG output
```

## Workflow

### 1. Script Your Demo (REQUIRED)

Before recording, write a brief script:

```markdown
## Demo: [feature name]
Duration: ~20-30 seconds

1. [0-3s] Show command being typed
2. [3-10s] Command executes, show key output
3. [10-25s] Highlight the "aha moment" - what makes this valuable
4. [25-30s] Clean exit or final state
```

**Keep it short.** 20-30 seconds max. Show ONE thing well.

### 2. Prepare Environment

```bash
# Clean terminal state
clear
export PS1='$ '                    # Simple prompt
export TERM=xterm-256color         # Consistent colors
# Hide sensitive info (API keys, paths with usernames)
```

Terminal size: **100x24** (readable when scaled down)

### 3. Record

```bash
# Record to .cast file
asciinema rec demo.cast --cols 100 --rows 24

# Execute your scripted demo
# Press Ctrl+D or type 'exit' when done
```

**Tips:**
- Type at readable speed (not too fast)
- Pause briefly after key moments
- If you make a mistake, start over (editing is harder than re-recording)

### 4. Convert to GIF

```bash
# Basic conversion (recommended)
agg demo.cast demo.gif

# With speed adjustment (1.5x faster)
agg --speed 1.5 demo.cast demo.gif

# With custom font size for readability
agg --font-size 14 demo.cast demo.gif
```

**Alternative - SVG (smaller files):**
```bash
svg-term --in demo.cast --out demo.svg --window
```

### 5. Validate (Self-Validation)

Claude can self-validate demos using three approaches:

#### A. Automated Checks (run these first)

```bash
# Check file size (must be < 5MB for GitHub)
ls -lh demo.gif

# Check recording duration from .cast metadata
head -1 demo.cast | jq '.duration // "check manually"'
```

#### B. Visual Validation (LLM-as-judge)

Extract a static frame for Claude to analyze:

```bash
# Option 1: Use svg-term to render a specific timestamp (e.g., 15 seconds in)
svg-term --in demo.cast --out demo-preview.svg --at 15000

# Option 2: Use asciinema cat + freeze for a snapshot
asciinema cat demo.cast | head -500 | freeze -o demo-preview.png

# Option 3: Just convert to GIF and use the file directly
# Claude can read GIF files with the Read tool
```

Then ask Claude to analyze using the Read tool on the image:

**Validation prompt:**
```
Analyze this terminal demo screenshot. Check:
1. Is the text readable (not too small/blurry)?
2. Is the command being demonstrated visible?
3. Is there any sensitive info (API keys, /Users/username paths)?
4. Does the terminal look clean (simple prompt, no clutter)?
5. Is the "aha moment" visible - what value does this demo show?

Rate: PASS or FAIL with specific issues.
```

#### C. Content Validation (parse .cast file)

The `.cast` file is JSON lines - validate the content programmatically:

```bash
# Check what commands were typed (input events)
grep '"i"' demo.cast | head -20

# Check recording duration
head -1 demo.cast | jq -r '.duration | floor'
# Should be 20-30 seconds

# Look for sensitive patterns
grep -iE '(api.?key|password|secret|/Users/[a-z])' demo.cast && echo "WARNING: Sensitive data found!"
```

#### D. Full Validation Checklist

After running the above, verify:

- [ ] File size < 5MB (automated)
- [ ] Duration 20-30 seconds (automated)
- [ ] No sensitive info in .cast (automated)
- [ ] Text readable in preview frame (visual/LLM)
- [ ] Demo shows feature clearly (visual/LLM)
- [ ] Clean terminal appearance (visual/LLM)

### 6. Embed in PR

```markdown
## Demo

![feature demo](./docs/demos/feature-demo.gif)

*Shows: [one-sentence description of what the demo shows]*
```

Store demos in `docs/demos/` or `assets/` directory.

## Quick Reference

| Setting | Recommended Value |
|---------|------------------|
| Duration | 20-30 seconds |
| Terminal size | 100x24 |
| Speed multiplier | 1.0-1.5x |
| Target file size | < 2MB ideal, < 5MB max |
| Font size (agg) | 14-16 |

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| Demo too long | Script it first, show ONE thing |
| Text unreadable | Use --font-size 14+, terminal 100x24 |
| File too large | Use svg-term-cli instead, or increase speed |
| Cluttered terminal | Clean PS1, clear history, hide paths |
| No context in PR | Add one-line description below GIF |

## File Organization

```
docs/demos/
├── feature-name.gif      # The demo
├── feature-name.cast     # Source recording (optional, for re-rendering)
└── README.md             # Recording instructions for future maintainers
```
code-assistSkill

Guides implementation of code tasks using test-driven development in an Explore, Plan, Code, Commit workflow. Acts as a Technical Implementation Partner and TDD Coach — following existing patterns, avoiding over-engineering, and producing idiomatic, modern code.

code-task-generatorSkill

Generates structured .code-task.md files from descriptions or PDD implementation plans. Auto-detects input type, creates properly formatted tasks with Given-When-Then acceptance criteria.

evaluate-presetsSkill

Use when testing Ralph's hat collection presets, validating preset configurations, or auditing the preset library for bugs and UX issues.

find-code-tasksSkill

Lists all code tasks in the repository with their status, dates, and metadata. Useful for getting an overview of pending work or finding specific tasks.

pddSkill

Transforms a rough idea into a detailed design document with implementation plan. Follows Prompt-Driven Development — iterative requirements clarification, research, design, and planning.

playwriterSkill

Browser automation via Playwriter (remorses) using persistent Chrome sessions and the full Playwright Page API.

ralph-docsSkill

Introspect, explain, and improve Ralph Orchestrator using its published llms.txt doc map. Use this skill whenever the user asks questions about Ralph's behavior, wants to understand how a Ralph internal works (event loop, hats, memories, tasks, backends, presets), debug an unfamiliar failure mode, or propose a code change to the ralph-orchestrator repo. The skill teaches the agent to discover authoritative answers from the live docs via llms.txt before guessing, and to scope improvements through the published architecture rather than the local checkout alone.

ralph-e2e-verifierSubagent

Use this agent when you need to run the Ralph orchestrator end-to-end test suite, analyze diagnostic outputs, and generate comprehensive reports of findings. This includes validating backend connectivity, orchestration loop behavior, event parsing, hat collections, memory systems, and error handling. Invoke this agent after making changes to core orchestration logic, before releases, or when debugging integration issues.\\n\\nExamples:\\n\\n<example>\\nContext: User has made changes to the event parsing logic and wants to verify nothing is broken.\\nuser: \"I just modified the event parsing in ralph-core, can you verify everything still works?\"\\nassistant: \"I'll use the ralph-e2e-verifier agent to run the full E2E test suite and analyze the results.\"\\n<Task tool invocation to launch ralph-e2e-verifier>\\n</example>\\n\\n<example>\\nContext: User is preparing a release and needs validation.\\nuser: \"We're preparing to release v0.5.0, please run the E2E tests\"\\nassistant: \"I'll launch the ralph-e2e-verifier agent to run comprehensive E2E tests across all backends and generate a release readiness report.\"\\n<Task tool invocation to launch ralph-e2e-verifier>\\n</example>\\n\\n<example>\\nContext: User notices orchestration issues and wants diagnostics analyzed.\\nuser: \"Ralph seems to be selecting the wrong hats, can you investigate?\"\\nassistant: \"I'll use the ralph-e2e-verifier agent to run E2E tests with diagnostics enabled and analyze the hat selection decisions.\"\\n<Task tool invocation to launch ralph-e2e-verifier>\\n</example>