The method catalog-publisher follows when publishing a design pack catalog as a GitHub + website.
Repo Layout
design-diversity/
README.md ← 프로젝트 목적·사용법·카탈로그 개요
CONTRIBUTING.md ← 새 팩 추가 절차 + 스키마 링크
LICENSE ← 명세·토큰의 재배포 라이선스
catalog.json ← 머신리더블 인덱스
design-packs/{slug}/ prompt.md · tokens.json · preview.png · meta.yaml
site/ ← Next.js 카탈로그 앱
README Structure
Make visitors understand "why·what·how" within 30 seconds:
- 왜 — The problem that PPT·web designs produced by Claude are monotonous. This catalog solves that diversity.
- What — What a design pack is (prompt.md + tokens.json + preview.png + meta.yaml), the current number of packs (by track).
- How to use it — From the pack folder,
prompt.mdcopy and paste into Claude Code and ask "make it in this style." Catalog site link. - Contribution guide (
CONTRIBUTING.md), license.
License / Copyright Hygiene
LICENSE는 What this repo distributesapplies to (design specifications·tokens·documentation). Recommended: MIT or CC BY 4.0.
Boundaries to state in README·CONTRIBUTING: "Each pack is a specification of visual principles learned from public design systems·styles, and does not redistribute any specific product's trademarks·logos·proprietary assets. The source of each pack is stated in meta.yaml." Packs with ambiguous licensing (license: unclear) are cleaned up together with pack-architect before publishing.
Catalog Website Specification
- Stack: Next.js 15 App Router + TypeScript. Data is statically generated (SSG) at build time from the
catalog.json+design-packs/folder. No runtime DB. - Core flow = copy. Visitors (1) browse the pack grid gallery, (2) filter by track (PPT/web)·style axis, and (3) in the pack detail,
prompt.md를 one-click copy. The copy button must be the most prominent. - Pack card:
preview.pngthumbnail + display_name + track badge + axes tags. The input for the production catalog ispublishablepacks, filtered— do not expose non-passing packs by adding a badge. - Pack detail: large preview, full prompt.md (copy button), tokens.json token visualization (color swatches, etc.), meta.yaml source.
- The site itself must be well designed to be persuasive. Restrained typography·clear grid·consistent color.
frontend-designRefer to the aesthetic principles of the skill, but keep the catalog in a neutral tone (so it does not lean toward a specific pack style). - Responsive (mobile to desktop), dark mode optional.
Deployment Procedure
site/Build in —npm run buildconfirm passing.- Vercel preview Deploy → obtain preview URL.
- After passing self-QA (below), report the preview URL to the user.
- Production deployment only after explicit user approval. remains in preview until approval.
- GitHub publication is performed after the user specifies and approves the remote repository.
Publishing gate — statusis not written by a human
What goes out to the catalog statusis not a hand-written string but is generatedfrom the gate results.
publishableThe definition of design-pack-schemaand the required gates per mode are SSOT in the state expression section of. Do not duplicate the expression here — duplicating it means only one side gets fixed and they diverge.
status: passOnly packs that areneeds_review·rejectpacks are not exported with a draft badge. Publishing a pack that failed validation erodes catalog credibility. Separate it into an internal review list.- If the gate artifact (
fidelity_qa/·craft_qa/·render-manifest.json) is absent, fail the build — do not let it pass silently.
Up to v2, it was "escalate after 2 rejections → publish with draft badge." This rule is discarded.
Self QA checklist
Check directly before reporting deployment:
-
npm run buildsucceeds, no console errors - All pack cards render and
preview.pngis not broken - Track and axis filters work
- The prompt.md copy button on the pack detail actually copies to the clipboard
- No layout breakage at mobile width (375px)
-
catalog.json의 팩 수 =design-packs/folder count - In production data,
needs_review·rejectpacks are not included (exists only in the internal review list)
Re-run
If an existing site/or repository exists, do not fully regenerate but apply incrementally (add new pack cards, update catalog.json ). If only "site redeploy" is requested, perform only build and deploy.