@su-record/vibe 2.8.51 → 2.8.53

package/skills/design-teach/rubrics/brand-personality.md

@@ -1,73 +1,73 @@
-# Brand Personality Assessment Framework
-
-Use this rubric to evaluate whether the current UI implementation reflects the stated brand personality. Score each axis 0–4.
-
----
-
-## Personality Axes
-
-### Axis 1: Formality (Casual ↔ Professional)
-
-| Score | Indicators |
-|-------|------------|
-| **4** | Typography is structured, spacing generous, copy is precise; no playful shapes or informal microcopy |
-| **3** | Mostly formal with 1–2 informal touches (e.g., friendly empty state copy) |
-| **2** | Mixed signals: formal layout but casual copy, or vice versa |
-| **1** | Predominantly informal when brand requires professional tone |
-| **0** | Completely misaligned (e.g., bounce animations and emoji icons on a financial compliance tool) |
-
-### Axis 2: Energy (Calm ↔ Bold)
-
-| Score | Indicators |
-|-------|------------|
-| **4** | Color saturation, animation speed, and typographic weight all consistent with stated energy level |
-| **3** | One outlier element (e.g., a single high-saturation call-to-action in an otherwise calm palette) |
-| **2** | Energy inconsistent across pages or components |
-| **1** | Dominant energy contradicts brand intent |
-| **0** | Extreme mismatch (e.g., muted monochrome palette on an "energetic, vibrant" brand) |
-
-### Axis 3: Warmth (Cold/Technical ↔ Warm/Human)
-
-| Score | Indicators |
-|-------|------------|
-| **4** | Color temperature, illustration style, and copy voice all aligned to warmth target |
-| **3** | Mostly aligned; one section feels tonally off |
-| **2** | Neutral — neither warm nor cold, no clear personality signal |
-| **1** | Opposite of intended (e.g., cool blues throughout a "warm and approachable" consumer product) |
-| **0** | Severely misaligned — creates user trust issues or tonal dissonance |
-
-### Axis 4: Complexity (Minimal ↔ Rich)
-
-| Score | Indicators |
-|-------|------------|
-| **4** | Visual density, number of elements per screen, and information hierarchy match stated style |
-| **3** | Correct overall density with 1–2 overcrowded or overly sparse areas |
-| **2** | Inconsistent density — some screens minimal, others overwhelming |
-| **1** | Density clearly wrong for product type (e.g., a consumer app with an enterprise-dense layout) |
-| **0** | Completely unrelated to brand intent |
-
----
-
-## Reference: Personality → Design Signal Mapping
-
-| Personality Word | Typography | Color | Spacing | Motion |
-|-----------------|------------|-------|---------|--------|
-| Professional | Geometric sans, weight contrast | Desaturated, cool neutrals | Generous, consistent | Subtle, linear ease |
-| Playful | Rounded, variable weight | High saturation, warm | Tight or expressive | Bouncy, spring ease |
-| Minimal | Single typeface, tight scale | Monochromatic or 2-color | Very generous | None or fade only |
-| Bold | High contrast, expressive display | Primary-heavy, high contrast | Dramatic gaps | Fast, snappy |
-| Warm | Humanist typeface | Warm neutrals, amber/terracotta | Comfortable | Gentle, ease-in-out |
-| Technical | Monospace or geometric | Low saturation, functional | Dense, structured | None or immediate |
-
----
-
-## Overall Brand Alignment Score
-
-Average the four axis scores. Thresholds:
-
-| Average | Assessment |
-|---------|------------|
-| 3.5–4.0 | Strong brand alignment — personality comes through clearly |
-| 2.5–3.4 | Adequate — personality visible but inconsistent in places |
-| 1.5–2.4 | Weak — personality signals mixed or absent in key areas |
-| 0–1.4 | Misaligned — redesign brand expression before shipping |
+# Brand Personality Assessment Framework
+
+Use this rubric to evaluate whether the current UI implementation reflects the stated brand personality. Score each axis 0–4.
+
+---
+
+## Personality Axes
+
+### Axis 1: Formality (Casual ↔ Professional)
+
+| Score | Indicators |
+|-------|------------|
+| **4** | Typography is structured, spacing generous, copy is precise; no playful shapes or informal microcopy |
+| **3** | Mostly formal with 1–2 informal touches (e.g., friendly empty state copy) |
+| **2** | Mixed signals: formal layout but casual copy, or vice versa |
+| **1** | Predominantly informal when brand requires professional tone |
+| **0** | Completely misaligned (e.g., bounce animations and emoji icons on a financial compliance tool) |
+
+### Axis 2: Energy (Calm ↔ Bold)
+
+| Score | Indicators |
+|-------|------------|
+| **4** | Color saturation, animation speed, and typographic weight all consistent with stated energy level |
+| **3** | One outlier element (e.g., a single high-saturation call-to-action in an otherwise calm palette) |
+| **2** | Energy inconsistent across pages or components |
+| **1** | Dominant energy contradicts brand intent |
+| **0** | Extreme mismatch (e.g., muted monochrome palette on an "energetic, vibrant" brand) |
+
+### Axis 3: Warmth (Cold/Technical ↔ Warm/Human)
+
+| Score | Indicators |
+|-------|------------|
+| **4** | Color temperature, illustration style, and copy voice all aligned to warmth target |
+| **3** | Mostly aligned; one section feels tonally off |
+| **2** | Neutral — neither warm nor cold, no clear personality signal |
+| **1** | Opposite of intended (e.g., cool blues throughout a "warm and approachable" consumer product) |
+| **0** | Severely misaligned — creates user trust issues or tonal dissonance |
+
+### Axis 4: Complexity (Minimal ↔ Rich)
+
+| Score | Indicators |
+|-------|------------|
+| **4** | Visual density, number of elements per screen, and information hierarchy match stated style |
+| **3** | Correct overall density with 1–2 overcrowded or overly sparse areas |
+| **2** | Inconsistent density — some screens minimal, others overwhelming |
+| **1** | Density clearly wrong for product type (e.g., a consumer app with an enterprise-dense layout) |
+| **0** | Completely unrelated to brand intent |
+
+---
+
+## Reference: Personality → Design Signal Mapping
+
+| Personality Word | Typography | Color | Spacing | Motion |
+|-----------------|------------|-------|---------|--------|
+| Professional | Geometric sans, weight contrast | Desaturated, cool neutrals | Generous, consistent | Subtle, linear ease |
+| Playful | Rounded, variable weight | High saturation, warm | Tight or expressive | Bouncy, spring ease |
+| Minimal | Single typeface, tight scale | Monochromatic or 2-color | Very generous | None or fade only |
+| Bold | High contrast, expressive display | Primary-heavy, high contrast | Dramatic gaps | Fast, snappy |
+| Warm | Humanist typeface | Warm neutrals, amber/terracotta | Comfortable | Gentle, ease-in-out |
+| Technical | Monospace or geometric | Low saturation, functional | Dense, structured | None or immediate |
+
+---
+
+## Overall Brand Alignment Score
+
+Average the four axis scores. Thresholds:
+
+| Average | Assessment |
+|---------|------------|
+| 3.5–4.0 | Strong brand alignment — personality comes through clearly |
+| 2.5–3.4 | Adequate — personality visible but inconsistent in places |
+| 1.5–2.4 | Weak — personality signals mixed or absent in key areas |
+| 0–1.4 | Misaligned — redesign brand expression before shipping |

package/skills/design-teach/templates/design-context.json

@@ -1,36 +1,36 @@
-{
-  "$schema": "design-context-v1",
-  "createdAt": "{{ISO_DATE}}",
-  "updatedAt": "{{ISO_DATE}}",
-  "audience": {
-    "primary": "B2B SaaS — product managers and engineers at mid-size tech companies",
-    "context": "desktop",
-    "expertise": "intermediate"
-  },
-  "brand": {
-    "personality": ["professional", "clean", "trustworthy", "efficient"],
-    "tone": "professional",
-    "existingAssets": ".claude/vibe/brand/brand-guide.pdf"
-  },
-  "aesthetic": {
-    "style": "minimal",
-    "colorMood": "cool",
-    "typographyMood": "modern",
-    "references": [
-      "https://linear.app",
-      "https://vercel.com"
-    ]
-  },
-  "constraints": {
-    "accessibility": "AA",
-    "performance": "core-web-vitals",
-    "browsers": ["chrome", "safari", "firefox", "edge"],
-    "devices": ["desktop", "tablet"]
-  },
-  "detectedStack": {
-    "framework": "Next.js 15",
-    "componentLibrary": "shadcn/ui",
-    "styling": "Tailwind CSS",
-    "fonts": ["Inter"]
-  }
-}
+{
+  "$schema": "design-context-v1",
+  "createdAt": "{{ISO_DATE}}",
+  "updatedAt": "{{ISO_DATE}}",
+  "audience": {
+    "primary": "B2B SaaS — product managers and engineers at mid-size tech companies",
+    "context": "desktop",
+    "expertise": "intermediate"
+  },
+  "brand": {
+    "personality": ["professional", "clean", "trustworthy", "efficient"],
+    "tone": "professional",
+    "existingAssets": ".claude/vibe/brand/brand-guide.pdf"
+  },
+  "aesthetic": {
+    "style": "minimal",
+    "colorMood": "cool",
+    "typographyMood": "modern",
+    "references": [
+      "https://linear.app",
+      "https://vercel.com"
+    ]
+  },
+  "constraints": {
+    "accessibility": "AA",
+    "performance": "core-web-vitals",
+    "browsers": ["chrome", "safari", "firefox", "edge"],
+    "devices": ["desktop", "tablet"]
+  },
+  "detectedStack": {
+    "framework": "Next.js 15",
+    "componentLibrary": "shadcn/ui",
+    "styling": "Tailwind CSS",
+    "fonts": ["Inter"]
+  }
+}

package/skills/devlog/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: devlog
+tier: standard
+description: "Auto-generate devlog posts from git commit history. Triggers every N commits, writes markdown to configured target repo."
+triggers: [devlog, 개발일지, dev log, devlog 작성, 개발일지 작성]
+priority: 60
+---
+# Devlog Auto-Generator
+
+Git 커밋 히스토리를 분석하여 개발일지를 자동 생성하고, 설정된 블로그 레포에 포스트로 저장합니다.
+
+## Config
+
+`.claude/vibe/config.json`의 `devlog` 섹션:
+
+```json
+{
+  "devlog": {
+    "enabled": true,
+    "targetRepo": "/absolute/path/to/blog-repo",
+    "targetDir": "posts",
+    "prefix": "devlog",
+    "interval": 10,
+    "autoPush": false,
+    "lang": "ko",
+    "author": "Su",
+    "category": "dev-log",
+    "tags": []
+  }
+}
+```
+
+| Key | Required | Default | Description |
+|-----|----------|---------|-------------|
+| `enabled` | Y | `false` | 활성화 여부 |
+| `targetRepo` | Y | — | 블로그 레포 절대 경로 |
+| `targetDir` | N | `"posts"` | 포스트 저장 디렉토리 |
+| `prefix` | N | `"devlog"` | 파일명 프리픽스 (`{prefix}-{NNNN}.md`) |
+| `interval` | N | `10` | 몇 커밋마다 생성할지 |
+| `autoPush` | N | `false` | targetRepo에 자동 commit+push |
+| `lang` | N | `"ko"` | 작성 언어 |
+| `author` | N | git user.name | 작성자 |
+| `category` | N | `"dev-log"` | frontmatter category |
+| `tags` | N | `[]` | 기본 태그 (프로젝트명 등 자동 추가) |
+
+## Trigger Modes
+
+### 1. Auto (post-commit hook)
+
+`devlog-gen.js` hook이 매 커밋마다 카운터를 확인하고, `interval`에 도달하면 `llm-orchestrate.js`를 통해 개발일지를 생성합니다.
+
+### 2. Manual
+
+사용자가 직접 `/devlog` 또는 `개발일지 작성` 키워드로 트리거. 마지막 개발일지 이후의 커밋을 모아 즉시 생성합니다.
+
+## Generation Process
+
+### Step 1: Collect Commits
+
+마지막 개발일지의 날짜 이후 커밋을 수집합니다:
+
+```bash
+# 마지막 devlog 파일에서 날짜 추출
+# targetRepo/targetDir/{prefix}-NNNN.md 의 frontmatter date
+git log --oneline --after="{last_date}" --reverse
+```
+
+### Step 2: Analyze & Group
+
+- 버전 범프 커밋 식별 (X.Y.Z 패턴)
+- feat/fix/refactor/docs 분류
+- 주요 커밋 선별 (의미 있는 변경)
+
+### Step 3: Generate Markdown
+
+다음 frontmatter 포맷으로 생성:
+
+```markdown
+---
+title: "{project_name} 개발일지 #{next_number} - {summary_title} ({interval}개 커밋)"
+date: "{today}"
+category: "{category}"
+description: "{one_line_description}"
+tags: [{project_tags}, {auto_detected_tags}]
+author: "{author}"
+lang: "{lang}"
+---
+
+# {title}
+
+**작업 기간**: {start_date} ~ {end_date}
+
+## 이번 기간 작업 내용
+
+### {theme} ({interval}개 커밋)
+
+{overview_paragraph}
+
+| 커밋 | 내용 |
+|------|------|
+| `{meaningful_commit_message}` | **{highlight}** |
+...
+
+## 작업 하이라이트
+
+{2-3 highlights with code blocks or diagrams}
+
+## 개발 현황
+
+- **버전**: {start_version} → {end_version}
+- **핵심**: {key_changes}
+
+---
+
+**다음 개발일지**: {prefix}-{next+1} (다음 {interval}개 커밋 후)
+```
+
+### Step 4: Write File
+
+```
+{targetRepo}/{targetDir}/{prefix}-{NNNN}.md
+```
+
+번호는 기존 파일에서 마지막 번호 + 1로 자동 결정.
+
+### Step 5: (Optional) Auto Push
+
+`autoPush: true`이면:
+
+```bash
+cd {targetRepo}
+git add {targetDir}/{prefix}-{NNNN}.md
+git commit -m "post: Add {prefix} #{NNNN}"
+git push
+```
+
+## Rules
+
+- **커밋 메시지 원문 보존** — 커밋 메시지를 그대로 인용, 임의 변경 금지
+- **버전 범프 커밋 포함** — 테이블에는 포함하되 하이라이트에서 제외
+- **하이라이트는 최대 3개** — 가장 영향력 있는 변경만 선별
+- **코드 블록 활용** — Before/After 비교, 아키텍처 다이어그램 권장
+- **숫자 강조** — 줄 수 변화(-N줄), 버전 범위, 파일 수 등

package/skills/e2e-commerce/SKILL.md

@@ -1,62 +1,62 @@
----
-name: e2e-commerce
-tier: core
-description: "E2E test scenarios for commerce checkout and payment flows. Provides ready-made Playwright test templates for cart→checkout→payment→confirmation flows, including PG sandbox testing (Toss/Stripe), error scenarios (payment failure, timeout, stock exhaustion), and idempotency verification. Use when writing E2E tests for any e-commerce feature — checkout, payment, order status, or refund flows."
-triggers: [e2e commerce, checkout test, payment test, order flow test]
-priority: 65
----
-
-# E2E Commerce Test Scenarios
-
-## Pre-check (K1)
-
-> Are you testing a checkout/payment/order flow? If testing simple CRUD or non-transactional features, standard E2E patterns suffice — this skill is not needed.
-
-## Must-Test Scenarios
-
-### P0 — Blocks Deployment
-
-| Scenario | What to Verify | Gotcha |
-|----------|---------------|--------|
-| **Happy path checkout** | Cart → Shipping → Payment → Order confirmation | Verify order status text, not just URL change |
-| **Payment failure** | Error message shown, stock released | Check stock is RELEASED after failure, not just error displayed |
-| **Duplicate payment** | Only 1 order created on double-click | `Promise.all([click(), click()])` then verify order count via API |
-| **Out of stock** | Blocks checkout with clear message | Simulate stock depletion mid-checkout via test API |
-
-### P1 — Should Pass
-
-| Scenario | What to Verify | Gotcha |
-|----------|---------------|--------|
-| **Coupon calculation** | Discount amount and total correct | Test percentage AND fixed amount coupons separately |
-| **Webhook resilience** | Order completes even with delayed webhook | Configure 5s delay, verify processing→complete transition |
-| **Cart merge on login** | Guest cart merged into user cart | User cart takes priority for duplicate items |
-| **Partial refund** | Refunded amount correct, order updated | Verify remaining amount, not just refund event |
-
-### P2 — Nice to Have
-
-| Scenario | What to Verify |
-|----------|---------------|
-| Multiple payment methods | Each method completes checkout |
-| Guest checkout | Full flow without login |
-| Order cancellation | Refund triggered, stock restored |
-
-## Test Environment Gotchas
-
-| Gotcha | Fix |
-|--------|-----|
-| Using real PG sandbox in CI | Use MSW (`setupServer`) for mock PG responses |
-| Flaky tests from timing | Use `waitForSelector`/`waitForURL`, never `sleep` |
-| Test data leaks between tests | Seed in `beforeAll`, clean in `afterAll` |
-| Hardcoded test card numbers | Document: `4000000000000002` = decline |
-
-## Related
-
-See `commerce-patterns` skill for implementation gotchas (idempotency, atomic stock, payment state machine) that these tests verify.
-
-## Done Criteria (K4)
-
-- [ ] All P0 scenarios pass in CI
-- [ ] P1 scenarios written and tracked
-- [ ] Test data seeded/cleaned per suite
-- [ ] No flaky tests (no arbitrary waits)
-- [ ] Mock PG server configured for CI
+---
+name: e2e-commerce
+tier: core
+description: "E2E test scenarios for commerce checkout and payment flows. Provides ready-made Playwright test templates for cart→checkout→payment→confirmation flows, including PG sandbox testing (Toss/Stripe), error scenarios (payment failure, timeout, stock exhaustion), and idempotency verification. Use when writing E2E tests for any e-commerce feature — checkout, payment, order status, or refund flows."
+triggers: [e2e commerce, checkout test, payment test, order flow test]
+priority: 65
+---
+
+# E2E Commerce Test Scenarios
+
+## Pre-check (K1)
+
+> Are you testing a checkout/payment/order flow? If testing simple CRUD or non-transactional features, standard E2E patterns suffice — this skill is not needed.
+
+## Must-Test Scenarios
+
+### P0 — Blocks Deployment
+
+| Scenario | What to Verify | Gotcha |
+|----------|---------------|--------|
+| **Happy path checkout** | Cart → Shipping → Payment → Order confirmation | Verify order status text, not just URL change |
+| **Payment failure** | Error message shown, stock released | Check stock is RELEASED after failure, not just error displayed |
+| **Duplicate payment** | Only 1 order created on double-click | `Promise.all([click(), click()])` then verify order count via API |
+| **Out of stock** | Blocks checkout with clear message | Simulate stock depletion mid-checkout via test API |
+
+### P1 — Should Pass
+
+| Scenario | What to Verify | Gotcha |
+|----------|---------------|--------|
+| **Coupon calculation** | Discount amount and total correct | Test percentage AND fixed amount coupons separately |
+| **Webhook resilience** | Order completes even with delayed webhook | Configure 5s delay, verify processing→complete transition |
+| **Cart merge on login** | Guest cart merged into user cart | User cart takes priority for duplicate items |
+| **Partial refund** | Refunded amount correct, order updated | Verify remaining amount, not just refund event |
+
+### P2 — Nice to Have
+
+| Scenario | What to Verify |
+|----------|---------------|
+| Multiple payment methods | Each method completes checkout |
+| Guest checkout | Full flow without login |
+| Order cancellation | Refund triggered, stock restored |
+
+## Test Environment Gotchas
+
+| Gotcha | Fix |
+|--------|-----|
+| Using real PG sandbox in CI | Use MSW (`setupServer`) for mock PG responses |
+| Flaky tests from timing | Use `waitForSelector`/`waitForURL`, never `sleep` |
+| Test data leaks between tests | Seed in `beforeAll`, clean in `afterAll` |
+| Hardcoded test card numbers | Document: `4000000000000002` = decline |
+
+## Related
+
+See `commerce-patterns` skill for implementation gotchas (idempotency, atomic stock, payment state machine) that these tests verify.
+
+## Done Criteria (K4)
+
+- [ ] All P0 scenarios pass in CI
+- [ ] P1 scenarios written and tracked
+- [ ] Test data seeded/cleaned per suite
+- [ ] No flaky tests (no arbitrary waits)
+- [ ] Mock PG server configured for CI