@k2works/claude-code-booster 1.13.0 → 2.0.1

package/lib/assets/.claude/skills/analyzing-usecases/SKILL.md

@@ -1,87 +1,72 @@
 ---
 name: analyzing-usecases
-description: ユースケースとユーザーストーリーの作成を支援。ビジネスユースケースの抽出からシステムユースケースの定義まで。ユースケース分析やストーリー作成時に使用。
+description: 要件定義からユースケースとユーザーストーリーを体系的に作成。ビジネスユースケース→システムユースケース→ユーザーストーリーの順に導出し、トレーサビリティを維持する。「ユースケースを作成したい」「ユーザーストーリーを書きたい」「要件定義からストーリーを導出したい」「受け入れ基準を定義したい」といった場面で発動する。ユースケースとストーリーを構造的に紐づけることで、開発フェーズでの「なぜこの機能を作るのか」が常に追跡可能になる。
 ---
 
-# ユースケース・ユーザーストーリー作成支援
+# ユースケース・ユーザーストーリー作成
 
-要件定義からユースケースを抽出し、トレーサビリティを維持します。
+要件定義からユースケースを抽出し、ユーザーストーリーまで一貫したトレーサビリティを維持しながら作成する。
 
-## Instructions
+ビジネスユースケース→システムユースケース→ユーザーストーリーの 3 段階で具体化することで、「ビジネス要求」と「実装タスク」の間の論理的なつながりを保証する。
 
-### 1. 参照ドキュメント
+## 参照ドキュメントとテンプレート
 
-- @docs/reference/ユースケース作成ガイド.md - ユースケース作成の進め方
+| 種類 | パス | 備考 |
+|------|------|------|
+| ガイド | @docs/reference/ユースケース作成ガイド.md | ユースケース作成の進め方詳細 |
+| テンプレート | @docs/template/完全形式のユースケース.md | 編集禁止。参照のみ |
+| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
+| 成果物 | `docs/requirements/business_usecase.md` | ビジネスユースケース |
+| 成果物 | `docs/requirements/system_usecase.md` | システムユースケース |
+| 成果物 | `docs/requirements/user_story.md` | ユーザーストーリー |
 
-### 2. テンプレート
+## 作成の 3 ステップ
 
-- @docs/template/完全形式のユースケース.md - ユースケーステンプレート（**編集禁止**）
+### ステップ 1: ビジネスユースケース作成
 
-### 3. 入力
+要件定義からビジネスレベルのユースケースを抽出する。システムの詳細には踏み込まず、業務目標とアクターの関係を定義する。
 
-- @docs/requirements/requirements_definition.md - 要件定義
+- 要件定義のシステム外部環境（層 2）を起点にアクターとユースケースを識別する
+- アクターとユースケースの関係を PlantUML で図示する
 
-### 4. 成果物
+### ステップ 2: システムユースケース作成
 
-- @docs/requirements/business_usecase.md - ビジネスユースケース
-- @docs/requirements/system_usecase.md - システムユースケース
-- @docs/requirements/user_story.md - ユーザーストーリー
+ビジネスユースケースをシステム境界の視点で詳細化する。「システムが何を提供するか」を明確にする。
 
-### 5. 作業内容
+- ビジネスユースケースの各項目をシステムレベルに分解する
+- システム境界を明確にし、テンプレートの完全形式で記述する
 
-#### ビジネスユースケース作成
+### ステップ 3: ユーザーストーリー作成
 
-- 要件定義からビジネスユースケースを抽出
-- アクターとユースケースの関係を定義
+システムユースケースから開発可能な粒度のユーザーストーリーを導出する。
 
-#### システムユースケース作成
+- 「〜として、〜したい。なぜなら〜だからだ」の形式で記述する
+- 各ストーリーに受け入れ基準を定義する
+- ユースケースとの対応関係を明記してトレーサビリティを確保する
 
-- ビジネスユースケースを詳細化
-- システム境界を明確化
+## 途中から再開・更新
 
-#### ユーザーストーリー作成
+既存の成果物がある場合は、まず現在の状態を確認する。不足しているステップや更新が必要な部分のみを修正する。
 
-- システムユースケースからユーザーストーリーを導出
-- 受け入れ基準の定義
+**Example:**
 
-#### トレーサビリティ維持
-
-- ユースケースとユーザーストーリー間のトレーサビリティを確保
-
-### 6. 注意事項
-
-- **前提条件**: @docs/requirements/requirements_definition.md が存在すること
-- **制限事項**:
-  - テンプレート @docs/template/完全形式のユースケース.md は絶対に編集しないこと
-  - user_story.md にはユーザーストーリーのみ記述する
-  - リリース計画とイテレーション計画は別途作成する
-- **推奨事項**: ユースケースとユーザーストーリーでトレーサビリティを維持する
-
-### 7. 記述ルール
-
-タスク項目などは一行開けて記述する。
-
-OK:
-
-```markdown
-**受入条件**:
-
-- [ ] ビジネスユースケースが作成されている
-- [ ] ユーザーストーリーが作成されている
 ```
-
-NG:
-
-```markdown
-**受入条件**:
-- [ ] ビジネスユースケースが作成されている
-- [ ] ユーザーストーリーが作成されている
+ユーザー: 「ビジネスユースケースは作った。ユーザーストーリーを書きたい」
+回答: ステップ 2（システムユースケース）の存在を確認する。
+      未作成ならステップ 2 から開始。作成済みならステップ 3 に進む。
+      既存のビジネスユースケースのアクターとユースケースを起点に、
+      システムユースケースを詳細化してからユーザーストーリーを導出する。
 ```
 
-## Examples
+## 注意事項
+
+- 入力の `requirements_definition.md` が存在しない場合は `analyzing-requirements` を先に実行する
+- テンプレートは編集禁止。参照のみとし、成果物は別ファイルに作成する
+- `user_story.md` にはユーザーストーリーのみ記述する。リリース計画・イテレーション計画は `planning-releases` で別途作成する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
 
-### 要件定義に基づくユースケース作成
+## 関連スキル
 
-1. @docs/requirements/requirements_definition.md を読み込む
-2. @docs/reference/ユースケース作成ガイド.md に基づいてユースケースを作成
-3. ビジネスユースケース → システムユースケース → ユーザーストーリーの順に作成
+- `analyzing-requirements` — 前段の要件定義（RDRA 2.0）
+- `planning-releases` — 後続のリリース・イテレーション計画
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

package/lib/assets/.claude/skills/creating-adr/SKILL.md

@@ -1,32 +1,20 @@
 ---
 name: creating-adr
-description: Architecture Decision Record の作成を支援。技術的意思決定の記録フォーマットとベストプラクティス。アーキテクチャ上の意思決定を記録する際に使用。
+description: Architecture Decision Record（ADR）の作成・管理を支援。技術的意思決定の背景・決定・影響をテンプレートに沿って記録する。「ADR を作成したい」「アーキテクチャの決定を記録したい」「技術選定の理由を残したい」「設計判断を文書化したい」といった場面で発動する。意思決定の経緯を記録することで、将来「なぜこの技術を選んだのか」が追跡可能になり、同じ議論の繰り返しを防ぐ。
 ---
 
-# ADR (Architecture Decision Record) 作成支援
+# ADR 作成
 
-アーキテクチャ決定記録（ADR）の作成・管理を支援します。
+アーキテクチャ決定記録（ADR）を作成・管理する。技術的意思決定のコンテキスト・決定内容・影響を構造化して記録する。
 
-## Instructions
+ADR の価値は「決定そのもの」ではなく「なぜその決定に至ったか」を残すこと。代替案と却下理由を含めることで、将来の見直し時に同じ検討を繰り返さずに済む。
 
-### 1. ADR ファイル構造
-
-ADR は `docs/adr/` ディレクトリに以下の命名規則で保存：
-
-```
-docs/adr/
-├── 001-backend-architecture-pattern.md
-├── 002-backend-framework.md
-├── 003-frontend-framework.md
-└── 004-database.md
-```
-
-### 2. ADR テンプレート
+## ADR テンプレート
 
 ```markdown
 # ADR-NNN: タイトル
 
-簡潔な説明（1行で決定内容を要約）。
+簡潔な説明（1 行で決定内容を要約）。
 
 日付: YYYY-MM-DD
 
@@ -75,7 +63,7 @@ docs/adr/
 - 関連 ADR: ADR-XXX
 ```
 
-### 3. ステータスの種類
+## ステータスの種類
 
 | ステータス | 説明 |
 |-----------|------|
@@ -84,32 +72,42 @@ docs/adr/
 | 廃止 | 無効になった決定 |
 | 置換 | 別の ADR で置き換えられた |
 
-### 4. 注意事項
+## 作成の進め方
 
-- **採番規則**: ADR 番号は 001 から連番で管理。既存の最大番号 + 1 で採番
-- **ファイル名**: `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
-- **配置場所**: 必ず `docs/adr/` ディレクトリに配置
-- **ドキュメント更新**: 新規 ADR 作成時は `docs/index.md` と `mkdocs.yml` も更新が必要
-- **コミット禁止**: ユーザーの指示があるまでコミットしない
+### 新規 ADR の作成
 
-### 5. ベストプラクティス
+1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認する
+2. 次の連番でテンプレートに基づいて ADR を作成する
+3. `docs/index.md` と `mkdocs.yml` を更新する
 
-1. **簡潔な要約**: タイトル直下に 1 行で決定内容を要約する
-2. **コンテキストの明確化**: なぜこの決定が必要なのか背景を説明
-3. **代替案の記録**: 検討した選択肢と却下理由を残す
-4. **影響の両面記載**: ポジティブ・ネガティブ両方の影響を記載
-5. **コンプライアンス項目**: 決定が守られていることを確認する方法を記載
+### 既存設計からの ADR 抽出
 
-## Examples
+1. アーキテクチャ設計ドキュメントを読み込む
+2. 主要な技術的意思決定を識別する
+3. 各決定を ADR として記録する
 
-### 新しい ADR の作成
+## 途中から再開・更新
 
-1. `docs/adr/` ディレクトリ内の既存 ADR の最大番号を確認
-2. 次の連番でテンプレートに基づいて ADR を作成
-3. `docs/index.md` と `mkdocs.yml` を更新
+既存の ADR がある場合は `docs/adr/` の内容を確認する。ステータス変更や新規 ADR の追記のみを行う。
 
-### 既存設計からの ADR 抽出
+**Example:**
 
-1. アーキテクチャ設計ドキュメントを読み込む
-2. 主要な技術的意思決定を識別
-3. 各決定を ADR として記録
+```
+ユーザー: 「フレームワークを変更する決定を記録したい」
+回答: docs/adr/ の最大番号を確認し、次の連番で ADR を作成する。
+      既存の関連 ADR があればステータスを「置換」に変更し、
+      新しい ADR の「コンテキスト」に経緯を記載する。
+```
+
+## 注意事項
+
+- 採番は `001` から連番。ファイル名は `NNN-kebab-case-title.md` 形式（例: `006-cache-strategy.md`）
+- 配置場所は必ず `docs/adr/`。新規作成時は `docs/index.md` と `mkdocs.yml` も更新する
+- ユーザーの指示があるまでコミットしない
+- コンテキストの明確化・代替案の記録・影響の両面記載・コンプライアンス項目を必ず含める
+
+## 関連スキル
+
+- `analyzing-architecture` — アーキテクチャ設計（ADR の主な発生源）
+- `analyzing-tech-stack` — 技術スタック選定（ADR として記録すべき決定）
+- `git-commit` — ADR 作成後のコミット

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

@@ -1,37 +1,39 @@
 ---
 name: developing-backend
-description: バックエンド開発の TDD ワークフロー。Red-Green-Refactor サイクル、インサイドアウトアプローチ、品質チェックリスト。Java/Spring Boot のバックエンド実装時に使用。
+description: バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
 ---
 
-# バックエンド開発ガイド
+# バックエンド開発
 
-TDD サイクルに従ったバックエンド開発を支援します。
+TDD サイクルに従いバックエンドを開発する。インサイドアウトアプローチ（データ層→ドメイン層→API 層）で、内側から外側へ段階的に構築する。
 
-## Instructions
+インサイドアウトの利点は、ドメインロジックのテストが外部依存なしで書けること。テストの実行速度が速く、フィードバックループを短く保てる。
 
-### 1. 参照ドキュメント
+## 参照ドキュメント
 
-- @docs/reference/コーディングとテストガイド.md - ワークフロー
-- @docs/design/architecture_backend.md - バックエンドアーキテクチャ
-- @docs/design/data-model.md - データモデル
-- @docs/design/domain-model.md - ドメインモデル
-- @docs/design/tech_stack.md - 技術スタック
-- @docs/design/test_strategy.md - テスト戦略
+| 種類 | パス |
+|------|------|
+| ワークフロー | @docs/reference/コーディングとテストガイド.md |
+| アーキテクチャ | @docs/design/architecture_backend.md |
+| データモデル | @docs/design/data-model.md |
+| ドメインモデル | @docs/design/domain-model.md |
+| 技術スタック | @docs/design/tech_stack.md |
+| テスト戦略 | @docs/design/test_strategy.md |
 
-### 2. TDD サイクルの実践
+## TDD サイクル
 
-Red-Green-Refactor サイクルを厳密に実行：
+10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
 
-1. **Red フェーズ**: 失敗するテストを最初に書く
-2. **Green フェーズ**: テストを通す最小限のコードを実装
-3. **Refactor フェーズ**: 重複を除去し設計を改善
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
 
-### 3. アプローチ戦略の選択
+## アプローチ
 
-- **インサイドアウト**: データ層から開始し上位層へ展開（推奨）
-- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装
+- **インサイドアウト**（推奨）: データ層から開始し上位層へ展開する
+- **アウトサイドイン**: API から開始しドメインロジックを段階的に実装する
 
-### 4. テストコマンド
+## テストコマンド
 
 ```bash
 # 全テスト実行
@@ -44,20 +46,18 @@ cd apps/backend && ./gradlew test --tests "UserServiceTest"
 cd apps/backend && ./gradlew jacocoTestReport
 ```
 
-### 5. API ドキュメント
-
-バックエンドには Swagger UI が組み込まれています。
+## API ドキュメント
 
 ```bash
 # バックエンドを起動
 cd apps/backend && ./gradlew bootRun
-
 # Swagger UI: http://localhost:8080/swagger-ui.html
 # OpenAPI JSON: http://localhost:8080/v3/api-docs
-# OpenAPI YAML: http://localhost:8080/api-docs.yaml
 ```
 
-### 6. 品質チェックリスト
+## 品質チェックリスト
+
+コミット前に必ず確認する。
 
 - [ ] すべてのテストがパス
 - [ ] ESLint/コンパイラの警告がゼロ
@@ -65,42 +65,36 @@ cd apps/backend && ./gradlew bootRun
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
 
-### 7. コンテキスト管理
-
-長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
+## 途中から再開
 
-**`/compact` を実施するタイミング**:
+開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
 
-- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
-- ユーザーストーリー 1 件の実装が完了したとき
-- コミット完了後、次のタスクに着手する前
-- テストスイートの実行と結果確認が完了したとき
+**Example:**
 
-**運用ルール**:
-
-1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
-2. `/compact` 実施後、次のタスクの作業を継続する
-3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+```
+ユーザー: 「ユーザー認証の Entity と Repository は実装済み。Service 層に進みたい」
+回答: 既存テストを実行して Green 状態を確認する。
+      Service 層の失敗するテスト（Red）を書いてから実装に進む。
+      Repository の戻り値を使った Service のビジネスロジックをテストする。
+```
 
-### 8. 注意事項
+## コンテキスト管理
 
-- **前提条件**: Java/Gradle のテスト環境が設定済みであること
-- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
-- **推奨事項**: コミット前に必ず品質チェックリストを実行
-- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
 
-## Examples
+- TDD サイクルを数回繰り返した後、ユーザーストーリー完了時、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
 
-### 新機能の TDD 実装
+## 注意事項
 
-1. 失敗するテストを書く（Red）
-2. テストを通す最小限のコードを実装（Green）
-3. 重複を排除し設計を改善（Refactor）
-4. 品質チェックリストを実行してコミット
+- Java/Gradle のテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+- TODO 駆動開発でタスクを細かく分割し、Rule of Three で 3 回同じコードが現れたらリファクタリングする
 
-### ベストプラクティス
+## 関連スキル
 
-1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
-2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
-3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
-4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
+- `developing-frontend` — フロントエンド TDD 開発
+- `orchestrating-development` — 開発フェーズ全体のワークフロー
+- `git-commit` — Conventional Commits 準拠のコミット

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

@@ -1,36 +1,38 @@
 ---
 name: developing-frontend
-description: フロントエンド開発の TDD ワークフロー。Red-Green-Refactor サイクル、アウトサイドインアプローチ、コンポーネント設計。React/TypeScript のフロントエンド実装時に使用。
+description: フロントエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとアウトサイドインアプローチで品質の高い UI を実装する。「フロントエンドを実装したい」「画面を作りたい」「コンポーネントを追加したい」「フロントエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、UI の振る舞いを自動テストで保証し、安全なリファクタリングを可能にする。
 ---
 
-# フロントエンド開発ガイド
+# フロントエンド開発
 
-TDD サイクルに従ったフロントエンド開発を支援します。
+TDD サイクルに従いフロントエンドを開発する。アウトサイドインアプローチ（UI 層→ロジック層→データ層）で、ユーザー視点から内側へ段階的に構築する。
 
-## Instructions
+アウトサイドインの利点は、ユーザーが実際に操作する画面から始めるため、不要な機能を作らずに済むこと。テストがユーザーの振る舞いに基づくため、実装の詳細に依存しにくい。
 
-### 1. 参照ドキュメント
+## 参照ドキュメント
 
-- @docs/reference/コーディングとテストガイド.md - ワークフロー
-- @docs/design/architecture_frontend.md - フロントエンドアーキテクチャ
-- @docs/design/ui-design.md - UI 設計
-- @docs/design/tech_stack.md - 技術スタック
-- @docs/design/test_strategy.md - テスト戦略
+| 種類 | パス |
+|------|------|
+| ワークフロー | @docs/reference/コーディングとテストガイド.md |
+| アーキテクチャ | @docs/design/architecture_frontend.md |
+| UI 設計 | @docs/design/ui-design.md |
+| 技術スタック | @docs/design/tech_stack.md |
+| テスト戦略 | @docs/design/test_strategy.md |
 
-### 2. TDD サイクルの実践
+## TDD サイクル
 
-Red-Green-Refactor サイクルを厳密に実行：
+10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
 
-1. **Red フェーズ**: 失敗するテストを最初に書く
-2. **Green フェーズ**: テストを通す最小限のコードを実装
-3. **Refactor フェーズ**: 重複を除去し設計を改善
+1. **Red**: 失敗するテストを最初に書く
+2. **Green**: テストを通す最小限のコードを実装する
+3. **Refactor**: 重複を除去し設計を改善する
 
-### 3. アプローチ戦略の選択
+## アプローチ
 
-- **アウトサイドイン**: UI から開始しロジックを段階的に実装（推奨）
-- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開
+- **アウトサイドイン**（推奨）: UI から開始しロジックを段階的に実装する
+- **インサイドアウト**: ユーティリティ/hooks から開始し上位層へ展開する
 
-### 4. テストコマンド
+## テストコマンド
 
 ```bash
 # 全テスト実行
@@ -46,7 +48,9 @@ cd apps/frontend && npm run test:coverage
 cd apps/frontend && npm run test:e2e
 ```
 
-### 5. 品質チェックリスト
+## 品質チェックリスト
+
+コミット前に必ず確認する。
 
 - [ ] すべてのテストがパス
 - [ ] ESLint の警告がゼロ
@@ -54,43 +58,36 @@ cd apps/frontend && npm run test:e2e
 - [ ] 単一の論理的作業単位を表現
 - [ ] コミットメッセージが変更内容を明確に説明
 
-### 6. コンテキスト管理
-
-長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに `/compact` を実施してコンテキストを圧縮する。
-
-**`/compact` を実施するタイミング**:
+## 途中から再開
 
-- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
-- コンポーネント 1 件の実装が完了したとき
-- コミット完了後、次のタスクに着手する前
-- テストスイートの実行と結果確認が完了したとき
+開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
 
-**運用ルール**:
+**Example:**
 
-1. `/compact` 実施前に、現在の作業状態と次のタスクをメモとして出力する
-2. `/compact` 実施後、次のタスクの作業を継続する
-3. 大規模なユーザーストーリーでは、サブタスクごとに `/compact` を検討する
+```
+ユーザー: 「ログイン画面のコンポーネントは作った。バリデーションを追加したい」
+回答: 既存テストを実行して Green 状態を確認する。
+      バリデーションの失敗するテスト（Red）を書いてから実装に進む。
+      ユーザーが不正な入力をした場合のエラー表示をテストする。
+```
 
-### 7. 注意事項
+## コンテキスト管理
 
-- **前提条件**: Node.js/npm のテスト環境が設定済みであること
-- **制限事項**: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
-- **推奨事項**: コミット前に必ず品質チェックリストを実行
-- 作業完了後に対象のイテレーション @docs/development/iteration_plan-N.md の進捗を更新する
+タスクの区切りごとに `/compact` を実施して Context limit reached エラーを回避する。
 
-## Examples
+- TDD サイクルを数回繰り返した後、コンポーネント完了時、コミット完了後に実施する
+- `/compact` 前に現在の作業状態と次のタスクをメモとして出力する
 
-### 新コンポーネントの TDD 実装
+## 注意事項
 
-1. 失敗するテストを書く（Red）
-2. テストを通す最小限のコードを実装（Green）
-3. 重複を排除し設計を改善（Refactor）
-4. 品質チェックリストを実行してコミット
+- Node.js/npm のテスト環境が設定済みであること（前提条件）
+- TDD の三原則を厳密に守る。テストなしでプロダクションコードを書かない
+- コミット前に必ず品質チェックリストを実行する
+- 作業完了後に対象の @docs/development/iteration_plan-N.md の進捗を更新する
+- コンポーネントは単一責任の原則に従い小さく保つ。TODO 駆動で分割し、Rule of Three でリファクタリングする
 
-### ベストプラクティス
+## 関連スキル
 
-1. **TODO 駆動開発**: タスクを細かい TODO に分割してから実装開始
-2. **小さなサイクル**: Red-Green-Refactor を 10-15 分で完了させる
-3. **継続的コミット**: 各サイクル完了時に動作する状態でコミット
-4. **Rule of Three**: 同じコードが 3 回現れたらリファクタリング
-5. **コンポーネント分割**: 単一責任の原則に従いコンポーネントを小さく保つ
+- `developing-backend` — バックエンド TDD 開発
+- `orchestrating-development` — 開発フェーズ全体のワークフロー
+- `git-commit` — Conventional Commits 準拠のコミット