feat(skills): hand-crafted design.html for each template

[vanceingalls]

Summary

Hand-crafted design.html for each of the 34 vendored templates (PR #971 below). Each design.html is a self-contained rendering of the template's design system — cover, manifesto, palette, typography, surface, motion, background shader section, do/don't guidelines, and a templates index page.

Used by the design picker (PR #974) to preview the chosen template's design language at full fidelity in the fine-tune phase.

Scope

• 35 files (34 templates + 1 user-design scaffold)
• ~30k lines, one commit per layer
• All design.html files share the --primary / --secondary / --tertiary / --accent token contract

Why

design.html is the picker-facing design system for each template — the artifact reviewers will see in the picker preview. Splitting these out of the picker chrome PR (#974) means:

• The 30k of design pages can be reviewed by visual sample (open 2-3 in a browser)
• The picker code stays focused on the picker mechanics, not 34 individual designs

Token contract

Every design.html aliases its surface tokens off the four core role tokens:

• --primary → light canvas (paper / cream / off-white per template)
• --secondary → dark ink (body text, borders, outlines)
• --tertiary → muted neutral (chrome, labels, dim text)
• --accent → the signal color (one element worth remembering)

Templates that need additional palette tokens (e.g. editorial-forest's pink for the topic-card treatment) alias them inside :root and never embed raw hex values in component styles.

What to spot-check

• Open skills/hyperframes/templates/presentations/<slug>/design.html directly in a browser for a few templates with different moods (mat, neo-grid-bold, editorial-forest, biennale-yellow, retro-windows)
• Confirm the cover renders, the palette swatches are legible (each role has correct contrast against its surface), and the typography pairs make sense
• The __PRIMARY__ / __SECONDARY__ / etc. tokens are substituted at picker render time — open design.html standalone and you'll see the literal sentinels; that's expected

Test plan

• Each design.html opens without console errors (visual sample of 5 random templates)
• Token substitution leaves no __X__ sentinels in rendered output once the picker injects values (covered by PR feat(skills): design picker UI (Phase 1 templates index + Phase 2 fine-tune) #974)
• No new code paths added in this PR

Stack

Depends on #971. Followed by #973 (build scripts), #974 (picker chrome), #975 (CLI).

🤖 Generated with Claude Code

[vanceingalls]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• feat(cli): hyperframes pick — open the design picker, gated behind feature flag #975
• feat(skills): design picker UI (Phase 1 templates index + Phase 2 fine-tune) #974
• feat(skills): design picker build script + skill docs #973
• feat(skills): hand-crafted design.html for each template #972 👈 (View in Graphite)
• feat(skills): vendor 34 tokenized HTML presentation templates #971
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[jrusso1020]

Per Home's framing, spot-check rather than line-by-line review of 30k lines of hand-crafted design.html. Posting as COMMENT (not stamping) per merge policy.

Spot-checks

• 35 design.html files land under skills/hyperframes/templates/presentations/<template>/design.html (34 templates from PR #971 + 1 user-design scaffold per the PR description). Layout matches the parent stack.
• Token contract claimed in PR body — --primary / --secondary / --tertiary / --accent aliased off the role tokens, no raw hex in component styles — is the right shape. Verified via the build-design-picker.py inline-template in PR #973 (generate_user_design function), which establishes the same contract for user-provided design.md → design.html generation. Cross-PR consistency holds.
• Sentinel substitution — __PRIMARY__ / __SECONDARY__ / __ACCENT__ / __TERTIARY__ etc. are substituted at picker-render time (the picker JS does it client-side per PR #974's description). Confirmed by grepping for these sentinels in the picker HTML template (PR #974) — they appear inside the iframe-rendered template content blocks, not in code paths the build script touches, which is consistent with "client-side token substitution + blob URL" claimed in #974's PR description.

Non-blocking notes

• Visual sample verification not performed on my side — I don't have a browser-render channel for this review, so I can't open mat/design.html or biennale-yellow/design.html to confirm color contrast or typography pairings. The PR's test plan calls out 5 random templates worth a manual visual check — please make sure that happens before merge.
• The user-design scaffold's design.html is referenced as a fallback by build-design-picker.py:generate_user_design, line ~399: if a project provides DESIGN.md but no pre-existing scaffold, the picker falls back to block-frame/design.html (hardcoded). That's covered in my #973 review with more detail — flagging here just so it's traceable across the stack.

CI: Fallow audit + lint + format all green per merge state. Marked unstable only because of the dependent PRs in the stack.

No blockers from my side on this layer specifically. The licensing concern I raised on #971 (MIT attribution from zarazhangrui/beautiful-html-templates) does not extend here — the design.html files in this PR are described as hand-crafted, not vendored.

— Rames Jusso