diff --git a/.claude/commands/doc.md b/.claude/commands/doc.md deleted file mode 100644 index ff2bd5f4..00000000 --- a/.claude/commands/doc.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -description: ドキュメント更新コマンド ---- - -ドキュメントの漏れや矛盾を徹底的に洗い出す。**実装が絶対的な正とする。** - -# 基本方針 - -**実装が全て。AI エージェントは実装と JSDoc しか見ない。** - -- **WHAT は書かない** — 実装・型・関数名・ファイル構成から読み取れることはドキュメントに書かない -- **WHY を書く** — 実装を見ても分からない意図・背景・制約・トレードオフだけを書く -- **JSDoc と MD を重複させない** — 同じ情報を二箇所に書かない。コードの近くに書けるなら JSDoc に書く -- ARCHITECTURE.md は廃止。アーキテクチャの WHY は JSDoc または該当箇所のコードコメントに集約する -- 各ドキュメントで指定されている言語を使用すること -- **実装を絶対に変更しない** — 関数本体、型定義、export 文、関数や型定義の順序すら変更しないこと -- **特定の依存パッケージのバージョン番号をドキュメントに含めない** — バージョンの正は `package.json` を参照 -- コードやドキュメントの意図が不明な場合は、推測せずユーザーに確認すること - -# 対象範囲 - -- **README.md** — セットアップ/利用手順のみ（後述） -- **JSDoc** — 公開 API（export）のみ、WHY 中心（後述） -- **その他の MD** — CONTRIBUTING / migration guide / decisions など、**実装を見ても分からない WHY または手順** に限り許容 - -ARCHITECTURE.md など廃止対象を見つけた場合は、削除または README/JSDoc への集約を提案すること。 - -# README.md に書くべき内容 - -README は「リポジトリを使い始めるための最短パス」に限定する。WHY は JSDoc に寄せる。 - -1. **セットアップ手順** — 環境構築から動作するまでの最短パス -2. **利用手順** — 代表的な使い方（CLI コマンド、最小コード例、設定ファイル例） -3. **トラブルシューティング** — 必要な場合のみ。実装を見ても分からない「踏みがちな罠」と対処法 - -以下は README に書かない: - -- API リファレンス・型定義・関数一覧（JSDoc が正） -- アーキテクチャ説明（実装が正、必要な WHY は JSDoc） -- 開発ワークフロー・テスト実行・デプロイ手順（CLAUDE.md / package.json scripts / CONTRIBUTING.md が正） - -# JSDoc - -- **対象は公開 API（export）のみ**。内部関数には付与しない -- **基本は WHY** — 名前と型で伝わる WHAT は書かない。意図・制約・前提・トレードオフを書く -- **公開 API には `@example` を必須化** — 実装を見るだけでは分からない使い方を示す -- 必須タグ: - - `@param` — 名前と型で伝わらない意図・制約がある場合のみ - - `@returns` — 戻り値の意味が型から自明でない場合のみ - - `@template` — 型パラメータの意図がある場合のみ - - `@example` — 公開 API では必須 -- TypeScript が既に提供している冗長な型注釈は追加しない - -# 最終ステップ（必須） - -ドキュメントの変更が全て完了したら、**必ず `yarn lint` を実行**してフォーマット、スペル、スタイルを検証する。エラーがあればコミット前に修正すること。 diff --git a/.claude/commands/pr.md b/.claude/commands/pr.md deleted file mode 100644 index 05a46ece..00000000 --- a/.claude/commands/pr.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -description: プルリクエストの作成とプッシュ ---- - -1. `dev` や `main` ではないトピックブランチにいることを確認する。 -2. **プリフライトチェック（必須 — 省略不可）:** - - `yarn lint`、`yarn build`、`yarn test` がこのセッション内でまだ実行・成功していない場合、続行する前に**今すぐ実行**する。 - - 全てがパスしなければならない。失敗があれば続行前に修正する。 -3. 適切な `git` コマンドを使って現在のトピックブランチの変更をレビューする。 -4. `gh pr create` コマンドのワンライナーを生成・実行してプルリクエストを作成する。 -5. **CI 監視:** - - PR 作成直後に `gh pr checks --watch` で CI の完了を待機する。 - - テストが途中で失敗した場合は完了を待たずに修正作業に戻る。 - - 全テストが通りマージ可能になったらユーザーに報告する。 diff --git a/.claude/commands/git.md b/.claude/skills/git/SKILL.md similarity index 59% rename from .claude/commands/git.md rename to .claude/skills/git/SKILL.md index db3c0ce9..1831bcc6 100644 --- a/.claude/commands/git.md +++ b/.claude/skills/git/SKILL.md @@ -1,10 +1,14 @@ --- -description: Git 操作ルール +name: git +description: Git 操作ルール（コミット作成、メッセージ形式、事前チェック） +disable-model-invocation: true --- # コミット作成 - 「コミット」を求められた場合: + - **重要: まず `git branch --show-current` で現ブランチを確認すること** + - **重要: `main` / `master` / `dev` / `develop` にいる場合、コミットを進めず、ユーザーにトピックブランチ作成を提案する** - **重要: 必ず `git status` で現在の状態を確認すること** - **重要: 以前の状態やメモリを信用しない — 必ずステージングエリアの現状を確認** 1. ファイルが既にステージングされている場合: @@ -29,8 +33,33 @@ description: Git 操作ルール # コミット前コンテンツチェック -- `git commit` を実行する前に、必ず `git diff --staged` をスキャンし、プロジェクト固有の名称、企業名、顧客情報など、リポジトリに含めるべきでない情報がないか確認する。 -- 該当するものがあれば、コミット前にステージングから除外する。 +`git commit` を実行する前に、必ず `git diff --staged` をスキャンして以下の 2 点を確認する。 + +## 1. 機密・案件情報の検出 + +プロジェクト固有の名称、企業名、顧客情報、API キー・トークンなど、リポジトリに含めるべきでない情報がないか確認する。 + +## 2. サンプル値の慣例チェック + +サンプル値が「無いこと」ではなく「**予約済み慣例に従っていること**」を確認する。 + +**許可される値（予約済み慣例）:** + +- ドメイン: `example.com` / `example.org` / `example.net`、`*.example` / `*.test` / `*.invalid` / `*.localhost`（RFC 2606 / RFC 6761） +- IP: `127.0.0.1`、TEST-NET（`192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`）、`2001:db8::/32` +- メール: `user@example.com` 系 + +**検出対象（混入してはいけない値）:** + +- 実在する無関係ドメイン・URL・パス +- 未取得の創作ドメイン（もっともらしい造語ドメインは将来第三者が取得しうる — supply-chain / SEO リスク） +- 案件キーワード・顧客識別子・実データ由来の識別子 +- 実データ・実コーパスでの実験・デバッグの残骸（実 URL、実ページタイトル、実クエリ値など） + +**検出時の対処:** + +- ステージングから除外するのではなく、**汎用値（example.com 等）へ書き換える**（fixture 内の実ドメインは除外しても解決しない）。書き換え後にテストが通ることを確認してからコミットする +- 判断が難しい場合（実データが検証に不可欠に見える等）はユーザーに確認する # コミットメッセージの形式 @@ -39,7 +68,7 @@ description: Git 操作ルール - Conventional Commits を使用すること - 使用するタイプ: `feat`, `fix`, `docs`, `refactor`, `test`, `chore` - 使用するスコープ: - - 各パッケージ名（ネームスペースなし）: `a11y-check`, `a11y-check-core`, `a11y-check-axe-scenario`, `a11y-check-scenarios`, `archaeologist`, `backlog-projects`, `beholder`, `cli-core`, `dealer`, `filematch`, `fs`, `google-auth`, `google-sheets`, `html-distiller`, `notion`, `print`, `proc-talk`, `puppeteer-dealer`, `puppeteer-general-actions`, `puppeteer-page-scan`, `puppeteer-screenshot`, `puppeteer-scroll`, `readtext`, `remote-inspector`, `replicator`, `roar`, `shared` + - 各パッケージ名（ネームスペースなし）: `a11y-check`, `a11y-check-axe-scenario`, `a11y-check-core`, `a11y-check-scenarios`, `archaeologist`, `backlog-projects`, `beholder`, `cli-core`, `dealer`, `filematch`, `fs`, `google-auth`, `google-sheets`, `html-distiller`, `notion`, `page-cluster`, `print`, `proc-talk`, `puppeteer-dealer`, `puppeteer-general-actions`, `puppeteer-page-scan`, `puppeteer-screenshot`, `puppeteer-scroll`, `readtext`, `remote-inspector`, `replicator`, `roar`, `shared` - `repo`, `deps`, `github` - メッセージ本文の各行は100文字以下 - 件名は sentence-case, start-case, pascal-case, upper-case にしない @@ -52,11 +81,7 @@ description: Git 操作ルール ## Heredoc 形式（破壊的変更では必須） -heredoc とコマンド置換を使って複数行のコミットメッセージを渡す。これにより: - -- 特殊文字（感嘆符など）が正しく保持される -- 複数行メッセージが適切にフォーマットされる -- commitlint がメッセージを正しくパースできる +heredoc とコマンド置換を使って複数行のコミットメッセージを渡す。 **形式:** @@ -73,17 +98,8 @@ EOF )" ``` -**重要な注意点:** - -- `<<'EOF'`（クォート付き）で変数展開を防ぐ -- `EOF` の後に `)` で閉じてコマンド置換を完了 -- 破壊的変更で複数の `-m` フラグを使用しない -- メッセージ全体を `"$(cat <<'EOF' ... EOF)"` で囲む - ## シンプルなコミット（非破壊的変更） -破壊的変更のないシンプルな1行コミット: - ```bash git commit -m 'type(scope): subject line' ``` diff --git a/.claude/commands/grill-me.md b/.claude/skills/grill-me/SKILL.md similarity index 88% rename from .claude/commands/grill-me.md rename to .claude/skills/grill-me/SKILL.md index da4e6ea5..562876d7 100644 --- a/.claude/commands/grill-me.md +++ b/.claude/skills/grill-me/SKILL.md @@ -1,5 +1,7 @@ --- -description: ユーザーの計画・考えを徹底的に grill し、共通認識を構築するコマンド +name: grill-me +description: ユーザーの計画・考えを徹底的に grill し、共通認識を構築するスキル +disable-model-invocation: true --- この計画のあらゆる側面について、私たちが共通の認識に達するまで、徹底的に私に質問を投げかけてください。設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決していきましょう。各質問に対し、あなたの推奨する回答も併せて提示してください。質問は一度に一つずつ、AskUserQuestion ツールを使って投げかけてください。もしコードベースを探索することで答えが得られる質問であれば、質問する代わりにコードベースを調査してください。 diff --git a/.claude/skills/impl/SKILL.md b/.claude/skills/impl/SKILL.md index 1650e9e3..b564382d 100644 --- a/.claude/skills/impl/SKILL.md +++ b/.claude/skills/impl/SKILL.md @@ -1,5 +1,5 @@ --- -description: 合意済み計画を実装し、レビュー・QA・PdM・ドキュメント・lint/test を通して PR 作成まで進める実行系オーケストレーター +description: 合意済み計画を実装し、レビュー・QA・PdM・lint/test を通して PR 作成まで進める実行系オーケストレーター when_to_use: ユーザーが「実装して」「進めて」「/impl」と指示した場合。grill-me で合意済みの計画を実装フェーズに進めるとき disable-model-invocation: true --- @@ -7,18 +7,19 @@ disable-model-invocation: true # 手順 1. 実装スコープ・アプローチ・トレードオフの合意が会話文脈で成立しているか確認する。未成立なら `/grill-me` を起動し、合意してから次へ -2. 合意した計画の通りに実装する -3. `/code-review xhigh` を実行し、指摘を fix all -4. `/qa-engineer` を実行し、指摘を fix all -5. `/product-manager` を実行し、指摘を fix all -6. `/doc` を実行し、指摘を fix all -7. `yarn lint` を実行し、エラーを修正 -8. `yarn test` を実行し、失敗を修正 -9. `/git` の手順でコミット -10. `/pr` の手順で PR 作成 +2. **ブランチ確認**: 現在のブランチを確認し、`dev` / `main` / エピックの base branch 上にいる場合は `git checkout -b` でサブブランチを切ってから進む。git worktree かどうかの確認は行わない（エージェントは worktree 起動が前提のため、あえてチェックしない） +3. **索引確認**: ARCHITECTURE.md の索引（Reading paths / 不変条件・負の知識 / 境界と所有権）を確認し、該当する Reading path に従って対象コードを読んでから実装に入る（索引が無いリポジトリではこのステップをスキップ） +4. 合意した計画の通りに実装する +5. `/code-review medium` を実行し、指摘を fix all +6. `/qa-engineer` を実行し、指摘を fix all +7. `/product-manager` を実行し、指摘を fix all（ドキュメント整合 — JSDoc・コメント原則・索引と実装の一致 — のチェックを含む） +8. `yarn lint` を実行し、エラーを修正 +9. `yarn test` を実行し、失敗を修正 +10. `/git` の手順でコミット +11. `/pr` の手順で PR 作成 # 重要ルール - **fix all の範囲**: コードレベル・テスト追加・ドキュメント修正の指摘はその場で適用。仕様変更やスコープ拡張を伴う指摘はユーザーに許可を取る -- **ループバック**: いずれかのステップで重大な方向転換や巨大なコード変更が発生したら、ステップ 3（`/code-review xhigh`）からやり直す +- **ループバック**: いずれかのステップで重大な方向転換や巨大なコード変更が発生したら、ステップ 5（`/code-review medium`）からやり直す - **スコープ厳守**: grill-me で合意したスコープを勝手に拡張しない diff --git a/.claude/skills/pr/SKILL.md b/.claude/skills/pr/SKILL.md new file mode 100644 index 00000000..7c2f92b3 --- /dev/null +++ b/.claude/skills/pr/SKILL.md @@ -0,0 +1,28 @@ +--- +name: pr +description: プルリクエストの作成とプッシュ（プリフライトチェック、base 追従、コンフリクト検知含む） +disable-model-invocation: true +--- + +1. `dev` や `main` ではないトピックブランチにいることを確認する。 +2. **base 追従（コンフリクト予防）**: `git fetch origin ` を実行し、`git log HEAD..origin/ --oneline` で base が進んでいないか確認する。進んでいれば push 前に `git rebase origin/` する。ドキュメント系のコンフリクトは機械的に解決せず、base 側で追加された内容を方針（索引・JSDoc 配置）に沿って取り込むこと。 +3. **プリフライトチェック（必須 — 省略不可）:** + - `yarn lint`、`yarn build`、`yarn test` がこのセッション内でまだ実行・成功していない場合、続行する前に**今すぐ実行**する。rebase を行った場合は rebase 後に再実行する。 + - 全てがパスしなければならない。失敗があれば続行前に修正する。 +4. 適切な `git` コマンドを使って現在のトピックブランチの変更をレビューする。 + - **サンプル慣例のダブルチェック**: base branch との全 diff（`git diff ...HEAD`）に対して、`.claude/skills/git/SKILL.md` の「サンプル値の慣例チェック」を再実行する。コミット単位のチェックをすり抜けた実在ドメイン・未取得ドメイン・案件識別子・実データ断片がないかを PR 全体で確認する。検出したら汎用値へ書き換えて追加コミットする。 +5. **PR body を一時ファイルに保存する**: scratchpad ディレクトリに PR body（markdown）を書き出す。 +6. **push と PR 作成はユーザーが実行する**: エージェントは `git push` / `gh pr create` を実行せず、ユーザーがそのまま実行できる `!` 付きコマンドを提示する。ファイルパス引数は必ずダブルクオーテーションで囲む。 + + ``` + ! git push -u origin + ! gh pr create --title "" --body-file "<PR body の一時ファイルパス>" + ``` + +7. **マージ可能性の確認（CI watch では捕捉できない）:** + - ユーザーから PR 作成の報告を受けたら、まず `gh pr view <number> --json mergeable,mergeStateStatus` で **`CONFLICTING` / `DIRTY` を検知**する。`gh pr checks --watch` はステータスチェックしか見ないため、コンフリクトは黙って素通りする。 + - `CONFLICTING` なら CI を待たずにステップ 2 の base 追従（rebase + 方針に沿った解決）に戻り、解決後にユーザーへ `! git push --force-with-lease` を依頼する。 +8. **CI 監視:** + - `gh pr checks --watch` を**バックグラウンド実行**で起動して CI の完了を待機する（フォアグラウンド実行はターン内タイムアウトで出力が欠損する）。 + - テストが途中で失敗した場合は完了を待たずに修正作業に戻る。 + - 全テストが通りマージ可能になったらユーザーに報告する。 diff --git a/.claude/skills/product-manager/SKILL.md b/.claude/skills/product-manager/SKILL.md index eb5761df..5985cf47 100644 --- a/.claude/skills/product-manager/SKILL.md +++ b/.claude/skills/product-manager/SKILL.md @@ -37,17 +37,13 @@ description: > ### ドキュメントの書き方 -**実装が全て。AI エージェントは実装と JSDoc しか見ない。** +情報は置き場で役割が決まる。**コードには How、テストコードには What、コミットログには Why、コードコメントには Why not**（Why が必要なときは Why も）。 -追加されるすべての新機能はメンテナンスコストの直接的な増加であり、長期的に動かし続けるための知識は記録されなければならない。 -ただし、その記録先は実装と JSDoc が優先である。MD ドキュメントは「実装を見ても分からない WHY」だけを担う。 - -- **WHAT は書かない** — 名前・型・構造から読み取れることはドキュメント化しない -- **WHY を書く** — 意図・背景・制約・トレードオフだけを書く -- **JSDoc と MD を重複させない** — 同じ情報を二箇所に書かない。コードの近くに書けるなら JSDoc に書く -- **公開 API には `@example` 必須** — 実装を見るだけでは分からない使い方を JSDoc で示す -- **README はセットアップ/利用手順のみ**、ARCHITECTURE.md は廃止 -- 詳細は `/doc` コマンドの方針に従う +- **JSDoc = 公開 API（export）の API ユーザー向け文書** — IDE ホバーで実装を読まない読者に届くため、WHAT / HOW / WHY を適切に書き、`@example` を必須とする。メインの公開 API は README にも載せる +- **非公開 API の JSDoc は必須にしない** — ただし複雑な内部モジュールの設計 WHY / Why not はファイルレベル JSDoc が推奨置き場 +- **ARCHITECTURE.md は索引** — 全体地図・境界・依存方向・不変条件・負の知識・Reading paths のみを担う（コードの再説明や実装詳細の保存庫にしない）。実装詳細の正は JSDoc +- **README はセットアップ / 利用手順 / メイン公開 API のみ** +- **計画相対概念の禁止** — 実装計画由来の相対概念（Phase/Step 番号、「本 PR」「今回」「旧実装」「導入予定」）を JSDoc・テスト名・ドキュメントに書かない。現在の挙動と意図的な不在として自己完結に書く。外部参照は issue / PR 番号のみ可 メンテナンスを支える条件: @@ -89,8 +85,11 @@ description: > - README にセットアップ、実行、テストの手順があるか？ - 仕様が変化する機能について、根拠と変更履歴が記録されているか？ - 最新情報の入手先（URL、検索キーワード）への明確なポインタがあるか？ -- 公開 API の JSDoc は揃っているか？`@example` は付いているか？ +- 公開 API の JSDoc は揃っているか？`@example` は付いているか？WHAT / HOW / WHY が API ユーザー向けに書かれているか？ - 実装と矛盾する MD ドキュメントが残っていないか？ +- **索引整合**: ARCHITECTURE.md（存在する場合）の境界・依存方向・不変条件・Reading paths が変更後も実装と一致しているか？変更が境界や不変条件に触れた場合、索引は更新されているか？ +- **計画相対概念の混入**: Phase/Step 番号・「本 PR」「今回」「導入予定」等の計画相対語が JSDoc・テスト名・ドキュメントに混入していないか？（コードに実在する語彙は正当） +- **コメント原則**: コードコメントは Why not（必要なら Why）を書いているか？WHAT の再説明や「レビュアーへの説明」になっていないか？ #### 3b. メンテナビリティ diff --git a/CLAUDE.md b/CLAUDE.md index d26c6b77..4e13372d 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -22,25 +22,35 @@ D-ZERO 株式会社の Web 開発・テスト・自動化ツール群（`@d-zero - `yarn watch` — `lerna run watch --parallel` - `yarn test` — Vitest によるテスト実行 - `yarn lint` — eslint / prettier / textlint / cspell を直列実行 -- `yarn release` / `yarn release:alpha` 等 — `lerna version`（independent モード）→ `release:trigger` で `git push origin main --follow-tags` と `v-release` タグ強制更新を行う。リリース手順は `/release` コマンド参照 +- `yarn release` / `yarn release:alpha` 等 — リリース用。**ユーザーのみ実行可**（エージェントは実行しない） +- **git worktree からのビルドは `NX_WORKSPACE_ROOT_PATH` 必須**: リポジトリ内部にネストした worktree（`.claude/worktrees/*` 等）から素の `yarn build` を実行すると、Nx がルートをメインチェックアウトに誤解決し、成功表示のまま成果物がメイン側に書かれる（worktree の `lib/` は生成されない）。`NX_WORKSPACE_ROOT_PATH=<worktree絶対パス> yarn build` でルートを明示すること ### コマンド制約 - **yarn のみ使用**: npm / pnpm / bun / deno によるコマンド実行は禁止 - **パッケージディレクトリに cd しない**: 常にリポジトリルートから実行 -- **ビルドは `yarn build` のみ**: `npx tsc`、`lerna run build --scope` 等の個別指定は禁止 +- **全体実行の強制**: 時間がかかっても `yarn build` / `yarn lint` / `yarn test` のリポジトリ全体実行を使う。`tsc` / `eslint` / `prettier` の単発実行・ファイルスコープ実行（`npx tsc`、`lerna run build --scope`、`npx eslint <file>` 等）は禁止 - **コマンドの連続実行禁止**: `&&`、`;`、改行によるコマンド連結をしない。1回の Bash 呼び出しで1コマンドのみ実行する。連結されたコマンドは settings.json の permissions allow/deny でパターンマッチできず、毎回ユーザーの手動承認が必要になり効率が大幅に低下する +- **main / dev ブランチでの作業・コミット禁止**: 作業開始前に `git branch --show-current` で現ブランチを確認し、`main` / `master` / `dev` / `develop` にいる場合は `git switch -c <topic>` でトピックブランチを作ってから作業する ## アーキテクチャ 各パッケージの責務・依存関係はソースコードと `package.json` の `dependencies` から把握すること。設計判断の WHY は該当コード位置の JSDoc に記載する（例: `puppeteer-page-scan/src/types.ts` の `PageHookSource`、`dealer/src/deal.ts` の `AbortSignal` 挙動）。 -ドキュメントと実装に矛盾がある場合は、**実装が正**とし、ドキュメントを修正すること。 +## ドキュメント原則 + +情報は置き場で役割が決まる。**コードには How、テストコードには What、コミットログには Why、コードコメントには Why not**（Why が必要なときは Why も書く）。 + +- **JSDoc = 公開 API（export）の API ユーザー向け文書**: IDE ホバーで実装を読まない読者に届くため、WHAT / HOW / WHY を適切に書き、`@example` を必須とする。メインの公開 API は README にも載せる +- **非公開 API の JSDoc は必須にしない**: ただし複雑な内部モジュールの設計 WHY / Why not はファイルレベル JSDoc が推奨置き場 +- **README はセットアップ / 利用手順 / メイン公開 API のみ** +- **計画相対概念の禁止**: 実装計画に由来する相対概念（Phase/Step 番号、「本 PR」「今回」「旧実装」「導入予定」）を JSDoc・テスト名・ドキュメントに書かない。現在の挙動と意図的な不在（Why not）として自己完結に書く。外部参照は issue / PR 番号のみ可 +- **ドキュメントと実装の矛盾**: **実装が正**とし、ドキュメントを修正すること ## independent モードの注意 - 各パッケージは個別のバージョンを持つ。`lerna version` は変更のあったパッケージのみ昇格させる -- リリース時は `v-release` タグの強制更新を伴う（`publish.yml` のトリガー） +- リリース時は `v-release` タグの強制更新を伴い、タグ push で Actions のリリース（[publish.yml](.github/workflows/publish.yml)）が開始される - 単一パッケージの破壊的変更でもリポジトリ全体の major bump にはならない ## コーディング規約 @@ -56,6 +66,7 @@ D-ZERO 株式会社の Web 開発・テスト・自動化ツール群（`@d-zero - `.env`、`.env.*` 等の機密ファイルを読み取り・編集・コミットしない（機密ファイルの判断は `.gitignore` を参考にすること） - `credentials.json`、`token.json` 等の Google API 認証情報も同様に扱う - コミット前に `git diff --staged` で機密情報（API キー、トークン、パスワード、企業名、顧客情報）が含まれていないか確認する +- **サンプル値は予約済み慣例に従う**: ドメインは `example.com` / `*.example` / `*.test` 等（RFC 2606/6761）、IP は TEST-NET。実在の無関係ドメイン、未取得の創作ドメイン、案件識別子、実データ・実コーパスの断片を成果物に残さない（詳細は `.claude/skills/git/SKILL.md` のサンプル値慣例チェック） - 環境変数やシークレットをコード内にハードコードしない ### サプライチェーン保護 @@ -71,8 +82,13 @@ D-ZERO 株式会社の Web 開発・テスト・自動化ツール群（`@d-zero タスクに応じて `.claude/skills/` 配下のスキルを参照すること。 -| スキル | パス | 用途 | -| --------------- | ----------------------------------------- | ----------------------------------------------------------- | -| Product Manager | `.claude/skills/product-manager/SKILL.md` | リポジトリ分析、ドキュメント生成・レビュー、PR レビュー | -| QA Engineer | `.claude/skills/qa-engineer/SKILL.md` | コードレビュー、テスト品質チェック、カバレッジ改善 | -| Impl | `.claude/skills/impl/SKILL.md` | 合意済み計画の実装・検証・PR 作成までのオーケストレーション | +| スキル | パス | 用途 | +| --------------- | ----------------------------------------- | -------------------------------------------------------------- | +| Product Manager | `.claude/skills/product-manager/SKILL.md` | リポジトリ分析、ドキュメント整合チェック、PR レビュー | +| QA Engineer | `.claude/skills/qa-engineer/SKILL.md` | コードレビュー、テスト品質チェック、カバレッジ改善 | +| Impl | `.claude/skills/impl/SKILL.md` | 合意済み計画の実装・検証・PR 作成までのオーケストレーション | +| git | `.claude/skills/git/SKILL.md` | コミット作成ルール（粒度、メッセージ形式、コミット前チェック） | +| pr | `.claude/skills/pr/SKILL.md` | PR 作成（プリフライト、base 追従、CI 監視） | +| grill-me | `.claude/skills/grill-me/SKILL.md` | 計画・設計の合意形成（実装前の徹底質問） | + +コミットは必ず `.claude/skills/git/SKILL.md`、PR 作成は `.claude/skills/pr/SKILL.md` の手順に従うこと。