@su-record/vibe 2.9.32 → 2.9.33

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

@@ -1,143 +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
-
-Analyzes git commit history to automatically generate development logs and saves them as posts to the configured blog repository.
-
-## Config
-
-`devlog` section in `.claude/vibe/config.json`:
-
-```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` | Whether to enable |
-| `targetRepo` | Y | — | Absolute path to the blog repository |
-| `targetDir` | N | `"posts"` | Directory to save posts |
-| `prefix` | N | `"devlog"` | Filename prefix (`{prefix}-{NNNN}.md`) |
-| `interval` | N | `10` | How many commits trigger a generation |
-| `autoPush` | N | `false` | Auto commit+push to targetRepo |
-| `lang` | N | `"ko"` | Writing language |
-| `author` | N | git user.name | Author name |
-| `category` | N | `"dev-log"` | frontmatter category |
-| `tags` | N | `[]` | Default tags (project name etc. auto-added) |
-
-## Trigger Modes
-
-### 1. Auto (post-commit hook)
-
-The `devlog-gen.js` hook checks the counter on every commit, and when it reaches `interval`, generates a devlog via `llm-orchestrate.js`.
-
-### 2. Manual
-
-User manually triggers via `/devlog` or the `개발일지 작성` keyword. Collects commits since the last devlog and generates immediately.
-
-## Generation Process
-
-### Step 1: Collect Commits
-
-Collects commits after the date of the last devlog:
-
-```bash
-# Extract date from last devlog file
-# frontmatter date of targetRepo/targetDir/{prefix}-NNNN.md
-git log --oneline --after="{last_date}" --reverse
-```
-
-### Step 2: Analyze & Group
-
-- Identify version bump commits (X.Y.Z pattern)
-- Classify by feat/fix/refactor/docs
-- Select notable commits (meaningful changes)
-
-### Step 3: Generate Markdown
-
-Generated with the following frontmatter format:
-
-```markdown
----
-title: "{project_name} Devlog #{next_number} - {summary_title} ({interval} commits)"
-date: "{today}"
-category: "{category}"
-description: "{one_line_description}"
-tags: [{project_tags}, {auto_detected_tags}]
-author: "{author}"
-lang: "{lang}"
----
-
-# {title}
-
-**Work period**: {start_date} ~ {end_date}
-
-## Work done this period
-
-### {theme} ({interval} commits)
-
-{overview_paragraph}
-
-| Commit | Description |
-|--------|-------------|
-| `{meaningful_commit_message}` | **{highlight}** |
-...
-
-## Work highlights
-
-{2-3 highlights with code blocks or diagrams}
-
-## Development status
-
-- **Version**: {start_version} → {end_version}
-- **Key changes**: {key_changes}
-
----
-
-**Next devlog**: {prefix}-{next+1} (after next {interval} commits)
-```
-
-### Step 4: Write File
-
-```
-{targetRepo}/{targetDir}/{prefix}-{NNNN}.md
-```
-
-The number is automatically determined as the last existing file number + 1.
-
-### Step 5: (Optional) Auto Push
-
-If `autoPush: true`:
-
-```bash
-cd {targetRepo}
-git add {targetDir}/{prefix}-{NNNN}.md
-git commit -m "post: Add {prefix} #{NNNN}"
-git push
-```
-
-## Rules
-
-- **Preserve original commit messages** — Quote commit messages verbatim, no arbitrary changes
-- **Include version bump commits** — Include in the table but exclude from highlights
-- **Maximum 3 highlights** — Select only the most impactful changes
-- **Use code blocks** — Before/After comparisons and architecture diagrams are recommended
-- **Emphasize numbers** — Line count changes (-N lines), version ranges, file counts, etc.
+---
+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
+
+Analyzes git commit history to automatically generate development logs and saves them as posts to the configured blog repository.
+
+## Config
+
+`devlog` section in `.claude/vibe/config.json`:
+
+```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` | Whether to enable |
+| `targetRepo` | Y | — | Absolute path to the blog repository |
+| `targetDir` | N | `"posts"` | Directory to save posts |
+| `prefix` | N | `"devlog"` | Filename prefix (`{prefix}-{NNNN}.md`) |
+| `interval` | N | `10` | How many commits trigger a generation |
+| `autoPush` | N | `false` | Auto commit+push to targetRepo |
+| `lang` | N | `"ko"` | Writing language |
+| `author` | N | git user.name | Author name |
+| `category` | N | `"dev-log"` | frontmatter category |
+| `tags` | N | `[]` | Default tags (project name etc. auto-added) |
+
+## Trigger Modes
+
+### 1. Auto (post-commit hook)
+
+The `devlog-gen.js` hook checks the counter on every commit, and when it reaches `interval`, generates a devlog via `llm-orchestrate.js`.
+
+### 2. Manual
+
+User manually triggers via `/devlog` or the `개발일지 작성` keyword. Collects commits since the last devlog and generates immediately.
+
+## Generation Process
+
+### Step 1: Collect Commits
+
+Collects commits after the date of the last devlog:
+
+```bash
+# Extract date from last devlog file
+# frontmatter date of targetRepo/targetDir/{prefix}-NNNN.md
+git log --oneline --after="{last_date}" --reverse
+```
+
+### Step 2: Analyze & Group
+
+- Identify version bump commits (X.Y.Z pattern)
+- Classify by feat/fix/refactor/docs
+- Select notable commits (meaningful changes)
+
+### Step 3: Generate Markdown
+
+Generated with the following frontmatter format:
+
+```markdown
+---
+title: "{project_name} Devlog #{next_number} - {summary_title} ({interval} commits)"
+date: "{today}"
+category: "{category}"
+description: "{one_line_description}"
+tags: [{project_tags}, {auto_detected_tags}]
+author: "{author}"
+lang: "{lang}"
+---
+
+# {title}
+
+**Work period**: {start_date} ~ {end_date}
+
+## Work done this period
+
+### {theme} ({interval} commits)
+
+{overview_paragraph}
+
+| Commit | Description |
+|--------|-------------|
+| `{meaningful_commit_message}` | **{highlight}** |
+...
+
+## Work highlights
+
+{2-3 highlights with code blocks or diagrams}
+
+## Development status
+
+- **Version**: {start_version} → {end_version}
+- **Key changes**: {key_changes}
+
+---
+
+**Next devlog**: {prefix}-{next+1} (after next {interval} commits)
+```
+
+### Step 4: Write File
+
+```
+{targetRepo}/{targetDir}/{prefix}-{NNNN}.md
+```
+
+The number is automatically determined as the last existing file number + 1.
+
+### Step 5: (Optional) Auto Push
+
+If `autoPush: true`:
+
+```bash
+cd {targetRepo}
+git add {targetDir}/{prefix}-{NNNN}.md
+git commit -m "post: Add {prefix} #{NNNN}"
+git push
+```
+
+## Rules
+
+- **Preserve original commit messages** — Quote commit messages verbatim, no arbitrary changes
+- **Include version bump commits** — Include in the table but exclude from highlights
+- **Maximum 3 highlights** — Select only the most impactful changes
+- **Use code blocks** — Before/After comparisons and architecture diagrams are recommended
+- **Emphasize numbers** — Line count changes (-N lines), version ranges, file counts, etc.

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