@k2works/claude-code-booster 4.12.0 → 4.13.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -217,6 +217,8 @@ Claude Code をより効率的に使うための基本設定テンプレート
|
|
|
217
217
|
│ ├── tracking-progress/SKILL.md
|
|
218
218
|
│ ├── syncing-github-project/SKILL.md
|
|
219
219
|
│ ├── planning-releases/SKILL.md
|
|
220
|
+
│ ├── opening-iteration/SKILL.md
|
|
221
|
+
│ ├── closing-iteration/SKILL.md
|
|
220
222
|
│ ├── creating-development-strategy/SKILL.md
|
|
221
223
|
│ ├── creating-journal/SKILL.md
|
|
222
224
|
│ ├── creating-slides/SKILL.md
|
|
@@ -20,7 +20,7 @@ description: イテレーション（IT）を漏れなくクローズするた
|
|
|
20
20
|
|
|
21
21
|
順序には理由がある。レビュー指摘を反映してから品質ゲートを固め（ローカル＋CI の両方で緑を確認）、実績が確定してからふりかえり・報告書を書き、ドキュメントが整ってから GitHub とインデックスに同期する。上から順に実施する。
|
|
22
22
|
|
|
23
|
-
> ステップ番号は 7 だが、品質ゲート（ステップ 2）にはローカル検証（2
|
|
23
|
+
> ステップ番号は 7 だが、品質ゲート（ステップ 2）にはローカル検証（2）・CI 確認（2.5）・SonarQube 品質ゲート（2.6）が含まれる。ローカル緑だけでは不十分で、CI が緑かつ SonarQube の Quality Gate が PASS であって初めて品質ゲートを通過とみなす。
|
|
24
24
|
|
|
25
25
|
### ステップ 1: マルチパースペクティブレビュー（`developing-review`）
|
|
26
26
|
|
|
@@ -36,7 +36,7 @@ description: イテレーション（IT）を漏れなくクローズするた
|
|
|
36
36
|
|
|
37
37
|
- 全テストが green（単体・統合・HTTP フロー / E2E）
|
|
38
38
|
- Lint・フォーマットがクリーン（このプロジェクトでは `cargo clippy --workspace --all-targets -- -D warnings` と `cargo fmt --check`）
|
|
39
|
-
-
|
|
39
|
+
- カバレッジを計測し目標との差分を把握する（静的解析の合否判定はステップ 2.6 の SonarQube 品質ゲートで確定する）
|
|
40
40
|
- ゲートを通らない場合はクローズを止め、修正してから再度ここに戻る
|
|
41
41
|
- **CI と同じツールチェーンで検証する**: ローカルの clippy が古いと CI（`.github/workflows/rust-ci.yml` は `dtolnay/rust-toolchain@stable` を使用）だけが新 lint で落ちる。ローカルの stable が CI より古い可能性があるため、`rustup update stable` してから `cargo +stable clippy --workspace --all-targets -- -D warnings` / `cargo +stable fmt --check` を実行し、ツールチェーンの乖離による「ローカル緑・CI 赤」を防ぐ
|
|
42
42
|
|
|
@@ -48,6 +48,21 @@ description: イテレーション（IT）を漏れなくクローズするた
|
|
|
48
48
|
- push 前にクローズ作業を進める場合も、過去コミットで CI が赤のまま放置されていないかを必ず確認する（赤を「完了」と宣言しない）
|
|
49
49
|
- 修正後は再 push し、CI が緑に戻ることを確認してからクローズを確定する
|
|
50
50
|
|
|
51
|
+
### ステップ 2.6: SonarQube 品質ゲート（`operating-qt`）
|
|
52
|
+
|
|
53
|
+
テスト・Lint が緑でも、静的解析の品質基準（Bug・Vulnerability・Code Smell・重複・カバレッジ）を満たしていなければクローズしない。`operating-qt` で SonarQube スキャンを実行し、**Quality Gate が PASS であること**を確定させる。
|
|
54
|
+
|
|
55
|
+
- **前提**: ローカル SonarQube が起動済み（`npx gulp sonar-local:status`）で `.env` に有効な `SONAR_TOKEN` が設定されていること。未起動なら `npx gulp sonar-local:setup`
|
|
56
|
+
- **カバレッジ連携**: スキャン前に対象言語のカバレッジレポートを生成する（例: Go は `go test -coverprofile=coverage.out -covermode=atomic ./...`、`sonar-project.properties` の `sonar.*.coverage.reportPaths` で連携）
|
|
57
|
+
- **実行**: `npx gulp sonar-local:scan` → `npx gulp sonar-local:gate`（または一連の `npx gulp sonar-local:check`）
|
|
58
|
+
- **合格基準**（[テスト戦略](../../../docs/design/test_strategy.md) の Quality Gate に準拠）:
|
|
59
|
+
- Quality Gate: **PASS**
|
|
60
|
+
- Bug: **0** / Vulnerability: **0**
|
|
61
|
+
- 重複率: **3% 未満**
|
|
62
|
+
- Code Smell: 可能な限り **0**（残す場合は方針を明記）
|
|
63
|
+
- カバレッジ: 新規コード 80% 以上（ドメイン層は 90% を目標）
|
|
64
|
+
- **不合格なら**: `npx gulp sonar-local:issues` で指摘を特定し、修正してステップ 2 に戻る。ゲートが PASS になるまでクローズを止める
|
|
65
|
+
|
|
51
66
|
### ステップ 3: 進捗反映（`tracking-progress --update`）
|
|
52
67
|
|
|
53
68
|
実績データ（git ログ・テスト結果・カバレッジ）を集計し、計画ドキュメントを実績で更新する。
|
|
@@ -95,8 +110,9 @@ KPT（Keep / Problem / Try）で振り返り、`docs/development/retrospective-N
|
|
|
95
110
|
すべて満たしたらイテレーションはクローズ済みとみなす。
|
|
96
111
|
|
|
97
112
|
- [ ] `developing-review` 実施・レポート保存・高優先度対応（または方針明記）
|
|
98
|
-
- [ ] 全テスト green・Lint/フォーマットクリーン（CI
|
|
113
|
+
- [ ] 全テスト green・Lint/フォーマットクリーン（CI と同じツールチェーンで確認）・カバレッジ把握
|
|
99
114
|
- [ ] **CI が緑**（`gh run list` で対象ブランチの最新実行が success・赤なら修正して再確認）
|
|
115
|
+
- [ ] **SonarQube Quality Gate が PASS**（Bug 0・Vulnerability 0・重複 3% 未満・Code Smell 方針明記・カバレッジ目標達成）
|
|
100
116
|
- [ ] `release_plan.md` / `iteration_plan-N.md` を実績で更新
|
|
101
117
|
- [ ] `retrospective-N.md`（KPT）作成
|
|
102
118
|
- [ ] `iteration_report-N.md`（完了報告書）作成
|
|
@@ -112,7 +128,8 @@ KPT（Keep / Problem / Try）で振り返り、`docs/development/retrospective-N
|
|
|
112
128
|
|
|
113
129
|
- **順序を守る**: レビュー指摘の反映前に報告書を書くと、報告書が実態とずれる。品質ゲートを通す前に GitHub をクローズすると、緑でない成果を「完了」と宣言してしまう
|
|
114
130
|
- **抜けやすいのはステップ 5-7**（報告書・GitHub・ドキュメント）。実装とレビューで達成感が出た後の事務作業のため後回しにされやすい。チェックリストで機械的に確認する
|
|
115
|
-
- **ローカル緑を CI 緑と混同しない**（ステップ 2.5）。ローカルのツールチェーンが CI
|
|
131
|
+
- **ローカル緑を CI 緑と混同しない**（ステップ 2.5）。ローカルのツールチェーンが CI より古いと、新しい lint がローカルをすり抜けて CI だけ赤になる。クローズ確定前に `gh run` で CI の実結果を必ず確認し、赤なら緑に戻す
|
|
132
|
+
- **品質ゲートは「テスト緑」で終わりにしない**（ステップ 2.6）。テストと Lint が緑でも SonarQube の Quality Gate（Bug・脆弱性・重複・カバレッジ・Code Smell）が赤ならクローズしない。スキャン→ゲート PASS までを品質ゲートの完了条件とする
|
|
116
133
|
- **正直さを優先する**: 未達・スコープ調整・DoD の未チェック項目は隠さず記録する。次イテレーションの計画精度とベロシティの信頼性はこの正直さに依存する
|
|
117
134
|
|
|
118
135
|
## 関連スキル
|
|
@@ -1,25 +1,36 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: creating-development-strategy
|
|
3
|
-
description: 開発戦略ドキュメント（docs/development/development_strategy.md
|
|
3
|
+
description: 開発戦略ドキュメント（docs/development/development_strategy.md）の作成・更新を支援。イテレーション計画（planning-releases でのイテレーション作成）を前提に、イテレーション群を序盤・中盤・終盤の局面に分け、各局面で採用する TDD アプローチ（アウトサイドイン / インサイドアウト）、ウォーキングスケルトンの基盤化、イテレーションのデモ項目を受け入れ基準（E2E / 受け入れテスト）とする方針、設計ドキュメント整合方針を定義する。「開発戦略を作りたい」「開発の進め方を局面ごとに決めたい」「アウトサイドインとインサイドアウトをどう使い分けるか整理したい」「ウォーキングスケルトンの方針を文書化したい」「デモ項目を受け入れ基準にする方針を決めたい」「イテレーションと設計ドキュメントの整合方針を決めたい」といった場面で必ず発動する。リリース計画・イテレーション計画を作成した後、開発フェーズに着手する前に開発戦略を定めておくことで、局面が変わってもアーキテクチャと品質の一貫性を保った開発を進められる。特定の言語・フレームワークに依存しない汎用スキルであり、参照元・コマンド・テスト構成は対象プロジェクトの実構成に合わせて解決する。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# 開発戦略作成
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
計画済みのイテレーション群を **序盤・中盤・終盤** の局面に分け、各局面で採用する TDD アプローチと横断的な進め方を定義する開発戦略ドキュメントを作成する。
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
本スキルは **イテレーション計画の作成（`planning-releases`）を前提** とする。開発戦略は個々のイテレーション計画の上位に位置し、「どのイテレーションでどちらのアプローチを採るか」「イテレーションの完了をどう受け入れ判定するか」という戦略レイヤーを明文化する。個々の TDD サイクルは対象プロジェクトのコーディング/テストガイドに従うため、本戦略はその上位で「テストの入口をどこに置き、レイヤーをどの順で貫通するか」を局面ごとに決める。局面が切り替わってもアーキテクチャ・品質・ユビキタス言語の一貫性を保つことが狙い。
|
|
11
|
+
|
|
12
|
+
本スキルは特定の言語・フレームワーク・アーキテクチャに依存しない。参照するガイド名・ディレクトリ・ビルド/テストコマンド・テスト構成は、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。
|
|
11
13
|
|
|
12
14
|
## 成果物
|
|
13
15
|
|
|
14
16
|
- 配置場所: `docs/development/development_strategy.md`
|
|
15
|
-
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
18
|
-
-
|
|
17
|
+
- 正となる参照元（存在するものを使う。無いものは前提にしない）:
|
|
18
|
+
- **イテレーション構成・デモ項目・受け入れ基準**: 各 `docs/development/iteration_plan-N.md`（**主たる入力**。イテレーション計画を前提とする）
|
|
19
|
+
- **イテレーション × ユーザーストーリーのマクロ配分**: `docs/development/release_plan.md`（あれば SSoT。無ければ計画済みイテレーションから局面を導く）
|
|
20
|
+
- **TDD アプローチ・手順・品質基準**: 対象プロジェクトのコーディング/テストガイド（例: `docs/reference/コーディングとテストガイド.md`）
|
|
21
|
+
- **テスト種別・受け入れ/E2E 方針**: 対象プロジェクトのテスト戦略（例: `docs/design/test_strategy.md`）
|
|
22
|
+
- **画面遷移・ナビゲーション**（UI を持つ場合）: UI 設計（例: `docs/design/ui_design.md`）
|
|
23
|
+
|
|
24
|
+
## 前提: イテレーション計画
|
|
25
|
+
|
|
26
|
+
開発戦略は計画済みのイテレーションを局面へ振り分ける。着手前に以下を満たすこと。
|
|
19
27
|
|
|
20
|
-
|
|
28
|
+
- `planning-releases` で少なくとも当面のイテレーション（最低でも序盤の 1-2 IT）が計画され、各 `iteration_plan-N.md` に **対象ユーザーストーリー** と **デモ項目（イテレーションレビューで実演するシナリオ）** が定義されていること。
|
|
29
|
+
- 全イテレーションが未計画でも、確定済みのイテレーション範囲で局面を割り当ててよい。未計画分は「局面割り当ての暫定案」として記し、計画確定時に追従する。
|
|
21
30
|
|
|
22
|
-
|
|
31
|
+
## 局面戦略の基本形
|
|
32
|
+
|
|
33
|
+
局面ごとに変えるのは **テストの入口** と **レイヤー貫通の順序** のみ。Red-Green-Refactor サイクルそのものは全局面で不変とする。局面数・順序はプロジェクトの性質（中核ドメインの複雑さ）に応じて調整してよい。
|
|
23
34
|
|
|
24
35
|
| 局面 | 対象イテレーション | 主アプローチ | 狙い |
|
|
25
36
|
| :--- | :--- | :--- | :--- |
|
|
@@ -29,19 +40,29 @@ description: 開発戦略ドキュメント（docs/development/development_strat
|
|
|
29
40
|
|
|
30
41
|
### アプローチ選択の根拠
|
|
31
42
|
|
|
32
|
-
|
|
43
|
+
選択は対象プロジェクトの実装アプローチ選択フロー（コーディング/テストガイド）に対応づけて説明する。理由を書くことで、局面が機械的な区切りでなく論理的必然であることを示す。
|
|
33
44
|
|
|
34
45
|
- 序盤（アウトサイドイン）: API・基盤とも未実装 → UI/受け入れテストのニーズから API を導出し薄く貫通させるのが安全（「API 未実装 → アウトサイドイン活用」）。
|
|
35
46
|
- 中盤（インサイドアウト）: 複雑ドメインで貧血モデルを避けたい → データ層・ドメイン層の基盤を固めてから上位へ展開（「基盤未確立 → インサイドアウト推奨」）。
|
|
36
47
|
- 終盤（アウトサイドイン）: 基本実装済み × ドメイン複雑 → 既存集約を組み合わせ業務シナリオを受け入れテストで束ねる（「基本実装済み × 複雑 → アウトサイドイン推奨」）。
|
|
37
48
|
|
|
49
|
+
中核が単純な CRUD 中心で複雑ドメインを持たない場合は、中盤（インサイドアウト）を省略し序盤・終盤のアウトサイドイン 2 局面に簡素化してよい。
|
|
50
|
+
|
|
51
|
+
## デモ項目を受け入れ基準とする（局面横断）
|
|
52
|
+
|
|
53
|
+
イテレーション計画のデモ項目を、局面横断の受け入れ基準として位置づける。受け入れ/E2E テストはテストピラミッド上は最小でも、「業務価値が実際に成立するか」を担保する最終ゲートとして各 IT の DoD に組み込む。具体的なツールは対象プロジェクトに合わせる（UI があれば Playwright/Cypress 等の E2E、API 中心なら受け入れテスト/HTTP シナリオテスト）。
|
|
54
|
+
|
|
55
|
+
- **序盤**: 受け入れ/E2E テストの基盤をセットアップし、ウォーキングスケルトンの妥当性を担保する（UI を持つ場合は全ナビゲーション遷移、API 中心の場合は主要エンドポイントのスモーク）。
|
|
56
|
+
- **中盤・終盤**: 各 `iteration_plan-N.md` の **デモ項目をそのままパスする受け入れ/E2E テスト** を追加し、当該 IT の受け入れ基準とする。デモ項目を「操作/リクエストの系列」に翻訳してテスト化する。
|
|
57
|
+
- **判定**: 当該 IT のデモ項目テストがすべて green であることを DoD に含める。green でなければイテレーションはクローズしない。追加したテストは以降も実行し、既存デモ項目の回帰を防ぐ。
|
|
58
|
+
|
|
38
59
|
## 作成の進め方
|
|
39
60
|
|
|
40
|
-
1. **参照元を読む**:
|
|
41
|
-
2. **局面を割り当てる**:
|
|
42
|
-
3. **共通の TDD サイクル節を書く**: Red-Green-Refactor
|
|
43
|
-
4. **各局面の節を書く**:
|
|
44
|
-
5. **横断方針を書く**:
|
|
61
|
+
1. **参照元を読む**: コーディング/テストガイド（アプローチのシーケンス・品質基準・コミット規約）、計画済みの各 `iteration_plan-N.md`（対象 US・デモ項目）、あれば `release_plan.md`（マクロ配分）を読み込む。
|
|
62
|
+
2. **局面を割り当てる**: 計画済みイテレーションを局面へ振り分ける。基盤・入口の IT を序盤、複雑ドメイン中核の IT を中盤、例外・仕上げの IT を終盤とする。未計画分は暫定案とする。
|
|
63
|
+
3. **共通の TDD サイクル節を書く**: Red-Green-Refactor と品質チェック（対象プロジェクトの実ビルド/テストコマンド）、テスト種別とレイヤーの対応表を、実構成を確認して記載する。
|
|
64
|
+
4. **各局面の節を書く**: 目的・対象ユーザーストーリー・ワークフロー（アウトサイドイン/インサイドアウトのシーケンスに基づく PlantUML/Mermaid）・手順・完了条件を記述する。完了条件には該当 IT のデモ項目受け入れテスト green を含める。
|
|
65
|
+
5. **横断方針を書く**: デモ項目を受け入れ基準とする方針、局面移行時の一貫性維持、アプローチが変わっても不変な規律（サイクル 3 原則・コミット単位・品質基準・アーキテクチャテスト常時グリーン）を明記する。
|
|
45
66
|
6. **インデックスを同期する**: `operating-docs --update` で `docs/development/index.md` と `mkdocs.yml` に開発戦略を追加する。
|
|
46
67
|
7. コミットは `git-commit`（ユーザー指示があるまでコミットしない）。
|
|
47
68
|
|
|
@@ -50,11 +71,12 @@ description: 開発戦略ドキュメント（docs/development/development_strat
|
|
|
50
71
|
```markdown
|
|
51
72
|
# 開発戦略 - <プロジェクト名>
|
|
52
73
|
|
|
53
|
-
## 概要（参照元と Single Source of Truth
|
|
74
|
+
## 概要（参照元と Single Source of Truth の明記・イテレーション計画前提）
|
|
54
75
|
## 戦略の全体像（局面 → アプローチの対応表・図）
|
|
55
|
-
## 共通の TDD サイクル（Red-Green-Refactor
|
|
76
|
+
## 共通の TDD サイクル（Red-Green-Refactor・テスト種別対応・品質チェック）
|
|
77
|
+
## デモ項目を受け入れ基準とする（受け入れ/E2E 方針）
|
|
56
78
|
## 序盤: アウトサイドイン（目的 / 対象 US / ワークフロー / 手順 / 完了条件）
|
|
57
|
-
## 中盤:
|
|
79
|
+
## 中盤: インサイドアウト（同上。中核が単純なら省略可）
|
|
58
80
|
## 終盤: アウトサイドイン（同上）
|
|
59
81
|
## イテレーションごとの設計ドキュメント整合
|
|
60
82
|
## 局面移行時の一貫性維持
|
|
@@ -63,9 +85,11 @@ description: 開発戦略ドキュメント（docs/development/development_strat
|
|
|
63
85
|
|
|
64
86
|
## 拡張トピック（プロジェクトに応じて追加）
|
|
65
87
|
|
|
66
|
-
###
|
|
88
|
+
### ウォーキングスケルトンの基盤化（受け入れ/E2E で担保）
|
|
67
89
|
|
|
68
|
-
|
|
90
|
+
序盤で横断基盤（DI 組み立て・認証/認可・共通ミドルウェア・レイアウトなど）を構築した直後に、UI を持つ場合は UI 設計の画面遷移図に従ったナビゲーション（ロール制御付き）と全ルートのプレースホルダ画面を一括作成し、これを骨格とする。横断関心事を業務ロジックが薄いうちに全画面で成立させ、以降の各 IT を「スタブを実画面へ差し替える」インクリメンタルな作業に落とす。
|
|
91
|
+
|
|
92
|
+
このスケルトンの妥当性は受け入れ/E2E テストで担保する。序盤の最初のタスクとして E2E 基盤（例: Playwright）をセットアップし、UI を持つ場合は各ナビゲーション遷移（全ルート到達・ロール別の表示/非表示/403）を、API 中心の場合は主要エンドポイントの疎通を、テストで green にすることをスケルトン成立の判定基準とする。対象ルート・表示ロール・担当 IT を対応表で明示する。
|
|
69
93
|
|
|
70
94
|
### イテレーションごとの設計ドキュメント整合
|
|
71
95
|
|
|
@@ -73,27 +97,29 @@ description: 開発戦略ドキュメント（docs/development/development_strat
|
|
|
73
97
|
|
|
74
98
|
## 途中から再開・更新
|
|
75
99
|
|
|
76
|
-
既存の `docs/development/development_strategy.md`
|
|
100
|
+
既存の `docs/development/development_strategy.md` がある場合はまず内容を読み、局面割り当てやアプローチの追記・修正のみを行う。新たにイテレーションが計画された・イテレーション構成が変わった場合は、局面への割り当て表と各局面の対象 US・デモ項目受け入れテストを追従させ、更新履歴に日付と変更内容を追記する。
|
|
77
101
|
|
|
78
102
|
**Example:**
|
|
79
103
|
|
|
80
|
-
```
|
|
104
|
+
```text
|
|
81
105
|
ユーザー: 「中盤にイテレーションを 1 つ追加したので開発戦略を更新したい」
|
|
82
|
-
回答:
|
|
83
|
-
|
|
106
|
+
回答: 追加された iteration_plan-N.md の対象 US とデモ項目を確認し、
|
|
107
|
+
development_strategy.md の中盤節の対象 US 表・ワークフロー・受け入れ基準に反映。
|
|
108
|
+
戦略の全体像の対応表を更新し、更新履歴に追記して、
|
|
84
109
|
operating-docs --update でインデックスを同期する。
|
|
85
110
|
```
|
|
86
111
|
|
|
87
112
|
## 注意事項
|
|
88
113
|
|
|
89
|
-
-
|
|
114
|
+
- 本スキルは **イテレーション計画を前提** とする。イテレーションが未計画なら先に `planning-releases` で計画する。少なくとも序盤の IT に対象 US とデモ項目が定義されていること。
|
|
115
|
+
- アプローチ選択は必ず対象プロジェクトのコーディング/テストガイドの選択フローに理由づける。「なぜこの局面でこのアプローチか」を書かないと、単なる区切り表になり戦略の価値が失われる。
|
|
90
116
|
- `ALWAYS`/`MUST` の羅列でなく、各局面の狙い（why）を説明する文体にする。局面が変わっても不変な規律（Red-Green-Refactor 3 原則・1 コミット 1 変更・品質基準・アーキテクチャテスト常時グリーン）は明記する。
|
|
91
|
-
-
|
|
117
|
+
- 品質チェックコマンド・テスト構成は対象プロジェクトの実構成を確認して合わせる（憶測で書かない。ビルド設定ファイル・テストディレクトリ・タスクランナー設定を実際に確認する）。
|
|
92
118
|
- 新規作成後は `docs/development/index.md` と `mkdocs.yml` を必ず同期する。ユーザーの指示があるまでコミットしない。
|
|
93
119
|
|
|
94
120
|
## 関連スキル
|
|
95
121
|
|
|
96
|
-
- `planning-releases` —
|
|
122
|
+
- `planning-releases` — リリース・イテレーション計画（**本スキルの前提入力**。局面割り当てとデモ項目の供給元）
|
|
97
123
|
- `orchestrating-development` — 開発フェーズ全体の TDD ワークフロー（本戦略の実行フェーズ）
|
|
98
124
|
- `validating-iteration-plan` — イテレーション計画と設計ドキュメントの整合検証
|
|
99
125
|
- `developing-backend` / `developing-frontend` — 各局面での TDD 実装
|