デザインシステムファクトリー

このリポジトリ（8341-ui）をひな形にして、新しいデザインシステムのリポジトリを作る。 画面設計の判断は design-principles スキルに従い、プロダクト固有の前提はユーザーへのヒアリングで決める。位置づけと全体像は docs/factory.md（必要になったときだけ読む）。

生成されるもの: 同じスタック（Base UI・Tailwind v4・DTCG トークン・Storybook・検査・改善ループ・design-principles）を持ち、名前・接頭辞・キーカラー・見た目の性格・DESIGN.md が新しいプロダクトに合わせて書き換わったリポジトリ。

手順

各段階の詳しい文書は、その段階に入ったときに読む。

1. ルールを読む: design-principles スキルを読み込み、mode-1-init.md（新規作成）に従う
2. ヒアリングする: hearing.md の項目を一度にまとめて聞き、要約して確認する
3. 設定ファイルを書く: 回答を JSON にする（形は hearing.md の「設定ファイル」。作業用の一時ディレクトリに置き、このリポジトリにはコミットしない）
4. 生成する: make factory CONFIG=<設定ファイル> OUT=<出力先>
   • git で追跡しているファイルだけがコピーされる。未コミットの変更を含めたいときは先にコミットする
   • 最後に「ひな形の見た目の性格が残っている箇所」と「次の手順」が表示される
5. 生成先で仕上げる: finish.md の 1〜9 を順に行う
6. 公開する（ユーザーの承認を得てから）: コミットし、承認されたら GitHub にリポジトリを作って push する（例: gh repo create <owner>/<name> --public --source . --push）。GitHub Pages（gh-pages ブランチ）と main の保護をユーザーに案内する
7. 報告する: 生成したリポジトリの場所、ヒアリングの要約、ひな形から変えた点、外した必須とその理由、残っている作業を短く伝える

このリポジトリ側の改善

• 生成で困った点（置き換え漏れ、手作業が多い手順）は、scripts/factory/create.mjs かこのスキルを直す PR にする
• 画面設計のルールのギャップは docs/design-principles/ を直す（design-principles スキルの feedback.md）

やってはいけないこと

• ヒアリングを飛ばして既定値だけで生成する（共有の基盤か専用かで DESIGN.md の書き方が変わる）
• 生成先で contrast.rules.json や WCAG の必須を緩めてチェックを通す
• ユーザーの承認なしに GitHub にリポジトリを作る・公開する