# What's Inside the Skill (plain-language tour)

**Repo:** https://github.com/Rweiss1014/skyvale-quiz-flight
**In the workshop:** participants BUILD this skill themselves in Part 1 of the
handout, by pasting the skill text and letting Claude fetch the support files.
**One-command fallback:** `npx skills add Rweiss1014/skyvale-quiz-flight`

## First, what is a "skill"?

A Claude Code skill is just a folder of instructions plus any files those
instructions need. Once it's on your machine, Claude Code gains a new ability.
Here, that ability is "build a Skyvale quiz game."

## The contents

```
skyvale-quiz-flight/
├── SKILL.md                  ← The recipe Claude follows (participants paste this by hand)
├── README.md                 ← Human docs plus Rachel's "How I made this" story
├── LICENSE                   ← MIT (yes, people can use this at work)
├── references/
│   └── customization.md      ← Deep-dive: config schema, scoring math, SCORM bridge
├── docs/
│   └── skyvale_collage.png   ← Screenshots for the README
└── assets/
    ├── index.html            ← THE ENTIRE GAME. About 17KB, one file. 3D world,
    │                            flight physics, fire mechanic, scoring, SCORM.
    ├── three.min.js          ← Three.js, the 3D graphics library (about 600KB)
    └── config.sample.json    ← Example questions showing the exact format
```

The headline: the whole game engine is one 17KB HTML file. No build step, no
dependencies to install, nothing server-side. Any static file host can serve it.
(The workshop build creates SKILL.md, assets/, and references/customization.md.
The README, LICENSE, and collage are repo extras that the skill doesn't need to
run.)

## What happens when someone uses it

When a person asks Claude Code for "a quiz game" (or "gamified training," or
literally "the dragon game"), the skill walks Claude through six steps:

1. **Gather.** Ask for the topic and questions; end with exactly 4 (3 gates plus
   1 fire).
2. **Validate and adapt.** Wrong answer counts get adapted (the fire question
   must have exactly 3). No questions provided? Claude drafts some to react to.
3. **Copy the engine verbatim.** `index.html` and `three.min.js` are treated as
   a black box. The skill explicitly forbids regenerating the game code. This is
   the quality-control move: the flight model took real playtesting to get
   right, and nobody gets to "improve" it by accident.
4. **Write `config.json`.** The ONLY file that changes between games. Question
   text, answers, which one is correct, the "why" feedback line, passing score.
5. **Validate the config.** A tiny Python script asserts the rules (3 gates, 2
   to 4 answers each, exactly 3 fire answers, correct-index in range) before
   anyone plays. A bad config fails loudly instead of weirdly.
6. **Test and ship.** Serve locally, confirm the user's first question shows up
   (not the sample), then guide deploy: static host, or into an LMS as SCORM.

## Why this design matters (the workshop talking point)

The skill separates **the engine** (hard, playtested, frozen) from **the
content** (easy, yours, one small JSON file). That's the same separation every
good learning tool makes, and it's why a room full of non-developers can each
walk out with a different working game in 30 minutes: everyone shares the
engine; nobody shares the questions.

## What each participant walks away with

Two things. A working skill on their machine that they built themselves and can
study, copy, and imitate for their own workflows. And a complete game (three
files: `index.html`, `three.min.js`, `config.json`) with their questions in it,
including a built-in SCORM bridge reporting score, completion, pass/fail
(passing is 300 of a possible 630), and a telemetry JSON (first-try rate,
decision latency, aim corrections) for the L&D folks who want the data.