@k2works/claude-code-booster 6.4.0 → 6.5.0

package/lib/assets/.claude/skills/developing-release/SKILL.md

@@ -1,120 +1,120 @@
----
-name: developing-release
-description: アプリケーションのリリースワークフローを一貫実行。品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を自動化する。「リリースしたい」「バージョンを上げたい」「CHANGELOG を生成したい」「リリース前のチェックをしたい」といった場面で発動する。リリース手順を標準化することで、ヒューマンエラーを排除し、いつでも安全にリリースできる状態を維持する。
----
-
-# リリースワークフロー
-
-品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を一貫して実行する。
-
-リリースを自動化する価値は「いつでもリリースできる」状態を維持すること。手作業によるミスを排除し、品質ゲートで最低品質を保証する。
-
-## 参照ドキュメント
-
-- @docs/reference/リリースガイド.md — リリースワークフロー全体
-
-## オプション
-
-| オプション | 説明 |
-|-----------|------|
-| なし | ドライランを実行（デフォルト） |
-| `--dry-run` | CHANGELOG プレビュー + バージョン計算 |
-| `--patch` | パッチリリース（バグ修正） |
-| `--minor` | マイナーリリース（新機能追加、後方互換あり） |
-| `--major` | メジャーリリース（破壊的変更） |
-| `--preflight` | 品質ゲートのみ実行 |
-| `--deploy` | リリース + デプロイ（`--patch` / `--minor` / `--major` と併用） |
-
-## リリースフロー
-
-1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認する
-2. **リリース種別選択**: patch / minor / major を選択する
-3. **品質ゲート（preflight）**: 全チェックを通過する
-4. **リリース実行**: バージョンバンプ→CHANGELOG 生成→commit + tag
-5. **リモートプッシュ**: コミットとタグをプッシュする
-6. **プルリクエスト作成**: リリースブランチからメインブランチへの PR を作成し、CHANGELOG の差分をレビューする
-7. **デプロイ**: 必要に応じて本番デプロイを実行する
-
-## 品質ゲート（preflight）
-
-リリース前に以下のチェックを直列実行する。全チェック通過が必須。
-
-| チェック | コマンド | 内容 |
-| :--- | :--- | :--- |
-| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
-| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
-| ユニットテスト | `release:preflight:test` | 全テストパス |
-| ビルド確認 | `release:preflight:build` | ビルド成功 |
-| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
-
-## バージョニング規則
-
-[Semantic Versioning](https://semver.org/) に従う。
-
-| 種類 | 変更例 | バージョン変化 |
-| :--- | :--- | :--- |
-| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
-| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
-| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
-
-モノレポ構成の場合、全パッケージのバージョンを同期管理する。
-
-## CHANGELOG 生成ルール
-
-[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成する。
-
-| prefix | カテゴリ |
-| :--- | :--- |
-| `feat` | Features |
-| `fix` | Bug Fixes |
-| `docs` | Documentation |
-| `refactor` | Refactoring |
-| `test` | Tests |
-| `chore` / `perf` / `ci` / `style` / `build` | その他 |
-
-直近の git tag から HEAD までのコミットを対象とする。タグが存在しない場合は全コミット履歴を対象とする。
-
-## リリース実行ステップ
-
-| ステップ | 内容 |
-| :--- | :--- |
-| [1/4] バージョン更新 | セマンティックバージョニングに従って更新 |
-| [2/4] CHANGELOG 生成 | コミットを分類し CHANGELOG.md を生成 |
-| [3/4] git commit + tag | `release: vX.X.X` でコミット→`vX.X.X` タグ作成 |
-| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
-
-## 途中から再開
-
-リリース作業の途中から再開する場合は、現在の状態を確認する。
-
-**Example:**
-
-```
-ユーザー: 「品質ゲートは通った。リリースを実行したい」
-回答: --preflight の結果を確認し、全チェック通過を検証する。
-      --patch / --minor / --major のいずれかでリリースを実行する。
-```
-
-## トラブルシューティング
-
-- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行する
-- **テスト失敗**: テストを修正してからリリースを再実行する
-- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
-
-## コンテキスト管理
-
-品質ゲート完了後、CHANGELOG 生成後、リリースコミット完了後に `/compact` を実施する。
-
-## 注意事項
-
-- ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済みであること（前提条件）
-- working tree がクリーンでないとリリース不可
-- リリース前に必ずドライランで内容を確認する
-- Conventional Commits でコミットメッセージを記述し CHANGELOG の品質を確保する
-
-## 関連スキル
-
-- `git-commit` — Conventional Commits 準拠のコミット作成
-- `managing-operations` — デプロイ・運用管理
-- `planning-releases` — リリース・イテレーション計画
-- `orchestrating-development` — 開発フェーズ全体のワークフロー
+---
+name: developing-release
+description: アプリケーションのリリースワークフローを一貫実行。品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を自動化する。「リリースしたい」「バージョンを上げたい」「CHANGELOG を生成したい」「リリース前のチェックをしたい」といった場面で発動する。リリース手順を標準化することで、ヒューマンエラーを排除し、いつでも安全にリリースできる状態を維持する。
+---
+
+# リリースワークフロー
+
+品質ゲート→バージョンバンプ→CHANGELOG 生成→git commit + tag を一貫して実行する。
+
+リリースを自動化する価値は「いつでもリリースできる」状態を維持すること。手作業によるミスを排除し、品質ゲートで最低品質を保証する。
+
+## 参照ドキュメント
+
+- @docs/reference/リリースガイド.md — リリースワークフロー全体
+
+## オプション
+
+| オプション | 説明 |
+|-----------|------|
+| なし | ドライランを実行（デフォルト） |
+| `--dry-run` | CHANGELOG プレビュー + バージョン計算 |
+| `--patch` | パッチリリース（バグ修正） |
+| `--minor` | マイナーリリース（新機能追加、後方互換あり） |
+| `--major` | メジャーリリース（破壊的変更） |
+| `--preflight` | 品質ゲートのみ実行 |
+| `--deploy` | リリース + デプロイ（`--patch` / `--minor` / `--major` と併用） |
+
+## リリースフロー
+
+1. **ドライラン**: CHANGELOG プレビューとバージョン計算を確認する
+2. **リリース種別選択**: patch / minor / major を選択する
+3. **品質ゲート（preflight）**: 全チェックを通過する
+4. **リリース実行**: バージョンバンプ→CHANGELOG 生成→commit + tag
+5. **リモートプッシュ**: コミットとタグをプッシュする
+6. **プルリクエスト作成**: リリースブランチからメインブランチへの PR を作成し、CHANGELOG の差分をレビューする
+7. **デプロイ**: 必要に応じて本番デプロイを実行する
+
+## 品質ゲート（preflight）
+
+リリース前に以下のチェックを直列実行する。全チェック通過が必須。
+
+| チェック | コマンド | 内容 |
+| :--- | :--- | :--- |
+| working tree クリーン | `release:preflight:clean` | 未コミット変更がないこと |
+| 静的解析 | `release:preflight:lint` | lint エラーがないこと |
+| ユニットテスト | `release:preflight:test` | 全テストパス |
+| ビルド確認 | `release:preflight:build` | ビルド成功 |
+| E2E テスト | `release:preflight:e2e` | E2E テスト全パス |
+
+## バージョニング規則
+
+[Semantic Versioning](https://semver.org/) に従う。
+
+| 種類 | 変更例 | バージョン変化 |
+| :--- | :--- | :--- |
+| `patch` | バグ修正、軽微な改善 | `0.1.0` → `0.1.1` |
+| `minor` | 新機能追加（後方互換あり） | `0.1.0` → `0.2.0` |
+| `major` | 破壊的変更 | `0.1.0` → `1.0.0` |
+
+モノレポ構成の場合、全パッケージのバージョンを同期管理する。
+
+## CHANGELOG 生成ルール
+
+[Conventional Commits](https://www.conventionalcommits.org/) に基づいて自動生成する。
+
+| prefix | カテゴリ |
+| :--- | :--- |
+| `feat` | Features |
+| `fix` | Bug Fixes |
+| `docs` | Documentation |
+| `refactor` | Refactoring |
+| `test` | Tests |
+| `chore` / `perf` / `ci` / `style` / `build` | その他 |
+
+直近の git tag から HEAD までのコミットを対象とする。タグが存在しない場合は全コミット履歴を対象とする。
+
+## リリース実行ステップ
+
+| ステップ | 内容 |
+| :--- | :--- |
+| [1/4] バージョン更新 | セマンティックバージョニングに従って更新 |
+| [2/4] CHANGELOG 生成 | コミットを分類し CHANGELOG.md を生成 |
+| [3/4] git commit + tag | `release: vX.X.X` でコミット→`vX.X.X` タグ作成 |
+| [4/4] サマリー表示 | バージョン変化、タグ名、次のステップを表示 |
+
+## 途中から再開
+
+リリース作業の途中から再開する場合は、現在の状態を確認する。
+
+**Example:**
+
+```
+ユーザー: 「品質ゲートは通った。リリースを実行したい」
+回答: --preflight の結果を確認し、全チェック通過を検証する。
+      --patch / --minor / --major のいずれかでリリースを実行する。
+```
+
+## トラブルシューティング
+
+- **working tree がクリーンでない**: 変更をコミットまたは `git stash` してからリリース再実行する
+- **テスト失敗**: テストを修正してからリリースを再実行する
+- **リリースを元に戻したい**: リモートプッシュ前なら `git tag -d vX.X.X && git reset --hard HEAD~1`
+
+## コンテキスト管理
+
+品質ゲート完了後、CHANGELOG 生成後、リリースコミット完了後に `/compact` を実施する。
+
+## 注意事項
+
+- ビルドツール・パッケージマネージャーがセットアップ済み、依存関係インストール済みであること（前提条件）
+- working tree がクリーンでないとリリース不可
+- リリース前に必ずドライランで内容を確認する
+- Conventional Commits でコミットメッセージを記述し CHANGELOG の品質を確保する
+
+## 関連スキル
+
+- `git-commit` — Conventional Commits 準拠のコミット作成
+- `managing-operations` — デプロイ・運用管理
+- `planning-releases` — リリース・イテレーション計画
+- `orchestrating-development` — 開発フェーズ全体のワークフロー

package/lib/assets/.claude/skills/developing-review/SKILL.md

@@ -1,175 +1,175 @@
----
-name: developing-review
-description: 開発成果物のマルチパースペクティブレビューを実施。XP エージェント（プログラマー、テスター、アーキテクト、テクニカルライター、ユーザー代表）を並列起動し、コード品質・テスト品質・設計整合性・ドキュメント品質・利用者視点からフィードバックを収集・統合する。「コードレビューして」「PR をレビューして」「実装をチェックして」「テストコードをレビューして」「この変更をレビューしてほしい」「コードの品質を確認して」といった場面で発動する。開発成果物に対するレビュー依頼があれば積極的に使用すること。
----
-
-# 開発成果物レビュー
-
-開発フェーズの成果物（プロダクションコード、テストコード、PR、リファクタリング結果など）を複数の XP エージェントで並列レビューし、多角的なフィードバックを統合する。
-
-## レビューの価値
-
-コードレビューは単なるバグ発見の手段ではない。設計の妥当性、テストの十分性、将来の変更容易性、ドキュメントとの整合性、そして実際のユーザーにとっての価値を同時に検証することで、「変更を楽に安全にできて役に立つソフトウェア」を維持する。
-
-## レビューエージェント
-
-| エージェント | 視点 | 着眼点 |
-|:---|:---|:---|
-| `xp-programmer` | コード品質 | SOLID 原則、DRY、命名、可読性、TDD サイクルの遵守、シンプルな設計 |
-| `xp-tester` | テスト品質 | テストカバレッジ、境界値、エッジケース、テストの信頼性、テストピラミッドのバランス |
-| `xp-architect` | 設計整合性 | アーキテクチャとの整合、依存関係の方向、変更容易性、技術的負債の蓄積 |
-| `xp-technical-writer` | ドキュメント品質 | API ドキュメント、コメントの適切さ、README の更新必要性、機能の理解しやすさ |
-| `xp-user-representative` | 利用者視点 | 実装された機能がユーザーの期待に合っているか、業務フローとの整合、使い勝手 |
-
-## レビュー対象の判定
-
-ユーザーのリクエストに応じてレビュー範囲を決定する。
-
-| リクエスト | レビュー範囲 |
-|:---|:---|
-| 「PR をレビュー」 | `git diff` で変更差分を取得 |
-| 「このファイルをレビュー」 | 指定ファイルの全体 |
-| 「最近の変更をレビュー」 | `git log` + `git diff` で直近の変更を取得 |
-| 「実装をレビュー」 | 指定された機能に関連するファイル群 |
-
-## レビューワークフロー
-
-### 1. レビュー対象の収集
-
-レビュー対象のコードを特定し、変更内容を把握する。
-
-- PR の場合: `git diff` でベースブランチとの差分を取得
-- ファイル指定の場合: 指定ファイルと関連ファイルを読み取る
-- 関連するテストファイル、設計ドキュメントも収集する
-
-### 2. エージェントの並列起動
-
-Agent ツールを使い、5 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
-
-```
-あなたは {エージェント名} です。
-.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
-
-## レビュー対象
-{変更差分 / ファイル内容}
-
-## 関連コンテキスト
-{関連する設計ドキュメント、テストファイル、ユーザーストーリー}
-
-## レビュー観点
-{エージェント固有の着眼点}
-
-## 出力形式
-以下の形式でフィードバックを返してください：
-
-### 評価サマリー
-（1-2 文で全体評価）
-
-### 良い点
-- （具体的に）
-
-### 改善提案
-- 【重要度: 高/中/低】（ファイル:行番号）（具体的な改善提案と理由）
-
-### 懸念事項
-- （潜在的なバグ、セキュリティリスク、パフォーマンス問題など）
-
-### スコープ外の発見
-- （レビュー対象外だが報告すべき問題）
-```
-
-#### Agent ツールが利用できない場合のフォールバック
-
-Agent ツールが利用できない環境では、5 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
-
-### 3. フィードバックの統合
-
-全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
-
-```markdown
-## コードレビュー結果
-
-### レビュー対象
-- {ファイル名 / PR 番号}
-
-### 総合評価
-（全エージェントの評価を統合した 2-3 文の評価）
-
-### 改善提案（重要度順）
-
-#### 高（マージ前に対応すべき）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-#### 中（対応推奨）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-#### 低（改善の余地あり）
-| # | 提案 | 箇所 | 指摘元 | 理由 |
-|---|------|------|--------|------|
-
-### 矛盾事項
-
-複数エージェントの指摘が相反する場合、ここに記載する。
-
-| # | 視点 A | 視点 B | 論点 | 推奨判断 |
-|---|--------|--------|------|----------|
-
-### エージェント別フィードバック詳細
-
-<details>
-<summary>xp-programmer（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-tester（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-architect（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-technical-writer（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-
-<details>
-<summary>xp-user-representative（高: N / 中: N / 低: N）</summary>
-（フィードバック全文）
-</details>
-```
-
-### 4. 改善アクションの提案
-
-重要度「高」の指摘は具体的な修正コードを提案する。修正を適用するかはユーザーの判断に委ねる。
-
-### 5. レビュー結果の保存
-
-統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
-
-## レビュー完了条件
-
-以下をすべて満たした場合にレビュー完了とする。
-
-- 全エージェントのフィードバックが収集済み
-- 統合レポートが作成済み
-- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
-- レビュー結果がドキュメントとして保存済み
-
-## 注意事項
-
-- レビューは「変更を楽に安全にできる」コードを維持するための協調的な活動
-- TDD サイクルの遵守状況（テストが先に書かれているか）もレビュー観点に含める
-- セキュリティに関する指摘は重要度「高」として扱う
-
-## 関連スキル
-
-- `orchestrating-development` — 開発フェーズの全体ワークフロー
-- `developing-backend` — バックエンド TDD 開発
-- `developing-frontend` — フロントエンド TDD 開発
-- `git-commit` — レビュー結果の保存後のコミット
+---
+name: developing-review
+description: 開発成果物のマルチパースペクティブレビューを実施。XP エージェント（プログラマー、テスター、アーキテクト、テクニカルライター、ユーザー代表）を並列起動し、コード品質・テスト品質・設計整合性・ドキュメント品質・利用者視点からフィードバックを収集・統合する。「コードレビューして」「PR をレビューして」「実装をチェックして」「テストコードをレビューして」「この変更をレビューしてほしい」「コードの品質を確認して」といった場面で発動する。開発成果物に対するレビュー依頼があれば積極的に使用すること。
+---
+
+# 開発成果物レビュー
+
+開発フェーズの成果物（プロダクションコード、テストコード、PR、リファクタリング結果など）を複数の XP エージェントで並列レビューし、多角的なフィードバックを統合する。
+
+## レビューの価値
+
+コードレビューは単なるバグ発見の手段ではない。設計の妥当性、テストの十分性、将来の変更容易性、ドキュメントとの整合性、そして実際のユーザーにとっての価値を同時に検証することで、「変更を楽に安全にできて役に立つソフトウェア」を維持する。
+
+## レビューエージェント
+
+| エージェント | 視点 | 着眼点 |
+|:---|:---|:---|
+| `xp-programmer` | コード品質 | SOLID 原則、DRY、命名、可読性、TDD サイクルの遵守、シンプルな設計 |
+| `xp-tester` | テスト品質 | テストカバレッジ、境界値、エッジケース、テストの信頼性、テストピラミッドのバランス |
+| `xp-architect` | 設計整合性 | アーキテクチャとの整合、依存関係の方向、変更容易性、技術的負債の蓄積 |
+| `xp-technical-writer` | ドキュメント品質 | API ドキュメント、コメントの適切さ、README の更新必要性、機能の理解しやすさ |
+| `xp-user-representative` | 利用者視点 | 実装された機能がユーザーの期待に合っているか、業務フローとの整合、使い勝手 |
+
+## レビュー対象の判定
+
+ユーザーのリクエストに応じてレビュー範囲を決定する。
+
+| リクエスト | レビュー範囲 |
+|:---|:---|
+| 「PR をレビュー」 | `git diff` で変更差分を取得 |
+| 「このファイルをレビュー」 | 指定ファイルの全体 |
+| 「最近の変更をレビュー」 | `git log` + `git diff` で直近の変更を取得 |
+| 「実装をレビュー」 | 指定された機能に関連するファイル群 |
+
+## レビューワークフロー
+
+### 1. レビュー対象の収集
+
+レビュー対象のコードを特定し、変更内容を把握する。
+
+- PR の場合: `git diff` でベースブランチとの差分を取得
+- ファイル指定の場合: 指定ファイルと関連ファイルを読み取る
+- 関連するテストファイル、設計ドキュメントも収集する
+
+### 2. エージェントの並列起動
+
+Agent ツールを使い、5 つのエージェントを **同一メッセージで並列起動** する。各エージェントには以下を指示する。
+
+```
+あなたは {エージェント名} です。
+.claude/agents/{エージェント名}.md の定義に従ってレビューしてください。
+
+## レビュー対象
+{変更差分 / ファイル内容}
+
+## 関連コンテキスト
+{関連する設計ドキュメント、テストファイル、ユーザーストーリー}
+
+## レビュー観点
+{エージェント固有の着眼点}
+
+## 出力形式
+以下の形式でフィードバックを返してください：
+
+### 評価サマリー
+（1-2 文で全体評価）
+
+### 良い点
+- （具体的に）
+
+### 改善提案
+- 【重要度: 高/中/低】（ファイル:行番号）（具体的な改善提案と理由）
+
+### 懸念事項
+- （潜在的なバグ、セキュリティリスク、パフォーマンス問題など）
+
+### スコープ外の発見
+- （レビュー対象外だが報告すべき問題）
+```
+
+#### Agent ツールが利用できない場合のフォールバック
+
+Agent ツールが利用できない環境では、5 つの視点を逐次的にシミュレートする。各エージェントの定義ファイル（`.claude/agents/{エージェント名}.md`）を読み、その視点でレビューを順次実施する。出力形式は同一のテンプレートに従う。
+
+### 3. フィードバックの統合
+
+全エージェントのフィードバックを受け取った後、以下の形式で統合レポートを作成する。
+
+```markdown
+## コードレビュー結果
+
+### レビュー対象
+- {ファイル名 / PR 番号}
+
+### 総合評価
+（全エージェントの評価を統合した 2-3 文の評価）
+
+### 改善提案（重要度順）
+
+#### 高（マージ前に対応すべき）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+#### 中（対応推奨）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+#### 低（改善の余地あり）
+| # | 提案 | 箇所 | 指摘元 | 理由 |
+|---|------|------|--------|------|
+
+### 矛盾事項
+
+複数エージェントの指摘が相反する場合、ここに記載する。
+
+| # | 視点 A | 視点 B | 論点 | 推奨判断 |
+|---|--------|--------|------|----------|
+
+### エージェント別フィードバック詳細
+
+<details>
+<summary>xp-programmer（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-tester（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-architect（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-technical-writer（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+
+<details>
+<summary>xp-user-representative（高: N / 中: N / 低: N）</summary>
+（フィードバック全文）
+</details>
+```
+
+### 4. 改善アクションの提案
+
+重要度「高」の指摘は具体的な修正コードを提案する。修正を適用するかはユーザーの判断に委ねる。
+
+### 5. レビュー結果の保存
+
+統合レポートを `docs/review/{対象名}_review_{YYYYMMDD}.md` に保存する。過去のレビュー結果と比較できるようにし、改善のトレーサビリティを確保する。
+
+## レビュー完了条件
+
+以下をすべて満たした場合にレビュー完了とする。
+
+- 全エージェントのフィードバックが収集済み
+- 統合レポートが作成済み
+- 重要度「高」の指摘について対応方針（修正する / 許容する / 保留する）が決定済み
+- レビュー結果がドキュメントとして保存済み
+
+## 注意事項
+
+- レビューは「変更を楽に安全にできる」コードを維持するための協調的な活動
+- TDD サイクルの遵守状況（テストが先に書かれているか）もレビュー観点に含める
+- セキュリティに関する指摘は重要度「高」として扱う
+
+## 関連スキル
+
+- `orchestrating-development` — 開発フェーズの全体ワークフロー
+- `developing-backend` — バックエンド TDD 開発
+- `developing-frontend` — フロントエンド TDD 開発
+- `git-commit` — レビュー結果の保存後のコミット