cdragon 0.1.0

package/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md

@@ -0,0 +1,35 @@
+# Issue tracker: GitLab
+
+Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
+
+## Conventions
+
+- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
+- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
+- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
+- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
+- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
+- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
+- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
+
+Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
+
+## Merge requests as a triage surface
+
+**MRs as a request surface: no.** _(Set to `yes` if this repo treats external merge requests as feature requests; `/triage` reads this flag.)_
+
+When set to `yes`, MRs run through the same labels and states as issues, using the `glab mr` equivalents:
+
+- **Read an MR**: `glab mr view <number> --comments` and `glab mr diff <number>` for the diff.
+- **List external MRs for triage**: `glab mr list -F json`, then keep only MRs whose author is not a project member/owner (a contributor's MR, not a maintainer's in-flight work).
+- **Comment / label / close**: `glab mr note`, `glab mr update --label`/`--unlabel`, `glab mr close`.
+
+Unlike GitHub, GitLab numbers issues and MRs separately, so `#42` is unambiguous once you know which surface the maintainer means.
+
+## When a skill says "publish to the issue tracker"
+
+Create a GitLab issue.
+
+## When a skill says "fetch the relevant ticket"
+
+Run `glab issue view <number> --comments`.

package/skills/setup-matt-pocock-skills/issue-tracker-local.md

@@ -0,0 +1,19 @@
+# Issue tracker: Local Markdown
+
+Issues and PRDs for this repo live as markdown files in `.scratch/`.
+
+## Conventions
+
+- One feature per directory: `.scratch/<feature-slug>/`
+- The PRD is `.scratch/<feature-slug>/PRD.md`
+- Implementation issues are `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01`
+- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
+- Comments and conversation history append to the bottom of the file under a `## Comments` heading
+
+## When a skill says "publish to the issue tracker"
+
+Create a new file under `.scratch/<feature-slug>/` (creating the directory if needed).
+
+## When a skill says "fetch the relevant ticket"
+
+Read the file at the referenced path. The user will normally pass the path or the issue number directly.

package/skills/setup-matt-pocock-skills/triage-labels.md

@@ -0,0 +1,15 @@
+# Triage Labels
+
+The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
+
+| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
+| -------------------------- | -------------------- | ---------------------------------------- |
+| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
+| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
+| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
+| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
+| `wontfix`                  | `wontfix`            | Will not be actioned                     |
+
+When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
+
+Edit the right-hand column to match whatever vocabulary you actually use.

package/skills/tdd/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: tdd
+description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
+---
+
+# Test-Driven Development
+
+## Philosophy
+
+**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
+
+**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
+
+**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
+
+See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+
+## Anti-Pattern: Horizontal Slices
+
+**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
+
+This produces **crap tests**:
+
+- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
+- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
+- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
+- You outrun your headlights, committing to test structure before understanding the implementation
+
+**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
+
+```
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+  ...
+```
+
+## Workflow
+
+### 1. Planning
+
+When exploring the codebase, read `CONTEXT.md` (if it exists) so that test names and interface vocabulary match the project's domain language, and respect ADRs in the area you're touching.
+
+Before writing any code:
+
+- [ ] Confirm with user what interface changes are needed
+- [ ] Confirm with user which behaviors to test (prioritize)
+- [ ] Identify opportunities for deep modules (small interface, deep implementation) — run the `/codebase-design` skill for the vocabulary and the testability checks
+- [ ] List the behaviors to test (not implementation steps)
+- [ ] Get user approval on the plan
+
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
+
+**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
+
+### 2. Tracer Bullet
+
+Write ONE test that confirms ONE thing about the system:
+
+```
+RED:   Write test for first behavior → test fails
+GREEN: Write minimal code to pass → test passes
+```
+
+This is your tracer bullet - proves the path works end-to-end.
+
+### 3. Incremental Loop
+
+For each remaining behavior:
+
+```
+RED:   Write next test → fails
+GREEN: Minimal code to pass → passes
+```
+
+Rules:
+
+- One test at a time
+- Only enough code to pass current test
+- Don't anticipate future tests
+- Keep tests focused on observable behavior
+
+### 4. Refactor
+
+After all tests pass, look for [refactor candidates](refactoring.md):
+
+- [ ] Extract duplication
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles where natural
+- [ ] Consider what new code reveals about existing code
+- [ ] Run tests after each refactor step
+
+**Never refactor while RED.** Get to GREEN first.
+
+## Checklist Per Cycle
+
+```
+[ ] Test describes behavior, not implementation
+[ ] Test uses public interface only
+[ ] Test would survive internal refactor
+[ ] Code is minimal for this test
+[ ] No speculative features added
+```

package/skills/tdd/mocking.md

@@ -0,0 +1,59 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint

package/skills/tdd/refactoring.md

@@ -0,0 +1,10 @@
+# Refactor Candidates
+
+After TDD cycle, look for:
+
+- **Duplication** → Extract function/class
+- **Long methods** → Break into private helpers (keep tests on public interface)
+- **Shallow modules** → Combine or deepen
+- **Feature envy** → Move logic to where data lives
+- **Primitive obsession** → Introduce value objects
+- **Existing code** the new code reveals as problematic

package/skills/tdd/tests.md

@@ -0,0 +1,61 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```

package/skills/to-html/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: to-html
+description: Use when the user asks to organize, summarize, lay out, or save content as an HTML file/document, or wants content rendered as a standalone shareable page/report — phrases like "html로 정리", "html로 뽑아/만들어/저장", "정리해서 html로", "시각화해서 저장". NOT for app UI code or React/components inside a project.
+---
+
+# Visualizing as HTML
+
+## Overview
+Turn arbitrary content (notes, meeting summaries, analyses, proposals, FGI reports) into a **single self-contained `.html` file** styled by a chosen brand design system bundled in `designs/`.
+
+Two things are decided every time:
+1. **Which brand design** — one of **60+ brand design systems** in `designs/` (catalog: `designs/INDEX.md`).
+2. **How much motion/interaction** — minimal & static by default; richer only when the content earns it.
+
+**Core principle: the user wants to read the content, not the decoration.** Design serves legibility first. Add interaction/animation only when it makes the content clearer or the user asked for it.
+
+## Workflow
+1. Confirm what content goes in and that they want an HTML file. If the content is ambiguous, ask what to include — never invent content.
+2. **Pick the design** (see *Design Selection*). Skim `designs/INDEX.md`; honor any brand the user named, otherwise infer from the content's domain and desired feel.
+3. **Read the chosen DESIGN.md fully** — `designs/<slug>.DESIGN.md` (exact filename is in INDEX.md), next to this SKILL.md. Follow its tokens, components, voice, and Motion & Easing section. Do not design from memory; the file is the source of truth.
+4. **Decide richness** (see *Minimal vs Rich*). Default = clean & static.
+5. Build ONE self-contained HTML file: inline `<style>`, system or CDN fonts only, no build step — it must work by double-clicking. Keep the source content's language (Korean stays Korean).
+6. **Save to the current working directory** with a descriptive filename + `.html`.
+7. **Open it** — launch the saved file in the default browser with `open` (see *Showing the result*). Then tell the user the path and state which design + richness level you chose (one line), so they can redirect.
+
+## Design Selection
+**60+ brand design systems** live in `designs/` (full list with category + accent + one-liner in `designs/INDEX.md`). Pick one per request:
+
+1. **Explicit request wins.** If the user names a brand ("Toss 스타일로", "Linear처럼", "apple로"), use that file directly.
+2. **Otherwise infer** from the content's domain + desired feel. Skim INDEX.md and match by category:
+
+| Content / vibe | Good-fit categories & examples (slug) |
+|---|---|
+| Dense data, dashboards, reports, admin, B2B, 회의·FGI·CS 정리 | `developer-tools` / `backend-devops` / `productivity` — Ant Design (`alipay`), IBM Carbon (`ibm`), Vercel Geist (`vercel`), Linear (`linear.app`), MongoDB (`mongodb`), Sanity (`sanity`) |
+| Narrative / showcase / pitch / vision / 발표·제안 | `consumer-tech` / design-tools — Apple HIG (`apple`), Airbnb (`airbnb`), Framer (`framer`), Figma (`figma`) |
+| Money / trust / 금융·핀테크 | `fintech` — Toss (`toss`), Alipay (`alipay`), banksalad (`banksalad`), kakaobank (`kakaobank`), kakaopay (`kakaopay`), wise (`wise`) |
+| AI product / model / 연구 | `ai` — Cursor (`cursor`), ElevenLabs (`elevenlabs`), Mistral (`mistral.ai`), Cohere (`cohere`), Upstage (`upstage`) |
+| Commerce / 쇼핑·커머스 | `ecommerce` / consumer — Coupang (`coupang`), Gmarket (`gmarket`), zigzag (`zigzag`), Karrot (`karrot`) |
+| Korean public / 정부·공공 | `government` — KRDS (`krds`) |
+
+3. **Default when unclear:** Apple (`apple`) for narrative/showcase, Ant Design (`alipay`) for dense documents — the safe, legible baselines.
+
+**Depth caveat:** some entries are full UI systems (tokens + components — e.g. `apple`, `alipay`, `ibm`, `vercel`, `mongodb`, `sanity`), others are brand-asset kits (logo + palette + voice, lighter on component specs — e.g. `cohere`, `elevenlabs`, `mistral.ai`). For laying out a document prefer a full UI system; reach for a brand-asset kit when the user wants that brand's *identity* (color/logo/voice) more than its components.
+
+## Minimal vs Rich (motion / interaction)
+**Default: minimal & static.** Clean layout, no JS, at most subtle CSS hover/transition allowed by the DESIGN.md Motion section.
+
+Escalate to interaction/animation ONLY when at least one is true:
+- The user explicitly asks ("인터랙티브", "애니메이션", "동적으로", "발표용").
+- The content genuinely benefits — e.g.:
+  - Long document → sticky table of contents, smooth-scroll, collapsible sections.
+  - Many items, steps, or a timeline → scroll-reveal / progressive disclosure.
+  - Tabular or comparison data → sortable/filterable table or tabs.
+  - Showcase content (e.g. `apple`, `framer`) → tasteful scroll-driven section reveals.
+
+Keep it tasteful and on-brand: follow the chosen DESIGN.md **Motion & Easing** (Ant = calm ~0.2–0.3s `cubic-bezier(0.645,0.045,0.355,1)`, never bouncy; Apple = slow, confident, pause-heavy). When in doubt, less.
+
+### Red flags — STOP, you're over-decorating
+- Adding animation to a one-page summary the user just wants to scan.
+- JS that doesn't change comprehension.
+- Motion that fights the brand's calm.
+
+All of these mean: strip it back to static.
+
+## Showing the result
+After saving, always open the file in the default browser with the OS `open` command:
+```bash
+open "<absolute path>.html"
+```
+Just `open` — don't branch on chrome-devtools / agent-browser. The saved `.html` is the deliverable; if `open` errors, report the path and move on.
+
+## Output requirements
+- One file, fully self-contained (inline CSS; JS only if richness genuinely calls for it).
+- Responsive and readable; semantic HTML.
+- Faithful to the DESIGN.md tokens — colors, type scale, border-radius, spacing, shadows. No invented hexes or off-brand fonts.
+- Preserve the source meaning and language; summarize/structure, don't fabricate.
+- **Credit the design.** Record which brand design system was used, in two places:
+  1. A discreet, on-brand **footer line** at the bottom of the page — e.g. *"Apple 디자인 시스템 기반"*, *"Styled with the Toss design system"* — in the brand's muted/secondary text tone so it never competes with the content.
+  2. An **HTML comment at the very top** for traceability: `<!-- design: <slug> · designs/<slug>.DESIGN.md · generated by to-html -->`.
+
+## Catalog source & adding a brand
+The 61 files come from **oh-my-design.kr/design-systems** (`omd` format; mirror of github.com/kwakseongjae/oh-my-design → `design-md/<slug>/DESIGN.md`). The repo carries ~170 brands total, so more can be pulled in.
+To add one: copy its `DESIGN.md` into `designs/` as `<slug>.DESIGN.md`, then regenerate `designs/INDEX.md` (parse each file's frontmatter: `name`, `category`, `primary_color`, `ds.name`/`ds.description`). No SKILL.md change needed unless you want a new example row in *Design Selection*.

package/skills/to-html/designs/INDEX.md

@@ -0,0 +1,74 @@
+# DESIGN.md 카탈로그 (62)
+
+`to-html` 스킬이 디자인을 고를 때 읽는 색인. 사용자가 브랜드를 명시하면 그 파일을, 아니면 콘텐츠 성격에 맞는 브랜드를 아래에서 고른다. 고른 뒤 해당 `designs/<file>`을 **전부 읽고** 그 토큰/컴포넌트/보이스/모션을 따른다.
+
+출처: https://oh-my-design.kr/design-systems · 원본 레포 github.com/kwakseongjae/oh-my-design (`omd` 포맷)
+
+| Category | Brand | File | Accent | Design system / 설명 |
+|---|---|---|---|---|
+| ai | Cohere | `cohere.DESIGN.md` | #39594d | **Cohere Newsroom** — Cohere's press kit with logos, symbols, and media resources. |
+| ai | ElevenLabs | `elevenlabs.DESIGN.md` | #000000 | **ElevenLabs Brand** — ElevenLabs brand guidelines covering logo, symbol, and product sub-brands. |
+| ai | Mistral AI | `mistral.ai.DESIGN.md` | #ff7000 | **Mistral Brand** — Mistral AI's logo, colors, typography, and brand asset kit. |
+| ai | OpenCode AI | `opencode.ai.DESIGN.md` | #000000 | **OpenCode Brand** — OpenCode's terminal-oriented logo and brand assets. |
+| ai | Together AI | `together.ai.DESIGN.md` | #0f6fff | **Together AI Brand** — Together AI's logo, color, and typography brand guidelines. |
+| ai | Upstage | `upstage.DESIGN.md` | #d2ff95 | **Upstage Brand Resource Center** — Upstage's brand resource hub — logo / symbol assets + IP rights statement. Token spec lives only in production CSS (Geist + Espeak proprietary face… |
+| backend-devops | ClickHouse | `clickhouse.DESIGN.md` | #fff100 | **ClickHouse Design** — ClickHouse brand hub plus the Click UI design system and component library. |
+| backend-devops | Hashicorp | `hashicorp.DESIGN.md` | #000000 | **Helios** — HashiCorp's design system documenting components and foundations. |
+| backend-devops | Mongodb | `mongodb.DESIGN.md` | #00ed64 | **LeafyGreen** — MongoDB's open-source design system with an extensive React component library. |
+| backend-devops | NHN Cloud | `nhncloud.DESIGN.md` | #125DE6 | **TOAST UI** — NHN's official open-source component library (TUI Grid/Editor/Calendar/Chart/Image-Editor), MIT-licensed under the nhn GitHub org and documented at… |
+| backend-devops | PostHog | `posthog.DESIGN.md` | #1d4aff | **PostHog Brand Assets** — PostHog's public handbook brand, logo, and illustration guidelines. |
+| backend-devops | Sanity | `sanity.DESIGN.md` | #f03e2f | **Sanity UI** — Sanity's accessible React toolkit for building apps with design tokens. |
+| backend-devops | Supabase | `supabase.DESIGN.md` | #3ecf8e | **Supabase Brand Assets** — Supabase's brand guidelines with logos and integration button specs. |
+| consumer-tech | Airbnb | `airbnb.DESIGN.md` | #ff5a5f | **Airbnb Brand Hub** — Airbnb's brand guidelines hub with logo, color, and visual identity rules. |
+| consumer-tech | Apple | `apple.DESIGN.md` | #000000 | **Human Interface Guidelines** — Apple's official design guidelines for iOS, macOS, watchOS, and visionOS. |
+| consumer-tech | Gogolook | `gogolook.DESIGN.md` | #0CD25F | **Whoscall Brand Guidelines** — Whoscall's official brand page — logo, the documented brand green #0CD25F, and usage guidelines. |
+| consumer-tech | IBM | `ibm.DESIGN.md` | #0f62fe | **Carbon** — IBM's open-source design system with React, Angular, Vue, and Web Components. |
+| consumer-tech | Karrot | `karrot.DESIGN.md` | #ff7e36 | **SEED Design** — Karrot (Daangn)'s open-source design system for marketplace apps. |
+| consumer-tech | LINE | `line.DESIGN.md` | #06c755 | **LINE Design System** — LINE's shared design system for products across the LINE family. |
+| consumer-tech | Naver | `naver.DESIGN.md` | #000000 | **NAVER Brand Resource** — NAVER Corp's official brand guide — logo usage, NAVER Green #03C75A, and identity rules. |
+| consumer-tech | Pinterest | `pinterest.DESIGN.md` | #e60023 | **Gestalt** — Pinterest's open-source React component library with tokens and foundations. |
+| consumer-tech | SOCAR | `socar.DESIGN.md` | #000000 | **SOCAR Design** — SOCAR's design system hub — Space Frame, SOCAR Blue, Sandoll Gothic Neo2 + Avenir typography, and mobility-flow component patterns. |
+| consumer-tech | Spotify | `spotify.DESIGN.md` | #1ed760 | **Encore** — Spotify's dark, content-first music UI — near-black surfaces, a singular Spotify Green accent, pill/circle geometry, and the Circular/CircularSp ty… |
+| consumer-tech | Uber | `uber.DESIGN.md` | #000000 | **Base Web** — Uber's React implementation of Base — a living component system. |
+| consumer-tech | Yanolja | `yanolja.DESIGN.md` | #000000 | **Yanolja Brand Center** — Yanolja's official brand center — visual identity inspired by the Multiverse of Dreams. |
+| consumer-tech | 강남언니 | `gangnamunni.DESIGN.md` | #d54300 | **Gangnamunni Blog** — Healience design team blog — the Cell + Welchis two-system architecture behind Gangnamunni's medical-platform UI. |
+| consumer-tech | 여기어때 | `yeogiotte.DESIGN.md` | #000000 | **여기어때 Design Library** — 여기어때 디자인 라이브러리 — A Visual Language for Travel. Foundations, components, and tokens. |
+| design-tools | Airtable | `airtable.DESIGN.md` | #fcb400 | **Airtable Trademark Guidelines** — Airtable's trademark usage and brand guidelines. |
+| design-tools | Clay | `clay.DESIGN.md` | #ffd23f | **Clay Newsroom** — Clay's official press kit and co-branding guidelines. |
+| design-tools | Figma | `figma.DESIGN.md` | #a259ff | **Figma Brand Guidelines** — Figma's official trademark and brand usage guidelines with logo downloads. |
+| design-tools | Framer | `framer.DESIGN.md` | #0055ff | **Framer Brand Guidelines** — Framer's brand and trademark guidelines with logo rules and color palette. |
+| design-tools | Miro | `miro.DESIGN.md` | #ffd02f | **Mirotone** — Miro's CSS component library for apps built on the Miro platform. |
+| developer-tools | Cursor | `cursor.DESIGN.md` | #000000 | **Cursor Brand** — Cursor's brand guidelines with logos, icons, and naming conventions. |
+| developer-tools | Expo | `expo.DESIGN.md` | #000020 | **Expo Brand** — Expo logo/wordmark trademark and usage guidelines. |
+| developer-tools | Raycast | `raycast.DESIGN.md` | #ff6363 | **Raycast Brand** — Raycast's brand guidelines with colors, logos, and asset kit. |
+| developer-tools | Sendbird | `sendbird.DESIGN.md` | #742DDD | **Sendbird UIKit** — Sendbird's official chat UIKit — a documented, token-driven conversation-UI system (React, iOS, Android, React Native) with named color sets, messa… |
+| developer-tools | Superhuman | `superhuman.DESIGN.md` | #5840ff | **Superhuman Media Assets** — Superhuman's press and brand asset kit. |
+| developer-tools | velog | `velog.DESIGN.md` | #12B886 | **velog (open source)** — velog's production frontend is fully open-source (MIT); its design tokens live in src/lib/styles (themes.ts + palette.ts), built on the Open Color … |
+| developer-tools | Vercel | `vercel.DESIGN.md` | #000000 | **Geist** — Vercel's design system with 50+ components, foundations, and brand resources. |
+| ecommerce | Coupang | `coupang.DESIGN.md` | #000000 | **Coupang Media Assets** — Coupang's official media-asset brand guidelines — logo usage, sizing, and attribution rules. |
+| ecommerce | Gmarket | `gmarket.DESIGN.md` | #ffd200 | **Gmarket Sans** — Gmarket's SIL OFL brand typeface — 3 weights, TTF/OTF, 11,172 KR glyphs. First-party font artifact from a 25-year-old open marketplace; backing 247… |
+| ecommerce | ZIGZAG | `zigzag.DESIGN.md` | #fa6ee3 | **ZIGZAG Tech / Brunch** — Kakaostyle / ZIGZAG's brand & design articles — the ZDS (ZIGZAG Design System) rearchitecture and the 2021 cool-pink rebrand. |
+| education | Hahow | `hahow.DESIGN.md` | #00CCB4 | **hahow-design** — Hahow's open-source design-system theme — Primary/Secondary token scales (Primary 500 #00ccb4). |
+| fintech | Alipay | `alipay.DESIGN.md` | #1677FF | **Ant Design** — The open-source enterprise design system born inside Ant Group (Alipay's parent), now the most influential Chinese design language and one of the m… |
+| fintech | Banksalad | `banksalad.DESIGN.md` | #04c584 | **Banksalad GitHub** — Banksalad's public GitHub org including styleguide repos and BPL (Banksalad Product Library) reference material. |
+| fintech | Coinone | `coinone.DESIGN.md` | #006BD6 | **Coinone Brand Guideline** — Official BI/brand guideline (v4.0) — Coinone Blue color system, signature logo lockups, clear-space rules. |
+| fintech | Hyundai Card | `hyundaicard.DESIGN.md` | #000000 | **Hyundai Card Design Library** — Hyundai Card's official Design Library — the brand's design philosophy, the proprietary Youandi typeface, and visual identity. |
+| fintech | KakaoBank | `kakaobank.DESIGN.md` | #000000 | **KakaoBank Brand Resource** — KakaoBank Brand Identity Guidelines V2.0 — logo system, KakaoBank Yellow #FFE300, downloadable CI assets. |
+| fintech | KakaoPay | `kakaopay.DESIGN.md` | #ffeb00 | **KakaoPay Story** — KakaoPay's design narrative blog — 3 pillars (Color · Icon · Type), the 3:1 contrast accessibility policy, and the KPDS internal design system cont… |
+| fintech | Money Forward | `money-forward.DESIGN.md` | #3B7DE9 | **Money Forward Cloud UI** — Money Forward's open-source React component library and theme tokens for the Money Forward Cloud business suite — buttons, forms, and a typed style… |
+| fintech | Toss | `toss.DESIGN.md` | #0064ff | **TDS** — Toss's mobile design system — 40+ components, tokens, and hooks. |
+| fintech | Wise | `wise.DESIGN.md` | #9fe870 | **Wise Design** — Wise's design system covering foundations, components, patterns, and tone of voice. |
+| government | KRDS | `krds.DESIGN.md` | #000000 | **KRDS — Korea Republic Design System** — 행정안전부 주관 범정부 통합 디자인 시스템. Government Blue #256EF4, Pretendard GOV, WCAG/KWCAG 2.2 a11y-first tokens and components. |
+| productivity | freee | `freee.DESIGN.md` | #005bac | **Vibes** — freee's open-source design system with accessibility-focused components. |
+| productivity | Kdan Mobile | `kdan.DESIGN.md` | #00DC87 | **kdan-ui** — Kdan's open-source UI token library (kdanGreen brand token + neutral scale + semantic colors). |
+| productivity | Linear | `linear.app.DESIGN.md` | #5e6ad2 | **Linear Brand** — Linear's brand guidelines with wordmark, logomark, and color specifications. |
+| productivity | Remember | `remember.DESIGN.md` | #000000 | **Remember UI** — Remember (drama&company) UI library — public Storybook deploy with components for the business-card / B2B networking product. |
+| productivity | Resend | `resend.DESIGN.md` | #000000 | **Resend Brand** — Resend's brand guidelines with wordmark, icons, and naming rules. |
+| productivity | Wanted | `wanted.DESIGN.md` | #0066ff | **Wanted Montage** — Wanted's Montage design system docs — components, foundations, Wanted Sans, and the brandcenter resource hub. |
+| productivity | Zapier | `zapier.DESIGN.md` | #ff4f00 | **Zapier Brand** — Zapier's official brand guidelines 1.0. |
+| saas | Channel Talk | `channeltalk.DESIGN.md` | #4f46e5 | **Bezier** — Channel Talk's open-source design system — Bezier (MIT). Inter + Noto KR/JP type stacks, token/component/icon packages, marketing-vs-product type c… |
+| saas | SmartHR | `smarthr.DESIGN.md` | #00C4CC | **SmartHR Design System** — SmartHR's fully public, governance-driven design system — primitive and semantic tokens, accessibility-first components, and inclusive UI guideline… |
+
+## 카테고리 분포
+
+consumer-tech(14) · fintech(9) · backend-devops(7) · developer-tools(7) · productivity(7) · ai(6) · design-tools(5) · ecommerce(3) · saas(2) · education(1) · government(1)