A Claude Code skill that turns any application into a beautiful, interactive single-page HTML guide — explaining features, user flows, and recent changes to non-technical people.
Point it at a project. Get back a stunning, self-contained guide that teaches what the app does and how to use it — with scroll-based navigation, animated user journey walkthroughs, interactive feature cards, before/after comparisons, and embedded quizzes.
AI is shipping features faster than ever. But QA cycles, product owner reviews, and stakeholder validation are falling behind — because no one has time to fully understand what changed. Teams fall back to reading PRs, digging through commits, or asking developers. App-explain turns release diffs into human-readable, visual explanations — what changed, why it matters, how it impacts users, what to test — in minutes, not hours.
Stakeholders, new team members, and hands-on users — anyone who needs to understand an application without reading source code.
The skill supports three depth levels to match the audience:
CEOs, investors, clients, board members, product sponsors. They want to understand what the app does and why it matters — not how to click through it step by step.
- What does this app do?
- What problems does it solve?
- What changed since last quarter?
- How does it compare to alternatives?
Result: A concise 5-10 minute interactive guide focused on value, capabilities, and differentiation.
New team members onboarding, QA testers, support agents, power users. They need to learn HOW to use features, including edge cases, permissions, and error handling.
- How do I accomplish X step by step?
- What happens when something goes wrong?
- What can each role see and do?
- What shortcuts and power-user tips exist?
Result: A comprehensive 15-30 minute training guide with detailed workflows, scenario-based quizzes, and troubleshooting.
QA engineers, product owners, tech leads, new developers. They need an exhaustive, dated reference of everything the app does — every feature, every flow, every edge case, every role.
- What does every single feature do in detail?
- What are all the roles and what can each one access?
- What happens in every error state and edge case?
- What integrations exist and how do they work?
Result: A comprehensive, dated document (30-90 min read) with dynamically sized sections based on the app's actual complexity. Includes sidebar navigation, search, permission matrices, and entity relationship diagrams. Regenerate each sprint for up-to-date living documentation.
The output is a single HTML file — no dependencies (except Google Fonts), no setup, works offline. It includes:
- Scroll-based modules with progress tracking and keyboard navigation
- Animated user journey walkthroughs — step-by-step traces of what happens when you use a feature
- Interactive feature cards — visual grids showing capabilities with icons and use cases
- Group chat animations — conversations between user roles or between user and system
- Before/after comparisons — side-by-side panels showing what changed (especially in Recent Changes mode)
- Scenario-based quizzes — "A client needs X by Friday — walk through the steps"
- Glossary tooltips — hover any domain term for a plain-language definition
- Decision trees, flow diagrams, changelog timelines — and 10+ other interactive patterns
- Warm, distinctive design — not the typical corporate documentation look
A complete tour of the application — what it does, its main features, key user flows, and practical tips.
When to use: Onboarding, stakeholder presentations, product documentation, training resources.
A focused guide covering everything that changed since a specific date, tag, or release. Instead of scanning commits, you get a structured, visual explanation:
- New features → explained as user flows, not commit messages
- Improvements → shown with before/after comparisons
- Bug fixes → contextualized (what was broken, what changed)
- Impacted areas → highlighted visually so QA knows what to test
This mode is especially powerful for QA teams preparing test plans, product owners reviewing a sprint, and stakeholders validating a release. The output becomes a shared artifact between dev, QA, and product — not just documentation, but a communication tool that everyone can actually read.
When to use: Release communications, sprint reviews, QA test planning, stakeholder validation, "what's new" pages, team handoffs.
Copy the app-explain folder into your Claude skills directory:
~/.claude/skills/app-explain/
├── SKILL.md
└── references/
├── design-system.md
└── interactive-elements.md
Open any project in Claude Code and say:
"Explain this app"
The skill will:
- Analyze the application (README, routes, UI, configs, git history)
- Ask tuning questions — confirm section count, depth level, and focus areas
- Build a single interactive HTML guide
- Open it in your browser for review
| Prompt | Mode | Depth |
|---|---|---|
| "Explain this app" | Full Overview | Overview (default) |
| "Make a training guide for this app" | Full Overview | Likely Operational |
| "What changed since v2.3.0?" | Recent Changes | Overview (default) |
| "What's new since last release?" | Recent Changes | Overview (default) |
| "Create an onboarding guide for new team members" | Full Overview | Likely Operational |
| "Make a feature tour for the board" | Full Overview | Overview |
| "Explain this app for stakeholders" | Full Overview | Overview |
| "Document this entire app" | Full Overview | Complete |
| "Generate complete documentation for QA" | Full Overview | Complete |
You don't need to specify the depth upfront — the skill will ask you during the tuning phase (Phase 1.5) after analyzing the app. Just say "go" to accept defaults, or adjust the depth, section count, and focus areas.
After analyzing your app, the skill pauses once to let you configure:
Before I build the guide, a few quick settings:
1. Sections: 7 (range: 3-12)
2. Depth: Overview (for stakeholders) or Operational (for hands-on users) or Complete (exhaustive living docs)
3. Focus areas:
✅ User management — rich role system with 4 levels
✅ Dashboard & analytics — 6 chart types, custom filters
✅ Notifications — email + in-app + webhooks
☐ Settings — thin, mostly default values
Defaults look good? Just say "go" or adjust anything above.
Say "go" to accept defaults. Or tweak: "operational, 5 sections, skip notifications" or "complete" for exhaustive documentation.
For Complete depth, the section count is automatically derived from the app's inventory — you don't pick a number. The skill inventories all routes, entities, and integrations, groups them by functional domain, and proposes sections accordingly.
Files are named with the project and depth:
acme-crm-guide-overview.html # Full overview, stakeholder depth
acme-crm-guide-operational.html # Full overview, hands-on depth
acme-crm-guide-complete-2026-03-27.html # Complete living docs (dated)
acme-crm-changes-v2.3-overview.html # Recent changes since v2.3
Complete depth files include a date (YYYY-MM-DD) and a visible header with the commit hash, so you always know which version of the app the documentation describes.
Every screen is at least 50% visual. Max 2-3 sentences per text block. If something can be a diagram, animation, or interactive element — it shouldn't be a paragraph.
The most powerful teaching tool: tracing what happens when someone does something in the app. "You open the dashboard. You see three panels. You click 'New Project.' A form appears." Concrete, sequential, experiential.
Overview guides emphasize value and capabilities — "here's what this app can do for you." Operational guides emphasize workflows and edge cases — "here's exactly how to do it, including what to do when things go wrong." Complete guides emphasize exhaustive coverage — "here's everything the app does, documented for the whole team."
No "What does CRM stand for?" Instead: "A client needs a custom report by Friday — walk through the steps." Quizzes test whether you can use what you learned to solve a real problem.
Each concept gets a metaphor that fits that specific idea. A dashboard is a car dashboard. A notification system is a postal service. Settings are a cockpit with dials. Never the same metaphor twice. (In Operational depth, metaphors are optional — workflows lead.)
app-explain/
├── SKILL.md # Main skill instructions (4.5-phase process)
├── README.md # This file
└── references/
├── design-system.md # CSS tokens, typography, colors, layout
└── interactive-elements.md # 16 interactive element patterns with full HTML/CSS/JS
| Phase | What happens |
|---|---|
| 1 — App Discovery | Deep analysis of README, routes, UI, configs, git history |
| 1.5 — Tuning Questions | One checkpoint: section count, depth, focus areas |
| 2 — Curriculum Design | Depth-aware module arc with focus area distribution |
| 3 — Build | Single HTML file, one module at a time, polish pass |
| 4 — Review | Open in browser, gather feedback |
Forked from the design philosophy of codebase-to-course. Adapted for application features and user flows instead of code explanation.