chore(repo): sync Claude Code configuration from ai-setup template

.claude/commands/doc.md

@@ -1,11 +1,31 @@
 ---
-description: Update documentation commands
+description: ドキュメント更新コマンド
 ---
 
-Thoroughly identify any omissions or inconsistencies in the documentation. **The implementation is the absolute source of truth.**
+ドキュメントの漏れや矛盾を徹底的に洗い出す。**実装が絶対的な正とする。**
 
-- README.md is intended for API users
-- ARCHITECTURE.md is intended for contributors
-- Other documents should match their respective content
+# 対象範囲
 
-Use the language specified in each document.
+- README.md は API ユーザー向け
+- ソースコード内の JSDoc コメント
+- その他のドキュメントはそれぞれの内容に対応
+
+# ルール
+
+- 各ドキュメントで指定されている言語を使用すること
+- **実装を絶対に変更しない** — 関数本体、型定義、export 文、関数や型定義の順序すら変更しないこと
+- **特定の依存パッケージのバージョン番号をドキュメントに含めない** — バージョンの正は `package.json` を参照
+- コードやドキュメントの意図が不明な場合は、推測せずユーザーに確認すること
+
+# JSDoc
+
+- エクスポートされた全ての関数と型に JSDoc コメントを付与すること
+- 必須タグ:
+  - `@param` — 各パラメータに対して。説明は必須
+  - `@returns` — 戻り値の説明は必須
+  - `@template` — 各型パラメータに対して
+- TypeScript が既に提供している冗長な型注釈は追加しない
+
+# 最終ステップ（必須）
+
+ドキュメントの変更が全て完了したら、**必ず `yarn lint` を実行**してフォーマット、スペル、スタイルを検証する。エラーがあればコミット前に修正すること。

.claude/commands/git.md

@@ -1,66 +1,98 @@
 ---
-description: Git manipulation rules
+description: Git 操作ルール
 ---
 
-# Commit creation
-
-- When asked to "commit":
-  1. Check staged files using `git diff --staged` and create a commit message using _only_ the staged files.
-     - Once the message is ready, directly propose the commit command to the user.
-  2. If no files are staged, check the differences using `git status`, then stage files sequentially based on the following commit granularity before committing:
-     - Separate commits by package.
-     - Commit dependencies first (if dependency order is unclear, check using `npx lerna list --graph`).
-- If the OS, application settings, or context suggest a language other than English is being used, provide a translation and explanation of the commit message in that language immediately before proposing the commit command to the user.
-- When the commit message is ready, try to execute it directly as `git commit` (the user will approve as appropriate).
-
-# Commit message format
-
-- You must write in English
-- You must use the imperative mood
-- You must use conventional commits
-  - You must use the following types:
-    - `feat`
-    - `fix`
-    - `docs`
-    - `refactor`
-    - `test`
-    - `chore`
-  - You must use the following scopes:
-    - Each package name (without namespace)
-    - `repo`
-    - `deps`
-    - `github`
-- The message body's lines must not be longer than 100 characters
-- The subject must not be sentence-case, start-case, pascal-case, upper-case
-
-# Commit message safety guidelines
-
-- Always use single quotes (') instead of double quotes (") for commit messages to avoid shell interpretation issues
-- For breaking changes or complex commit messages:
-  - Option 1 (Recommended for complex messages): Use the git commit without -m flag to open an editor:
-
-    ```
-    git commit
-    ```
-
-    Then write your commit message in the editor with the proper format:
-
-    ```
-    type(scope)!: subject line
-
-    BREAKING CHANGE: detailed explanation
-    - Additional details
-    - More information
-    ```
-
-  - Option 2: For command line commits with breaking changes, use a simple format:
-    ```
-    git commit -m 'type(scope)!: subject line' -m 'BREAKING CHANGE: explanation'
-    ```
-
-- Avoid using special characters like \n in command line commit messages
-- For multi-line messages in command line, use multiple -m parameters instead of line breaks
-- When lines exceed 100 characters, split them using multiple -m flags:
-  ```
-  git commit -m 'type(scope): subject line' -m 'First line of body' -m 'Second line of body'
-  ```
+# コミット作成
+
+- 「コミット」を求められた場合:
+  - **重要: 必ず `git status` で現在の状態を確認すること**
+  - **重要: 以前の状態やメモリを信用しない — 必ずステージングエリアの現状を確認**
+  1. ファイルが既にステージングされている場合:
+     - **重要: ステージング済みファイルがある場合、`git add` や `git restore` を絶対に使わない**
+     - **重要: ステージングエリアを一切変更しない**
+     - `git diff --staged` でステージング済みファイルを確認し、そのファイル*のみ*に基づくコミットメッセージを作成
+     - メッセージ付きで `git commit` を直接実行（ユーザーが適宜承認する）
+     - ユーザーが既にステージングエリアを準備済み — その判断を完全に尊重すること
+  2. ステージングされたファイルがない場合:
+     - `git status` で差分を確認
+     - 以下のコミット粒度に基づいてファイルを順次ステージングしてからコミット:
+       - パッケージ単位でコミットを分割
+       - 依存元を先にコミット（依存順序が不明な場合は `yarn lerna list --graph` で確認）
+- **各コミット後:**
+  - **重要: 自動的に次のコミットに進まない**
+  - **重要: 次に何をすべきか推測しない**
+  - **重要: 以前の状態のメモリを信用しない**
+  - `git status` と `git diff` で現在の状態を確認
+  - この判定プロセスの最初に戻る（ファイルがステージングされているかどうかの確認）
+  - 続行する前にユーザーの確認または新しい指示を待つ
+- OS、アプリケーション設定、またはコンテキストから英語以外の言語が使用されていると判断される場合、コミットコマンド実行の直前に、コミットメッセージの翻訳と説明をその言語で提供すること。
+
+# コミット前コンテンツチェック
+
+- `git commit` を実行する前に、必ず `git diff --staged` をスキャンし、プロジェクト固有の名称、企業名、顧客情報など、リポジトリに含めるべきでない情報がないか確認する。
+- 該当するものがあれば、コミット前にステージングから除外する。
+
+# パッケージのコミット順序（依存元優先）
+
+複数パッケージにまたがる変更をコミットする場合、必ず**リーフからルートへ**コミットする。依存順序が不明な場合は `yarn lerna list --graph` で確認すること。
+
+- ルート設定の変更（`tsconfig.json`, CI 等）はパッケージの変更より先にコミット
+- 単一パッケージの変更は順序付け不要 — そのパッケージだけをコミット
+
+# コミットメッセージの形式
+
+- 英語で記述すること
+- 命令法を使用すること
+- Conventional Commits を使用すること
+  - 使用するタイプ: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+  - 使用するスコープ:
+    - 各パッケージ名（ネームスペースなし）: `builder`, `check-frontend-env`, `create-frontend`, `custom-components`, `postcss-config`, `scaffold`
+    - `repo`, `deps`, `github`
+- メッセージ本文の各行は100文字以下
+- 件名は sentence-case, start-case, pascal-case, upper-case にしない
+
+# コミットメッセージの安全ガイドライン
+
+- 破壊的変更や複雑なコミットメッセージには、必ず heredoc 形式を使用（下記参照）
+- シンプルな1行コミットにはシングルクォート (') を使用
+- 破壊的変更で複数の -m フラグを絶対に使わない（commitlint のパースエラーの原因になる）
+
+## Heredoc 形式（破壊的変更では必須）
+
+heredoc とコマンド置換を使って複数行のコミットメッセージを渡す。これにより:
+
+- 特殊文字（感嘆符など）が正しく保持される
+- 複数行メッセージが適切にフォーマットされる
+- commitlint がメッセージを正しくパースできる
+
+**形式:**
+
+```bash
+git commit -m "$(cat <<'EOF'
+type(scope)!: subject line
+
+BREAKING CHANGE: 説明
+
+詳細:
+- 変更点1
+- 変更点2
+EOF
+)"
+```
+
+**重要な注意点:**
+
+- `<<'EOF'`（クォート付き）で変数展開を防ぐ
+- `EOF` の後に `)` で閉じてコマンド置換を完了
+- 破壊的変更で複数の `-m` フラグを使用しない
+- メッセージ全体を `"$(cat <<'EOF' ... EOF)"` で囲む
+
+## シンプルなコミット（非破壊的変更）
+
+破壊的変更のないシンプルな1行コミット:
+
+```bash
+git commit -m 'type(scope): subject line'
+```
+
+複数行の非破壊的コミットにも、適切なフォーマットを確保するため heredoc 形式を使用すること

.claude/commands/pr.md

@@ -1,7 +1,14 @@
 ---
-description: Create and push a pull request
+description: プルリクエストの作成とプッシュ
 ---
 
-1. Ensure that you are on a topic branch that is not `dev` or `main`.
-2. Review the changes on the current topic branch using appropriate `git` commands.
-3. Generate and execute a one-liner `gh pr create` command to create a pull request.
+1. `dev` や `main` ではないトピックブランチにいることを確認する。
+2. **プリフライトチェック（必須 — 省略不可）:**
+   - `yarn lint`、`yarn build`、`yarn test` がこのセッション内でまだ実行・成功していない場合、続行する前に**今すぐ実行**する。
+   - 全てがパスしなければならない。失敗があれば続行前に修正する。
+3. 適切な `git` コマンドを使って現在のトピックブランチの変更をレビューする。
+4. `gh pr create` コマンドのワンライナーを生成・実行してプルリクエストを作成する。
+5. **CI 監視:**
+   - PR 作成直後に `gh pr checks --watch` で CI の完了を待機する。
+   - テストが途中で失敗した場合は完了を待たずに修正作業に戻る。
+   - 全テストが通りマージ可能になったらユーザーに報告する。

.claude/settings.json

@@ -0,0 +1,12 @@
+{
+	"permissions": {
+		"deny": [
+			"Read(**/.env)",
+			"Read(**/.env.*)",
+			"Edit(**/.env)",
+			"Edit(**/.env.*)",
+			"Write(**/.env)",
+			"Write(**/.env.*)"
+		]
+	}
+}