Skills Showcase Deck-Builder Refactor

Fresh-start rebuild of the skills showcase at gskillpacks.com. The current informational pages (Workflows, Packs, Catalog, Inspect, Benchmarks, Follow) are replaced by a deck-building card-game experience that is both the brand's visual identity and a functional tool for assembling skill libraries.

Users browse sealed booster packs (categories), tear them open to reveal skill cards, inspect card stats (benchmarks, platform, tags), and add cards into deck slots that map to the four canonical workflow types. Building a deck produces actionable output: a copyable CLI command (npx skillpacks install-deck ...) and a downloadable project.json config.

The site uses dual branding: card-game terminology as the primary voice (the GSkillPacks brand), with technical terms in parentheticals and tooltips so developers always know what they're actually installing.

The current showcase pages and components will be archived once the deck-builder replacement is live.

from prompt Terminology rename scoped to showcase only. Docs and CLI keep current terminology.

Two Archetypes

from prompt Archetypes are the two workflow tempo classes. Individual decks are named [descriptor] + [archetype] by default. Canonical GSkill decks follow this convention; users can rename their custom decks freely.

Four Canonical Decks

Each deck combines a domain descriptor with an archetype on a 2×2 matrix (domain × tempo):

inferred The current showcase presents skills as a flat searchable catalog with workflow documentation pages. Users can read about packs and skills but don't get an intuitive feel for how to compose their own skill library.

The deck-building metaphor makes the selection process tactile and exploratory. Users tear open packs, inspect cards, and assemble decks — which communicates the composable nature of the system in a way that a table of names and descriptions cannot.

Additionally, the existing card-game primitives (SealedPack, SkillCard, PackOpener) already exist on a hidden /prototype debug page. The investment is partially made but invisible to users.

inferred

• Primary: Developers evaluating GSkillPacks who want to understand what skills exist and how to assemble them into workflows (decks). The deck-builder is both a discovery tool and a configuration wizard.
• Secondary: Existing users configuring new projects — they already know the system but want a faster way to pick packs for a new repo.

inferred Developer tool interactive catalog / configuration UI with a card-game brand wrapper. Not a standalone game — the card-game metaphor is a UX convention for real skill library management and brand differentiation.

from prompt

• No other AI skill/agent marketplace uses a deck-builder metaphor
• The card-game framing makes the abstract concept of "composing AI workflow toolchains" concrete and engaging
• Dual branding keeps it accessible: card-game voice for brand personality, technical parentheticals for clarity
• The actionable output (CLI command + config download) bridges the gap from "fun browsing" to "actually installed in my project"

confirmed

• No real trading/collecting system with accounts, inventories, or progression
• Not replacing the npm CLI distribution — the showcase is visual, the CLI is the install mechanism
• Not designing new animation primitives (existing state machine covers the interaction model)
• Not an e-commerce or paid card system
• Not renaming terminology outside the showcase (docs, CLI, SKILL.md frontmatter stay as-is)

Assumptions

Unknowns to Resolve Downstream

1. Deck composition UX: How does a user actually add cards to a deck? Drag-and-drop from opened pack? Click-to-add? Auto-suggest based on archetype?
2. Page/route structure: Is the entire site one interactive canvas, or are there distinct routes (e.g., / shelf, /deck/:id builder, /card/:id detail)?
3. Mobile experience: The current card animations are gesture-heavy (drag-to-tear). How does this work on mobile viewports?
4. Data generation pipeline: Does the existing generate-skills-showcase-data.mjs output need restructuring for deck-builder data shapes?
5. shadcn registry browser tie-in: Does the showcase double as the shadcn-style registry browser, or are those separate surfaces?

What's already built and ready to promote from /prototype to production:

Key Reference Documents

• tasks/pack-card-hierarchy.md — 7 sets mapped to 157 skills with TypeScript data
• docs/decks.md — Four deck archetypes on domain × tempo matrix
• docs/skillpacks-npm-distribution.md — CLI commands, manifest schema, deck metadata
• alignment/uat-card-pack-migration.html — Prior UAT alignment for card pack migration
• apps/skills-showcase/alignment/animation-state-machine.html — Animation state machine docs

The concept is ready for ICP analysis with the following inputs:

• Primary beneficiary hypothesis: Developers evaluating GSkillPacks for project adoption
• Secondary beneficiary: Existing users configuring new projects
• Market structure: Single-sided (developer tool catalog, not a marketplace)
• Assumptions to test first: Whether the deck-builder metaphor resonates with developers vs. feeling gimmicky; whether the 2 archetypes (RD/AFPS) and [descriptor]+[archetype] naming convention cover real workflow patterns
• Existing evidence: Devtool research docs in research/ (positioning, adoption, DX journey, user map, monetization) provide market context

Answer these gates after reviewing the concept, constraints, and assumptions above.