[IDEA] Support reusable theme packages and theme generation

Frontend Slides already has a strong foundation for visual discovery: safe presets, the bundled bold-template-pack, and the custom wildcard design option.

From what I found, custom wildcard design already acts like a one-off theme creator for a specific deck: the skill generates a custom visual direction, and if the user chooses it, that preview's CSS, palette, typography, layout rhythm, and visual language become the recipe for the final deck.

The missing piece is persistence and reuse. That custom style does not appear to become a reusable theme package. I could not find a documented contract for saving it, reusing it in future decks, sharing it with a team, or installing external theme packages.

Current behavior observed

Style selection appears to be tied to bundled repository files:

• STYLE_PRESETS.md for safe presets
• bold-template-pack/selection-index.json for bundled template metadata
• bold-template-pack/templates/*/preview.md for shortlisted preview cards
• bold-template-pack/templates/*/design.md for the final selected design recipe
• a custom wildcard design option, useful for a single deck, but apparently not reusable as an installed theme

This makes the bundled bold-template-pack internally extensible, but I could not find a documented way to add a separate package such as my-company-theme-pack and have the skill discover it during style selection.

Proposal

Evolve custom wildcard design into a persistent, reusable theme system with two complementary paths:

1. Consume custom theme packages created manually by users, teams, or designers.
2. Create theme packages from user references, using the existing custom visual generation flow as the starting point.

A theme package could follow a contract close to the current bold-template-pack structure:

my-theme-pack/
  theme-pack.json
  selection-index.json
  templates/
    my-theme/
      preview.md
      design.md
      assets/

External theme packages

Suggested behavior:

1. Let users point the skill at one or more local directories or repositories containing theme packages.
2. Define a small manifest, for example theme-pack.json, with name, version, author, description, and compatible Frontend Slides version.
3. Reuse the current selection-index.json fields where possible: slug, name, tagline, mood, tone, formality, density, scheme, best_for, avoid_for, preview_md, and design_md.
4. Merge bundled and custom theme candidates during Phase 2, preserving source attribution so users can tell built-in and custom themes apart in the chat response.
5. Keep the same progressive-disclosure rule: read the custom pack index first, then only shortlisted preview.md files, then exactly one selected design.md.
6. Document validation expectations: fixed 1920x1080 stage compatibility, self-contained final output, font/asset handling, and no internal process labels in rendered slides.

Theme creator from user references

In addition to consuming ready-made packages, the skill could create a reusable theme from references supplied by the user, such as:

• brand guidelines or design-system documentation
• screenshots of websites, apps, slides, or moodboards
• logos, palettes, fonts, and brand assets
• an already generated deck whose visual language should become reusable

Possible flow:

1. Collect and inspect the user's references.
2. Extract reusable tokens and rules: palette, typography, type scale, spacing, layout grammar, decorative motifs, image treatment, motion style, and accessibility constraints.
3. Generate preview.md and design.md from those references.
4. Validate the package against Frontend Slides requirements: fixed 1920x1080 stage, self-contained final deck, overflow-safe layouts, resolvable assets/fonts, and no process text visible on slides.
5. Save the result as a local/private theme package for future decks.

Why this would help

• Teams could maintain reusable brand systems without forking frontend-slides.
• Designers could publish theme packs independently from the core skill.
• Users could turn real references into reusable themes without manually writing preview.md and design.md.
• The current bold-template-pack already looks close to a reusable package contract, so this could be an incremental evolution.
• custom wildcard design would become more than a per-deck choice: it could become a reusable asset.

Possible acceptance criteria

• Documentation explains how to create, install, and use a custom theme package.
• Documentation explains how to turn user references into a reusable theme.
• The skill can include at least one external/custom theme in Phase 2 visual discovery.
• The skill can save an approved custom wildcard design as reusable preview.md + design.md files.
• Custom packages follow the same progressive-disclosure loading model as bold-template-pack.
• Missing or invalid custom packages fail gracefully and fall back to bundled presets/templates.
• A minimal sample theme package is included as a reference.