---
name: scrollcraft
description: "Premium scroll-driven landing pages; scroll = timeline."
version: 1.0.0
author: 'nateherkai (upstream scroll-craft), ported by Hermes Agent'
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [web-development, landing-page, scrollytelling, animation, design, frontend]
    category: web-development
    homepage: https://github.com/nateherkai/scroll-craft
    related_skills: []
---

# scrollcraft

Scroll is the only input every visitor already knows. This skill treats it as a
timeline: the wheel is a scrubber, the page is a film with real text on top,
and each section behaves differently enough that the visitor keeps going.

**What you produce:** an interview brief, a page grammar, a customer-journey
map, a feeling curve with one engineered peak, a scroll score, one signature
move, assets, one real HTML page on a token-driven design floor, and a strip of
screenshots proving it holds up at every scroll position.

Use for: "scrollytelling", "scroll animation site", "a site where scrolling
plays a video", "Apple-style landing page", "3D scroll world", "make my brand a
scroll experience", "this looks like a template", or any request for a site
that should feel like an experience rather than a document.

## What this is not

It is not "generate a flythrough and drop text on it." That produces one device
applied to a whole page, recognisable at a glance. Four spine rules:

1. **Variety is the product.** At least four device families, never the same
   device twice in a row. Read [references/devices.md](references/devices.md).
2. **The world is photographic** unless the brand is genuinely illustrated.
   Clay/low-poly diorama is banned as a default. Read [references/worlds.md](references/worlds.md).
3. **No continuous chain** unless the brief is literally "one continuous
   journey" (then see [references/worldflight.md](references/worldflight.md)).
4. **A different world is not a different page.** Structure is a separate axis;
   decide it deliberately. Read [references/uniqueness.md](references/uniqueness.md).

## Step 0: The interview

**Always ask the user in chat before building anything.** Real questions, asked
and answered in the conversation, written down — not a brief inferred from the
brand name. Eight questions in one pass:

1. **Vibe in three to five words**, plus up to three references from any medium
   (film, album cover, shop, magazine, game — not "sites you like").
2. **The scroll journey, section by section, in their words.**
3. **The energy curve** — where calm, where intense.
4. **How should someone feel while scrolling, stage by stage, and what is the
   ONE moment they should remember?** Becomes the feeling curve and the peak.
   See [references/feel.md](references/feel.md).
5. **One thing this site should do that no site they have seen does** — the
   seed of the signature move.
6. **How far from premium-minimal?** Offer the range in
   [references/uniqueness.md](references/uniqueness.md) §5: brutalist,
   maximalist, playful, retro, dense, editorial, premium-minimal.
7. **One unbroken world, or distinct scenes?** The biggest structural fork, and
   it is their call.
8. **What assets do they already have?** Footage, photos, product shots, brand
   kit. "Nothing" is fine and means a fully generated world.

Write the answers verbatim into `<workspace>/builds/<name>/BRIEF.md` (use
write_file) before any act planning. BRIEF.md must contain the eight answers,
the feeling curve (one line per act: emotion, then cause), the peak (as the
sentence a visitor would say to a friend), the completed "It's the site where
___" sentence, and any authored silence. If the user is genuinely unreachable
in a fully autonomous run, self-author BRIEF.md, mark it
`Self-authored, not interviewed`, and say so in the report.

## Bootstrap

Run the preflight rather than checking by hand (it catches a stripped ffmpeg
that reports missing filters as syntax errors):

```bash
node <skill>/scripts/doctor.mjs
node <skill>/scripts/workspace.mjs --ensure   # prints workspace, seeds registry
```

Workspace resolution order: `SCROLLCRAFT_HOME` env var; nearest
`.scrollcraft.json` (`{ "workspace": "..." }`) walking up from cwd;
`<project root>/scrollcraft`. Builds live at `<workspace>/builds/<name>/`, the
fingerprint registry at `<workspace>/FINGERPRINTS.md` (seeded from
[templates/FINGERPRINTS.md](templates/FINGERPRINTS.md), starts empty — the gate
stops you repeating *yourself*).

Copy `engine/scrollcraft.js` and `engine/scrollcraft.css` into the build
folder. **Never edit the engine per-project.** Theme with tokens; write your
own markup. Bespoke behaviour is bespoke JS in the page, driven off `--sc-p`
and your own `data-sc-*` attributes.

## Step 1: The brief, journey first

Ask the subject open, in plain prose. Then ask only what Step 0 did not cover:
what is this and who is it for; the one sentence the page installs; the one
next action (one label, used everywhere); what they already have; art
direction from [references/worlds.md](references/worlds.md). Then write the
**journey**: four to seven beats, each a shift in what the visitor knows or
feels. Beats are the spine; a section serving no beat is cut. Confirm the
journey with the user before generating assets — assets are the expensive part.

## Step 2: Grammar, gate, then score

Full detail in [references/uniqueness.md](references/uniqueness.md).

- **Pick a grammar.** Eight, mutually exclusive. Choosing filmic one-shot means
  saying in the report why the other seven lost. Nav, hero and close follow
  from the grammar.
- **Invent the signature move.** One bespoke interaction coded in the page, not
  a parameter change to a kit device. Interview question 5 is the seed.
- **Run the fingerprint gate.** The planned build must differ from every row in
  `<workspace>/FINGERPRINTS.md` on at least 4 of 6 dimensions: grammar, nav
  treatment, hero device, act-sequence shape, close pattern, signature move.
  If it fails, change the plan, not the log.
- **Write the feeling curve before the score table** (method:
  [references/feel.md](references/feel.md)). Then assign each beat a device in
  a written table (beat / device / why).

Checks before building: grammar bans hold; 4+ device families; no device
twice in a row; at most two `scrub` acts; no two adjacent acts with the same
feeling; one peak with the largest span; total page length 8–14
viewport-heights.

## Step 3: Assets

Full pipeline, prompt scaffolds and model notes: [references/assets.md](references/assets.md).

**Hermes-native paths first:**

- **User-supplied footage and photos** — no key, no spend, a first-class route.
  Grade and encode them.
- **The `image_generate` tool** for stills: one style preamble reused verbatim
  in every prompt is what makes six images look like one shoot. Inspect every
  asset (vision_analyze) before use; rerolling beats shipping a bad frame.

**Optional upstream path — kie.ai** (vendored verbatim as
[scripts/kie.mjs](scripts/kie.mjs)): photoreal stills and camera-move clips.
Requires the `KIE_AI_API_KEY` environment variable (export it in your shell;
there is no bundled env file in this port). Check balance with
`node <skill>/scripts/kie.mjs probe`; a still costs cents, a 5s clip more.

```bash
node <skill>/scripts/kie.mjs still "<style preamble>\n\n<scene>" out/01-hero.png --ar 16:9
node <skill>/scripts/kie.mjs shot  "<camera move>" out/01-hero.png out/01.mp4 --dur 5
bash  <skill>/scripts/encode.sh out/01.mp4 assets/01.mp4
bash  <skill>/scripts/encode.sh out/01.mp4 assets/01-m.mp4 mobile
```

**Encode for scrubbing, not playback.** `encode.sh` sets a dense GOP because
seeking walks from the previous keyframe; a normal web encode scrubs like mud.
It also strips audio.

## Step 4: Build the page

Write real HTML — real `<h1>`, real `<p>`, real reading order. The engine reads
`data-sc-*` attributes off your markup and drives it; it never generates DOM.
Start from [references/template.html](references/template.html). Device
patterns: [references/devices.md](references/devices.md). Spacing, type, depth,
colour: [references/taste.md](references/taste.md) — read it before writing
markup. Theme by overriding tokens, six values and two fonts:

```css
:root {
  --sc-canvas: #0A0806;  --sc-surface: #16110E;
  --sc-ink:    #F5EBDD;  --sc-ink-soft: #A2968A;
  --sc-accent: #FF5A3D;  --sc-accent-ink: #15110F;
  --sc-font-display: "Archivo", system-ui, sans-serif;
  --sc-font-text:    "Geist", system-ui, sans-serif;
}
```

## Step 5: Verify by scrolling it

Not optional. Every scroll position is a different frame; failures live between
the two you looked at. Full procedure: [references/verify.md](references/verify.md).

```bash
cd <build project> && npm i playwright-core     # once
node <skill>/scripts/serve.mjs --root . --port 4500 &
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/shots
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/mobile --width 390 --height 844
node <skill>/scripts/shoot.mjs --url http://localhost:4500 --out lab/reduced --reduced-motion
```

The harness walks each act at six positions, waits for scrub video to settle,
reports dead scroll, cues that never reach full opacity, and composited
contrast; it writes a contact sheet. Then read `sheet.png` yourself
(vision_analyze) — the harness proves a clip advances, not that the page means
anything. Run the feel check ([references/feel.md](references/feel.md) §6):
scroll cold, one word per act, diff against BRIEF.md. Where they disagree the
page is wrong, not the brief.

A green run does not cover a real phone (video decoder, autoplay policy, Low
Power Mode). On any reported mobile defect, deploy
[references/device-diag.html](references/device-diag.html) beside the site on
the first round and let the device answer.

## Hard rules (ship-blockers)

No clay diorama default; no "scroll to explore" cues or animated mouse icons;
no `01 / 06` section counters; at most one eyebrow per three sections; no
visible em dashes; vary the copy anchor; no device twice in a row; never build
before the interview; one engineered peak, not zero or three; the close
resolves instead of fading to a footer; curve before devices; one bespoke
signature move; 4-of-6 fingerprint clearance against every row; never edit the
engine; no full-frame dark overlay for contrast (scrim only where text sits);
no text baked into images; no invented statistics; no `transition: all` or
animating width/height/top/left (`transform`/`opacity`; `clip-path` for
wipes); no gradient text or neon glow; no audio on scrub clips; never ship
without Step 5.

## Output

The build folder including BRIEF.md, then a short report: grammar and why the
other seven lost, signature move, fingerprint gate result per row, journey,
feeling curve and peak, feel-check diff, score table, what you generated, what
you verified with screenshots, and what you could not verify. Append the
build's row to `<workspace>/FINGERPRINTS.md`.

## Pitfalls

- `scripts/shoot.mjs` needs Playwright (`npm install playwright` or
  `playwright-core` plus a Chrome install). Hermes' `browser_exec` tool is the
  lighter alternative for scroll-screenshot verification: serve the build,
  scroll in steps, capture screenshots, and inspect them yourself.
- `scripts/kie.mjs` needs `KIE_AI_API_KEY` and paid credit; prefer
  `image_generate` or user assets when the budget is unclear.
- `encode.sh` and `doctor.mjs` expect a full ffmpeg build; distro-stripped
  ffmpeg reports missing filters as command syntax errors — run
  `scripts/doctor.mjs` first.
- Upstream script invocations above are copied from upstream docs and
  unverified by this port beyond `node --check` syntax validation — trust
  `--help`/source if drifted.
- The upstream repo ships worked examples and a change log that are not
  vendored in this port; see the upstream repository if you want them.