Skills Showcase Deck-Builder Refactor
Rebuild gskillpacks.com from an informational skill catalog into an interactive deck-building experience where users tear open packs, inspect skill cards, and assemble workflow decks — with dual card-game / technical branding.
Concept Summary
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 five canonical workflow decks. 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.
Dual Branding Map
from prompt Terminology rename scoped to showcase only. Docs and CLI keep current terminology.
| Card Game (GSkillPacks) | Technical | Current Term | Scope |
|---|---|---|---|
| Deck | Named workflow sequence | Deck | Showcase UI |
| Archetype | Workflow tempo class | RD / AFPS | Showcase UI |
| Pack / Booster | Category / Pack | Pack | Showcase UI |
| Card | Skill | Skill | Showcase UI |
| Tear open / Collect | Install / Enable | Install | Showcase UI |
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.
Five Canonical Decks
Each canonical deck combines a domain descriptor with a tempo archetype. Business and developer domains each have rapid and deliberate decks; the game domain currently has a deliberate Game AFPS deck and no rapid feeder deck.
RDBusiness
RDDeveloper
AFPSBusiness
AFPSDeveloper
AFPSGame
Problem Hypothesis
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.
Beneficiary Hypothesis
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.
Product Category Guess
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.
Value Wedge
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"
Constraints
| Constraint | Source | Rationale |
|---|---|---|
| Existing card primitives (SealedPack, SkillCard, PackOpener, BottomSheet, debug harness) are the starting asset library — promote, don't rewrite | from repo | 678-line SealedPack + full animation state machine already built |
Current generated inventory: 373 platform entries, 190 unique mirrored skills, 179 unique pack skills, 11 unique global skills, and 41 active packs; old 157-card / 7-set map in tasks/pack-card-hierarchy.md is historical prototype display scope | from repo | Content inventory exists, but deck-builder set data must be regenerated from apps/skills-showcase/public/assets/skills-data.js before implementation |
Must coexist with npm skillpacks CLI distribution | from repo | Showcase is visual; CLI is the install mechanism |
| Must coexist with shadcn-style repo distribution | from prompt | Both distribution paths feed from the same manifest |
| Next.js 16 + React 19 + Framer Motion + Tailwind 4 stack stays | from repo | No framework migration |
| No GitHub Actions | from repo | Project convention |
| Fresh start on page structure (not retrofitting existing pages) | from prompt | User decision — deck-builder IS the experience |
| Dual branding scoped to showcase only | from prompt | Docs and CLI keep current terminology |
| Archive old showcase once replacement is live | from prompt | User request — preserve old code in archive, don't delete |
Non-Goals
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
Assumptions
| Assumption | Source | Status | What would change it |
|---|---|---|---|
The historical 7 booster-set prototype map from pack-card-hierarchy.md can seed the sealed-pack experience after current generated data is regenerated into deck-builder set data | from repo | Provisional | User wants a different grouping, fewer/more sets, or generated-data analysis shows the old display grouping is no longer useful |
The RD and AFPS archetypes plus five canonical decks (VARD, ORD, Business AFPS, Devtool AFPS, Game AFPS) from docs/decks.md are the deck-building structure users select from | from repo | Provisional | User wants custom/freeform deck building beyond the [descriptor]+[archetype] convention |
| Users understand the deck-builder metaphor without onboarding | inferred | Assumed | User testing reveals confusion; an onboarding flow would be needed |
| CLI command + project.json export is sufficient to bridge browsing to installation | inferred | Assumed | Users expect a one-click web install or direct GitHub integration |
Unknowns to Resolve Downstream
- 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?
- Page/route structure: Is the entire site one interactive canvas, or are there distinct routes (e.g.,
/shelf,/deck/:idbuilder,/card/:iddetail)? - Mobile experience: The current card animations are gesture-heavy (drag-to-tear). How does this work on mobile viewports?
- Data generation pipeline: Does the existing
generate-skills-showcase-data.mjsoutput need restructuring for deck-builder data shapes? - shadcn registry browser tie-in: Does the showcase double as the shadcn-style registry browser, or are those separate surfaces?
Existing Asset Inventory
What's already built and ready to promote from /prototype to production:
| Component | Lines | Status | Notes |
|---|---|---|---|
SealedPack.tsx | 678 | Prototype | Tear-to-open with horizontal drag, shimmer foil, page curl |
SkillCard.tsx | 90 | Prototype | Flippable card with front/back faces, 180x252px |
CardFace.tsx | 72 | Prototype | Type badge, benchmark grade, title, command, version |
PackOpener.tsx | 385 | Prototype | Fan-out drawer with staggered springs, collapse-to-target |
BottomSheet.tsx | 194 | Prototype | Slide-up drawer with drag-to-dismiss |
debug/* | ~500 | Prototype | Full animation debug harness (keep for dev, hide in prod) |
Key Reference Documents
tasks/pack-card-hierarchy.md— historical 7-set prototype display map with 157 repo-managed Claude pack roots; regenerate current deck-builder set data fromapps/skills-showcase/public/assets/skills-data.jsdocs/decks.md— Five canonical decks across business, developer, and game domainsdocs/skillpacks-npm-distribution.md— CLI commands, manifest schema, deck metadataalignment/uat-card-pack-migration.html— Prior UAT alignment for card pack migrationapps/skills-showcase/alignment/animation-state-machine.html— Animation state machine docs
ICP Readiness
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 RD/AFPS archetypes 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
business-discovery pack is not currently enabled in .agents/project.json. ICP analysis requires: /pack install business-discovery
Review Gates
Answer these gates after reviewing the concept, constraints, and assumptions above.
Idea Identity & Slug
Is "Skills Showcase Deck-Builder" the right concept identity, and skills-showcase the right slug for the product path?
Scope & Non-Goals
Are the constraints and non-goals listed above correct and complete for the deck-builder refactor?
ICP Readiness
Is the concept ready for ICP analysis with the beneficiary hypotheses listed, or does it need more scoping first?
Artifact Destination & Proposed File Changes
Approve the output files that will be created on final approval:
research/skills-showcase/idea-brief.md— canonical idea briefresearch/skills-showcase/idea-brief-interview.md— interview logresearch/.progress.yaml— product path manifest (new file)
Post-Approval Route
After final approval, what should the agent do next?
Compile YAML
Use feedback YAML for emphasis requests, concerns, or clarification before answering all gates. Use final answers YAML only when every required gate is answered.