main

.claude/settings.json

@@ -1,35 +1,10 @@
 {
-  "hooks": {
-    "PostToolUse": [
-      {
-        "matcher": "Edit|MultiEdit|Write",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "pnpm format"
-          },
-          {
-            "type": "command",
-            "command": "pnpm test"
-          },
-          {
-            "type": "command",
-            "command": "pnpm type-check"
-          }
-        ]
-      }
-    ]
-  },
   "env": {
     "MAX_MCP_OUTPUT_TOKENS": "100000"
   },
-  "statusLine": {
-    "type": "command",
-    "command": "input=$(cat); model=$(echo \"$input\" | jq -r '.model.display_name // empty'); ctx=$(echo \"$input\" | jq -r '.context_window.used_percentage // empty'); five=$(echo \"$input\" | jq -r '.rate_limits.five_hour.used_percentage // empty'); reset5=$(echo \"$input\" | jq -r '.rate_limits.five_hour.resets_at // empty'); week=$(echo \"$input\" | jq -r '.rate_limits.seven_day.used_percentage // empty'); reset7=$(echo \"$input\" | jq -r '.rate_limits.seven_day.resets_at // empty'); [ -n \"$model\" ] && out=\"$model\" || out=\"model: -\"; [ -n \"$ctx\" ] && out=\"$out | context: $(printf '%.0f' \"$ctx\")%\" || out=\"$out | context: -\"; if [ -n \"$five\" ]; then out=\"$out | 5h: $(printf '%.0f' \"$five\")%\"; if [ -n \"$reset5\" ]; then reset_time=$(date -r \"$(printf '%.0f' \"$reset5\")\" '+%H:%M'); out=\"$out (reset: $reset_time)\"; fi; else out=\"$out | 5h: -\"; fi; if [ -n \"$week\" ]; then out=\"$out | 7d: $(printf '%.0f' \"$week\")%\"; if [ -n \"$reset7\" ]; then reset_date=$(LANG=C date -r \"$(printf '%.0f' \"$reset7\")\" '+%m/%d %a %H:%M'); out=\"$out (reset: $reset_date)\"; fi; else out=\"$out | 7d: -\"; fi; echo \"$out\""
-  },
- "permissions": {
+  "permissions": {
     "allow": [
-    "Bash(git:*)",
+      "Bash(git:*)",
       "Bash(pnpm:*)",
       "Bash(npx:*)",
       "Bash(node:*)",
@@ -88,5 +63,33 @@
     ],
     "deny": [],
     "ask": []
+  },
+  "hooks": {
+    "PostToolUse": [
+      {
+        "matcher": "Edit|MultiEdit|Write",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "pnpm format"
+          },
+          {
+            "type": "command",
+            "command": "pnpm test"
+          },
+          {
+            "type": "command",
+            "command": "pnpm type-check"
+          }
+        ]
+      }
+    ]
+  },
+  "statusLine": {
+    "type": "command",
+    "command": "input=$(cat); model=$(echo \"$input\" | jq -r '.model.display_name // empty'); ctx=$(echo \"$input\" | jq -r '.context_window.used_percentage // empty'); five=$(echo \"$input\" | jq -r '.rate_limits.five_hour.used_percentage // empty'); reset5=$(echo \"$input\" | jq -r '.rate_limits.five_hour.resets_at // empty'); week=$(echo \"$input\" | jq -r '.rate_limits.seven_day.used_percentage // empty'); reset7=$(echo \"$input\" | jq -r '.rate_limits.seven_day.resets_at // empty'); [ -n \"$model\" ] && out=\"$model\" || out=\"model: -\"; [ -n \"$ctx\" ] && out=\"$out | context: $(printf '%.0f' \"$ctx\")%\" || out=\"$out | context: -\"; if [ -n \"$five\" ]; then out=\"$out | 5h: $(printf '%.0f' \"$five\")%\"; if [ -n \"$reset5\" ]; then reset_time=$(date -r \"$(printf '%.0f' \"$reset5\")\" '+%H:%M'); out=\"$out (reset: $reset_time)\"; fi; else out=\"$out | 5h: -\"; fi; if [ -n \"$week\" ]; then out=\"$out | 7d: $(printf '%.0f' \"$week\")%\"; if [ -n \"$reset7\" ]; then reset_date=$(LANG=C date -r \"$(printf '%.0f' \"$reset7\")\" '+%m/%d %a %H:%M'); out=\"$out (reset: $reset_date)\"; fi; else out=\"$out | 7d: -\"; fi; echo \"$out\""
+  },
+  "enabledPlugins": {
+    "frontend-design@claude-code-plugins": true
   }
 }

.claude/skills/create-design/SKILL.md

@@ -0,0 +1,201 @@
+---
+name: create-design
+description: Create mock screen designs as Storybook stories using this project's design system (Chakra UI v3 + `src/components/ui/` wrappers). Triggers only when the user explicitly invokes `/create-design` or says "デザイン作って" / "モック作って" / "make a mock" / "design this screen". **Never auto-trigger**. Handles both new-screen proposals and existing-screen redesigns.
+---
+
+# /create-design — Storybook Mock Design Generator
+
+You are an expert designer working with the user as a manager. You produce design artifacts on their behalf — **as Storybook stories inside this project's codebase**, using its existing design system.
+
+You must embody an expert in the relevant domain: UX designer, prototyper, visual designer. Avoid generic web design tropes. Match the visual vocabulary of what already exists here.
+
+## Output contract
+
+- Output is always a `*.stories.tsx` file (plus any supporting mock files it imports).
+- **No real logic.** No Convex queries/mutations, no Router definitions, no auth wrappers, no tests. Dummy data + inline state only.
+- Use Chakra UI v3 style props. No Tailwind, no raw CSS.
+- Storybook is `@storybook/react-vite` — import `Meta`/`StoryObj` from there (not `@storybook/react`).
+- `@storybook/test` is not installed — do not use `fn()`. Pass callbacks as `() => {}`.
+
+## Workflow
+
+1. Ask clarifying questions
+2. Gather design context from the codebase
+3. Verbalize the system you'll use (junior-designer-to-manager review)
+4. Build
+5. Verify visually with Playwright MCP
+6. Short end-of-turn summary (1–2 sentences)
+
+Run file-exploration tools concurrently when possible. For any scope beyond a single screen or beyond a few hours of work, use a todo list to track progress.
+
+---
+
+### Step 1: Ask clarifying questions
+
+Asking good questions is **essential**. Bad context produces bad design. Always confirm the starting point — a design system, an existing page, a spec doc — before building.
+
+For every request, confirm at minimum:
+
+- **What is being designed**: a new screen, a redesign of an existing one, or a single section/component
+- **Target device**: PC (max content width 1024px), SP (design baseline 390px), or both
+- **Variation count**: single proposal, or 2–3 proposals to compare
+
+For **existing-screen redesigns**, go deeper. This is a conversation, not a checklist — ask in batches of 2–3 and keep iterating:
+
+- Why redesign? What concretely isn't working?
+- Who uses it now, how often, and has that changed?
+- What must survive the redesign? What should be cut?
+- Is the scope visual only, information architecture, or full rethink?
+- Can data structure and navigation change?
+- Any reference products or inspirations?
+- What does "done" look like for them?
+
+Skip questions only for obvious tweaks or when the user has already provided everything.
+
+### Step 2: Gather design context
+
+**Mocking a full product from scratch is a last resort.** Before writing any component, read what already exists. Do this in parallel:
+
+- `src/components/ui/` — generic UI wrappers (Button, FormCard, BottomSheet, Empty, Title, Select…)
+- `src/components/templates/` — layout shells (BottomMenu, SideMenu, ContentWrapper)
+- `src/components/features/` — domain UI (always read this when redesigning)
+- `src/components/pages/` — existing page-level compositions
+- `design/designIndex.md` — index of `.pen` design files
+- `doc/features/<relevant>.md` — feature specs
+
+While reading, observe and think out loud about the **visual vocabulary**: color palette, spacing rhythm, corner radii, shadow depth, density, hover/click states, copy tone, iconography. You will match it unless the user explicitly asks to break from it.
+
+**Prefer code over screenshots.** When redesigning an existing screen, read the actual source of the current page/feature — not just a screenshot of it. Code tells you exact tokens, spacing, and structural choices; screenshots only tell you appearance. Use screenshots as supplements when the user provides them, not as a substitute for reading the source.
+
+If the context you need isn't here, ask the user to point you at it (a screenshot, a `.pen` file, a reference product, a URL). Don't invent from thin air. Be proactive — list directories, grep for relevant names, open adjacent files.
+
+### Step 3: Verbalize the system
+
+Before writing components, state — like a junior designer briefing their manager — in a few short lines:
+
+- The visual system you'll use (one line: e.g. "calm neutral surface, single teal accent, generous card radii")
+- Layout approach for the main sections (3–5 bullets)
+- Which existing components you'll reuse
+- What you'll placeholder vs. render fully
+- Any intentional breaks from existing vocabulary, and why
+
+If the direction is obvious, keep moving. If there's a real fork, pause and confirm.
+
+### Step 4: Build
+
+**Output location**:
+
+- New screen → default `src/components/mocks/<FeatureName>/index.stories.tsx`. Confirm placement with the user once; match whatever the project has already established for mocks.
+- Redesign → place alongside the existing story as `<Name>.v2.stories.tsx` (or similar), so old and new coexist for comparison.
+
+**File organization** — for multi-variant screen mocks, this layout has worked well in this repo:
+
+```
+src/components/mocks/<FeatureName>/
+  index.stories.tsx   # meta + imports + exports only (thin)
+  VariantA.tsx        # one variant per file
+  VariantB.tsx
+  mockData.ts         # shared dummy data
+```
+
+Keep each variant file under ~300 lines — split nested components out if you're above that.
+
+**Show early, iterate.** Don't disappear for an hour and return with a finished mock. As soon as the skeleton loads cleanly in Storybook, tell the user it's viewable — even if sections are placeholder boxes. Take one round of reaction, then fill in. Iterative feedback beats one big reveal.
+
+**Implementation rules**:
+
+- Use Chakra UI v3 style props (`<Box bg="teal.50" borderRadius="2xl" px={5}>`). Recipes, compound components, and `ContentWrapper` are your friends.
+- Handlers are `() => {}`. State that needs to demo interaction uses `useState`.
+- Put mock data at the top of the file or in a sibling `mockData.ts`. Keep it realistic — real-looking names, times, counts — not `"foo"`/`"bar"`.
+- **Placeholders beat bad attempts**. If you don't have an icon, illustration, logo, or chart, a labeled `<Box bg="gray.200" />` or a plain text label is always better than a hand-drawn SVG or AI-guessed rendering.
+- For full-screen mocks: one variant per source file, all re-exported as `Variant_X` stories from the thin `index.stories.tsx` (see File organization above).
+- For small UI components: collapse multiple states into a single story with a `<Variants />` grid — cheaper on VRT capture count.
+
+**Project-specific rules (non-negotiable)**:
+
+- MVP screens do not include `SideMenu`. Prefer SP-first; use `BottomMenu` if navigation is needed.
+- Avoid border duplication. A header bottom-border stacked against a content card border reads as a fat double line.
+- **Status color palette**: `teal` = brand, `orange` = needs attention, `green` = achievement, `gray` = completed/disabled, `red` = destructive. `yellow` is almost never used.
+- Inside modal/BottomSheet, `Select` must be `usePortal={false}` or the dropdown renders behind the surface. If `BottomSheet`'s `overflowY="auto"` clips a dropdown, pass `overflowY="visible"`.
+- Never use `new Date()` + `toISOString()` for date strings — TZ drift. Even in mocks, use `dayjs` or fixed `"YYYY-MM-DD"` literals.
+- Complex UI (shift tables, grids with many interactive cells) — render as a **placeholder block**, not a pixel-perfect rendition. The feedback loop on those is better in code than in mocks.
+
+**Copy tone** (from `CLAUDE.md` text guidelines):
+
+- Titles/subtitles: no commas or periods; mid-register tone (not `です/ます` but not slangy either); 体言止め fine; prefer hiragana density; short.
+- Lead with benefit, not pain. No humble-brag ("すごいでしょ?"). No condescension ("小さなお店" → "少人数のお店").
+- One line, multiple jobs (who it's for + what it does).
+
+### Step 5: Verify with Playwright MCP
+
+- Make sure Storybook is running (`pnpm storybook`, port 6006). If not, ask the user to start it.
+- Story URL format (iframe, no Storybook chrome): `http://localhost:6006/iframe.html?id=<kebab-title>--<kebab-story>&viewMode=story`. Example: `id=mocks-dashboard--variant-a`.
+- `playwright_navigate` to the story URL, then `playwright_screenshot`.
+- Capture at SP (390×844) and PC (1280×800) at minimum. For responsive breakpoint work, add a mid width (768×1024).
+- Check: layout breaks, overflow, border duplication, text wrapping, tap targets ≥ 44px, vertical rhythm, status color correctness. Match against the intent declared in Step 3.
+- Fix and re-capture. Don't report done until clean.
+
+### Step 6: End-of-turn summary
+
+1–2 sentences: what was built + the single most useful next action (pick a variant, tune copy, start wiring, etc.). No recap, no self-congratulation.
+
+---
+
+## Design principles
+
+### Do
+
+- **Match existing visual vocabulary**: colors, radii, shadow, density, copy tone. Observe before you write. Think out loud about what you see.
+- **Use colors from the existing palette.** If you genuinely need a new color, compute it with `oklch()` so it harmonizes — don't invent hex from scratch.
+- **Placeholders are a feature**, not a failure. A `gray.200` box labeled "shift grid placeholder" is a clearer design communication than a half-faked table.
+- **Declare a system up front.** Pick one approach for section headers, one type scale, 1–2 background colors max. Commit to it across the screen.
+- **Use scale deliberately.** SP tap targets ≥ 44px. Body text ≥ 14px. Headings big enough to do the work.
+- **Use CSS properly.** `text-wrap: pretty`, CSS Grid, `aspect-ratio`, `min()/max()/clamp()`, container queries — they're there, use them.
+- **Surprise the user when it helps.** Users often don't know what HTML/CSS can do. Novel layouts, scale play, layering, and visual rhythm are worth proposing.
+
+### Avoid
+
+- **Filler content.** Never pad a design with dummy sections, placeholder paragraphs, or invented stats just because the layout feels empty. Emptiness is a layout problem, solved with composition — not with made-up material. One thousand no's for every yes.
+- **Unilateral additions.** If you think a section would help, **ask** before adding it. The user knows the audience better than you.
+- **AI slop**, including:
+  - Aggressive gradient backgrounds
+  - Emoji that aren't part of the brand
+  - Rounded containers with a left-border accent color
+  - SVG illustrations drawn from scratch — use placeholders, or ask for real assets
+  - Overused typefaces (Inter, Roboto, Arial, system stacks — use what the project ships)
+  - Data slop (decorative numbers, unearned icons, KPI-shaped nothing)
+- **Repetition.** The same point in two sections is a design bug.
+- **Cross-project tropes.** Don't design a "web page" unless this is a web page. Don't design an "admin dashboard" unless the user asked for one.
+
+---
+
+## Variations strategy
+
+When the user asks for 2–3 variations, make the spread meaningful:
+
+- **Variant A — safe, pattern-faithful.** Uses the existing vocabulary as-is. This is the "you could ship this tomorrow" option.
+- **Variant B (and C) — increasingly exploratory.** Push on one dimension at a time: layout metaphor, information hierarchy, type treatment, density, or interaction model. Start close to A and get bolder.
+- **Don't waste variants on trivial deltas** (different accent color, slightly different padding). If A and B differ only in hex, you've delivered one variant, not two.
+- Mix conservative with novel. Mix text-heavy with imagery-led. Mix dense with airy. Goal: expose the user to as many atomic choices as possible so they can mix-and-match.
+
+Expose each variant as its own `export const Variant_X: StoryObj<typeof meta> = { render: () => <ProposalX /> }`.
+
+---
+
+## Asking questions — tips from the base
+
+- **Confirm context via a question, not an assumption.** "I assume you want to reuse the existing form card" is worse than asking.
+- When redesigning, ask what they care most about — flows, copy, or visuals — and design variants along that axis.
+- Ask whether they want divergent visuals / interactions / copy, or just polish on the existing pattern.
+- Err on the side of more questions for ambiguous briefs. For tight briefs, skip questions entirely.
+- Before showing variations, ask what dimensions they want explored (novel UX, different visuals, animation, copy).
+
+---
+
+## Do not produce
+
+- `CLAUDE.md`, `README.md`, or other documentation files
+- Real logic (Convex, API calls, auth)
+- Route definitions
+- Test files
+- Exports to PPTX / PDF / video / Canva — this skill builds Storybook stories, nothing else