spec-runner 1.1.16 → 1.1.18

package/spec-runner/templates/.claude/skills/existing-project-to-docs/SKILL.md

@@ -34,18 +34,25 @@ Phase 5: architecture contract 化
 
 ## Phase 3: 概要設計の draft 化
 
-1. UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
-2. `docs/02_概要設計/システム全体俯瞰.md` を作る
+1. `docs/02_概要設計/システム全体俯瞰.md` を作る
+2. `style: ddd` の場合: UC から集約・境界コンテキストを整理し `docs/02_概要設計/ドメインモデル.md` を draft する
 3. 必要なら ADR 候補も洗い出す（配置先は `90_ADR/全体/` / `ドメイン/` / `UC/` / `DB/`）
 4. ユーザーに確認・承認を得る
 
 ## Phase 4: 詳細設計の draft 化
 
+`style: ddd` の場合:
+
 1. ドメインごとにビジネスルール・集約を整理し `docs/03_詳細設計/01_ドメイン/{ドメイン名}.md` を draft する
 2. UC ごとに `docs/03_詳細設計/02_ユースケース/UC-{日本語名}.md` を draft する
 3. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/03_DB・外部サービス/` を作る
-4. 各ファイルの `maps_to` に対応コードとテストを入れる
-5. ユーザーに確認・承認を得る
+
+`style: layered` の場合:
+
+1. UC ごとに `docs/03_詳細設計/01_ユースケース/UC-{日本語名}.md` を draft する
+2. DB・外部サービスの仕様が必要なら `docs/03_詳細設計/02_DB・外部サービス/` を作る
+
+各ファイルの `maps_to` に対応コードとテストを入れる。ユーザーに確認・承認を得る。
 
 ## Phase 5: architecture contract 化
 
@@ -55,6 +62,6 @@ Phase 5: architecture contract 化
 
 ## 原則
 
-- 既存コードを正として観測し、推測は明示する
-- docs は最初から完璧を目指さず、draft として起こす
+- 既存コードを正として観測する。推測する場合は明示する
+- docs は最初から完璧を目指さず draft として起こす
 - `maps_to` と `depends_on` を使って後続変更に耐える形へ整える

package/spec-runner/templates/.claude/skills/harness-engineering/SKILL.md

@@ -1,12 +1,11 @@
 ---
 name: harness-engineering
-description: AI 開発運用の skills・rules・agents・テンプレートを改善・保守するためのメタスキル。別の作業を進めた結果、繰り返し発生する手戻り、ルール不足、責務の曖昧さ、テンプレートの重複が見つかったときに使用する。通常の機能実装やアプリコードの TDD には使わない。
+description: skills・rules・agents・テンプレートを改善・保守するメタスキル。手戻り・ルール不足・責務の曖昧さ・テンプレート重複が繰り返し発生したときに使う。通常の機能実装や TDD には使わない。
 ---
 
 # harness-engineering
 
-skills・rules・agents・テンプレートを改善するためのメタスキル。
-**主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。**
+skills・rules・agents・テンプレートを改善するためのメタスキル。主目的の作業を先に進め、再利用価値のある改善が必要なときだけ使う。
 
 ## 使うタイミング
 
@@ -24,8 +23,7 @@ skills・rules・agents・テンプレートを改善するためのメタスキ
 - アプリケーションコードに対する TDD
 - 単なる言い回しの微調整で済む変更
 
-**TDD はこのスキルの対象ではない。**
-TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
+TDD はこのスキルの対象ではない。TDD は `test-driven-development` スキルに従い、対象プロダクトのコード品質を上げるために行う。
 
 ## 全体フロー
 
@@ -68,7 +66,7 @@ Phase 4: 影響範囲の反映確認
 
 ## Phase 3: skill / rule / agent / template の修正
 
-ファイルを作成・修正する前に **`.claude/rules/harness-formats.md`** を読み、フォーマットを確認する。
+ファイルを作成・修正する前に `.claude/rules/harness-formats.md` を読み、フォーマットを確認する。
 
 1. 対象ファイルを特定する
 2. 意図が変わらない最小差分で修正する
@@ -98,8 +96,8 @@ Phase 4: 影響範囲の反映確認
 
 ## 原則
 
-- **ハーネス改善は常時実行しない。必要なときだけ行う**
-- **主目的の作業を優先する**
-- **最小変更で改善する**
-- **新しい skill の追加は慎重に行う**
-- **TDD の責務を skill 改善と混同しない**
+- ハーネス改善は常時実行しない。必要なときだけ行う
+- 主目的の作業を優先する
+- 最小変更で改善する
+- 新しい skill の追加は慎重に行う
+- TDD の責務を skill 改善と混同しない

package/spec-runner/templates/.claude/skills/simple-seed/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: simple-seed
+description: レイヤードアーキテクチャ / CRUD 中心のプロジェクト向け docs 正本開発フロー。ドメイン層を持たず UC・サービス層で設計する。architecture.yaml の style: layered のときに使う。
+---
+
+# simple-seed
+
+> レイヤードアーキテクチャ / CRUD 中心のプロジェクト向けの docs 正本開発フロー（種）。`architecture.yaml` の `style: layered` で使う。DDD が必要なプロジェクトは `docs-driven-seed` を使う。
+> このスキルは種。`architecture-skill-development` でプロジェクト専用スキルに育てる。
+
+## 全体フロー
+
+```
+Phase 1: 要件定義
+Phase 2: 概要設計（ユースケース + システム全体俯瞰）
+Phase 3: ADR（必要時のみ）
+Phase 4: 詳細設計（UC → DB・外部サービス）
+Phase 5: TDD → 実装
+```
+
+## 前提ルール
+
+- docs は正本とし、各ドキュメントに `spec_runner` frontmatter を付ける
+- 詳細設計は `01_ユースケース/` `02_DB・外部サービス/` の 2 層で構成する
+- `maps_to` は必ず設定する。パス推定に頼らない
+- ユーザー承認なしに次フェーズへ進めない
+
+## Phase 1: 要件定義
+
+`architecture-definition` で完了済み。`docs/01_要件定義/` が存在することを確認して次へ進む。
+
+## Phase 2: 概要設計
+
+テンプレート: `templates/02_概要設計/`
+
+1. 要件定義からユースケースを洗い出す（Query / Command を意識）
+2. テンプレートをコピーして `docs/02_概要設計/ユースケース一覧.md` を作る
+3. コンポーネント全体図・外部 IF を整理し `docs/02_概要設計/システム全体俯瞰.md` を作る
+4. ユーザーに確認・承認を得る
+
+### 出力
+
+```
+docs/02_概要設計/
+  ユースケース一覧.md
+  システム全体俯瞰.md
+  90_ADR/
+    全体/
+    UC/
+    DB/
+```
+
+## Phase 3: ADR（必要時のみ）
+
+1. 設計判断が必要な場合だけ ADR を作る
+2. 提案時に必ず 3 案を比較する。ドキュメントには採用案と採用理由のみ記録する
+3. ファイル名は `mmdd-{日本語タイトル}.md`、配置先は対象フォルダ
+
+| 対象 | 配置先 |
+|------|--------|
+| システム横断の決定 | `90_ADR/全体/` |
+| UC フローの決定 | `90_ADR/UC/` |
+| DB・外部サービスの決定 | `90_ADR/DB/` |
+
+4. 採用案を概要設計へ反映してから次へ進む
+
+## Phase 4: 詳細設計
+
+UC → DB・外部サービス の順に設計する。
+
+### 4-1. ユースケース
+
+テンプレート: `templates/03_詳細設計/01_ユースケース/UC-{日本語名}.md`
+
+```
+docs/03_詳細設計/01_ユースケース/
+  UC-{日本語名}.md
+```
+
+### 4-2. DB・外部サービス（必要時のみ）
+
+```
+docs/03_詳細設計/02_DB・外部サービス/
+  スキーマ定義.dbml
+  外部サービス.md
+```
+
+3. ユーザーに確認・承認を得る
+
+## Phase 5: TDD → 実装
+
+`test-driven-development` スキルへ移行する。
+
+### 実装完了後
+
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
+- `@code-reviewer` — コーディング規約への適合チェック
+
+## 原則
+
+- ドメイン層は持たない。ビジネスロジックは UC / サービス層で表現する
+- `maps_to` は必ず設定する。パス推定に頼らない

package/spec-runner/templates/.claude/skills/simple-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/202/267/343/202/271/343/203/206/343/203/240/345/205/250/344/275/223/344/277/257/347/236/260.md

@@ -0,0 +1,33 @@
+---
+spec_runner:
+  node_id: overview.system_context
+  kind: overview_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - src/
+---
+
+# システム全体俯瞰
+
+## コンポーネント全体図
+
+```mermaid
+graph LR
+  User([ユーザー])
+  subgraph システム
+    {フロントエンド}
+    {バックエンド}
+  end
+  Ext([{外部サービス}])
+
+  User --> {フロントエンド}
+  {フロントエンド} --> {バックエンド}
+  {バックエンド} --> Ext
+```
+
+## 外部インターフェース
+
+| 外部システム | 方向 | プロトコル | 概要 |
+|------------|------|----------|------|
+| {外部システム名} | 受信 / 送信 | {HTTP / gRPC など} | {概要} |

package/spec-runner/templates/.claude/skills/simple-seed/templates/02_/346/246/202/350/246/201/350/250/255/350/250/210//343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/344/270/200/350/246/247.md

@@ -0,0 +1,15 @@
+---
+spec_runner:
+  node_id: overview.use_case_list
+  kind: overview_design
+  depends_on:
+    - requirement.要件定義
+  maps_to:
+    - docs/03_詳細設計/01_ユースケース/
+---
+
+# ユースケース一覧
+
+| UC ID | UC名 | 種別 | 概要 |
+|-------|------|------|------|
+| UC-{番号} | {UC名} | Command / Query | {概要} |

package/spec-runner/templates/.claude/skills/simple-seed/templates/03_/350/251/263/347/264/260/350/250/255/350/250/210/01_/343/203/246/343/203/274/343/202/271/343/202/261/343/203/274/343/202/271/UC-{/346/227/245/346/234/254/350/252/236/345/220/215}.md

@@ -0,0 +1,53 @@
+---
+spec_runner:
+  node_id: detail.usecase.{UC名}
+  kind: detailed_design
+  depends_on:
+    - overview.use_case_list
+  maps_to:
+    - src/application/{uc_name}/
+    - tests/application/{uc_name}/
+---
+
+# UC-{UC名} 詳細設計
+
+## 概要
+
+- トリガー: {何がこのUCを呼び出すか}
+- 事前条件: {UCが成立するために必要な状態}
+- 事後条件: {UC完了後の状態}
+
+## 入出力
+
+| 種別 | 名前 | 型 | 説明 |
+|------|------|----|------|
+| 入力 | {入力名} | {型} | {説明} |
+| 出力 | {出力名} | {型} | {説明} |
+
+## 主要フロー
+
+```mermaid
+sequenceDiagram
+  {シーケンス図}
+```
+
+1. {ステップ1}
+2. {ステップ2}
+
+## 判断条件
+
+| 判断ポイント | 条件 | アクション |
+|------------|------|----------|
+| {判断ポイント} | {条件} | {アクション} |
+
+## エラーポリシー
+
+| エラーケース | 発生条件 | 対応 |
+|------------|---------|------|
+| {エラーケース} | {発生条件} | {対応} |
+
+## テスト観点
+
+- {正常系の観点}
+- {異常系の観点}
+- {境界条件の観点}

package/spec-runner/templates/.claude/skills/test-driven-development/SKILL.md

@@ -9,13 +9,13 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 テストを先に書く。失敗するのを確認する。通る最小のコードを書く。
 
-**中核原則:** テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
+テストが失敗するのを見ていないなら、そのテストが正しいものを検証しているか分からない。
 
 ## いつ使うか
 
-**常に:** 新機能・バグ修正・リファクタリング・振る舞い変更
+常に使う: 新機能・バグ修正・リファクタリング・振る舞い変更
 
-**例外（ユーザーに確認する）:** 使い捨てプロトタイプ・生成コード・設定ファイル
+例外（ユーザーに確認する）: 使い捨てプロトタイプ・生成コード・設定ファイル
 
 ## 鉄の掟
 
@@ -28,7 +28,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ## テスト戦略：テストピラミッド
 
-実装前にどのテスト種別を書くかを決める。迷ったら**単体テストから始める**。
+実装前にどのテスト種別を書くかを決める。迷ったら単体テストから始める。
 
 ```
         /\
@@ -55,7 +55,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 
 ### 結合テスト（Integration）
 
-**対象:** 複数モジュールの連携、DB・キャッシュ・外部APIとの境界
+**対象:** 複数モジュールの連携、DB・キャッシュ・外部 API との境界
 
 **書くとき:**
 - DB へのクエリ・永続化
@@ -91,7 +91,7 @@ description: 新機能実装やバグ修正を行う際、実装コードを書
 | バグ修正 | 最小レベルで再現テスト | — |
 
 **バグ修正の場合:** バグを再現できる最も低いレベルのテストを書く。
-単体で再現できるなら単体、DBが絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
+単体で再現できるなら単体、DB が絡むなら結合。E2E で初めて再現するバグは、単体・結合に落とし込めないか検討する。
 
 ## テスト実行コマンド
 
@@ -145,7 +145,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify RED - 失敗するのを確認する
 
-**必須。絶対に省略しない。**
+> 必須。絶対に省略しない。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -164,7 +164,7 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### Verify GREEN - 通るのを確認する
 
-**必須。**
+> 必須。
 
 `@test-runner` エージェントに委任して実行する。
 
@@ -178,8 +178,8 @@ test("ある入力に対して期待する出力を返す", () => {
 
 ### REFACTOR - 整理する
 
-Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
-テストは常にGreenを維持する。新しい挙動は追加しない。
+Green の後にのみ: 重複削除・命名改善・ヘルパ抽出。
+テストは常に Green を維持する。新しい挙動は追加しない。
 
 ### 繰り返す
 
@@ -189,12 +189,12 @@ Greenの後にのみ: 重複削除・命名改善・ヘルパ抽出。
 
 - **最小**: 1つの振る舞いだけ。「and」が入るなら分割する
 - **明確**: テスト名が挙動を説明する
-- **意図が見える**: 望ましいAPIの使い方が伝わる
+- **意図が見える**: 望ましい API の使い方が伝わる
 
 ## テストのコメント
 
 テストコメントの規約は同梱のコーディング規約ファイルの「テストコメント規約」に従う。
-GREEN / REFACTORフェーズで書く実装コードにもビジネスロジックの意図をコメントする。
+GREEN / REFACTOR フェーズで書く実装コードにもビジネスロジックの意図をコメントする。
 
 ## テスト構成
 
@@ -256,18 +256,19 @@ tests/
 |------|------|
 | 「簡単すぎてテスト不要」 | 簡単でも壊れる。テストは30秒 |
 | 「あとでテストする」 | すぐ通るテストは何も証明しない |
-| 「今回だけTDDを飛ばす」 | 合理化である。止めること |
-| テスト前にコードを書いた | コードを削除し、TDDで最初からやり直す |
+| 「今回だけ TDD を飛ばす」 | 合理化である。止めること |
+| テスト前にコードを書いた | コードを削除し、TDD で最初からやり直す |
 | テストが最初から通る | 既存挙動をテストしている。テストを修正する |
 | なぜ失敗したか説明できない | テストが正しいか再検討する |
 | 全部 E2E で書いた | ピラミッドが逆転している。単体・結合に落とし込む |
 | 全部モックだらけ | 結合が強すぎる。または結合テストを書くべき |
 
-**どれか1つでも当てはまるなら: コードを削除し、TDDで最初からやり直す。**
+どれか 1 つでも当てはまるなら: コードを削除し、TDD で最初からやり直す。
 
 ## 完了時のレビュー
 
-実装完了後、以下のエージェントでレビューする:
+実装完了後、以下のエージェントを**同時に**起動してレビューする:
+- `@design-reviewer` — 設計書⇔実装の整合性チェック
 - `@code-reviewer` — コーディング規約への適合チェック
 
 ## 検証チェックリスト
@@ -285,13 +286,13 @@ tests/
 - [ ] モック方針がテスト種別に合っている
 - [ ] エッジケースとエラーをカバーした
 
-すべてにチェックできないならTDDを飛ばしている。やり直すこと。
+すべてにチェックできないなら TDD を飛ばしている。やり直すこと。
 
 ## 詰まったとき
 
 | 問題 | 解決 |
 |------|------|
-| どうテストすべきか分からない | 望むAPIを書き、まずアサーションを書く。ユーザーに相談する |
+| どうテストすべきか分からない | 望む API を書き、まずアサーションを書く。ユーザーに相談する |
 | どのテスト種別か迷う | 単体から始める。単体で書けないなら結合を検討する |
 | テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化する |
 | 何でもモック必須 | 結合が強すぎる。依存性注入を使う。または結合テストで書く |
@@ -302,7 +303,7 @@ tests/
 
 ```
 本番コード → 先にテストが存在し、失敗している
-それ以外 → TDDではない
+それ以外 → TDD ではない
 ```
 
 ユーザーの許可なしに例外はない。

package/spec-runner/templates/.github/agents/code-reviewer.agent.md

@@ -5,9 +5,9 @@ tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# コーディング規約チェックエージェント
+# コーディング規約チェックエージェント（読み取り専用）
 
-変更されたコードをコーディング規約と照合し、違反を報告する。
+変更されたコードをコーディング規約と照合し、違反を報告する。変更ファイルのみが対象。
 
 ## 手順
 
@@ -31,9 +31,3 @@ model: sonnet
 ### 問題なし
 - [チェック済みファイル一覧]
 ```
-
-## 注意事項
-
-- 読み取り専用（コードの変更は行わない）
-- 日本語で報告する
-- 変更されたファイルのみをチェック対象とする（既存コードの規約違反は指摘しない）

package/spec-runner/templates/.github/agents/design-reviewer.agent.md

@@ -5,17 +5,16 @@ tools: Read, Grep, Glob
 model: sonnet
 ---
 
-# 設計書⇔実装 整合性チェックエージェント
+# 設計書⇔実装 整合性チェックエージェント（読み取り専用）
 
-docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離を報告する。
+`docs/` の設計書と `src/` の実装コードを突合し、乖離を報告する。`maps_to` を唯一の参照先とする（パス推定は行わない）。
 
 ## 手順
 
 1. `docs/` 配下の設計書ファイルを一覧取得する
 2. 各設計書の frontmatter を読み、`spec_runner.node_id` / `kind` / `depends_on` / `maps_to` を確認する
-3. `docs/02_概要設計/**` の各ファイルを読む。ユースケース・責務・外部 IF が実装に反映されているか確認するために、`maps_to` から対応する `src/` ファイルを特定して実際に読んで比較する
-4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを**実際に読み**、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する
-   - `maps_to` が空または未設定の場合はフロントマターの問題として報告する（パス推定は行わない）
+3. `docs/02_概要設計/**` の各ファイルを読む。`maps_to` から対応する `src/` ファイルを特定して読み、ユースケース・責務・外部 IF が実装に反映されているか比較する
+4. `docs/03_詳細設計/**` の各ファイルを読む。`maps_to` に列挙された `src/` / `tests/` ファイルを実際に読み、責務・入出力・判断条件・テスト観点を設計書と行レベルで比較する（`maps_to` が空または未設定の場合は frontmatter の問題として報告する）
 5. 乖離を報告する
 
 ## チェック項目
@@ -44,7 +43,7 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 ```
 ## 整合性チェック結果
 
-### frontmatterの問題
+### frontmatter の問題
 - [ファイル]: [問題内容]
 
 ### 一致（問題なし）
@@ -57,9 +56,4 @@ docs/ 配下の設計書と src/ 配下の実装コードを突合し、乖離
 - 推奨対応: 設計書を更新 / 実装を修正
 ```
 
-## 注意事項
-
-- 読み取り専用（コードや設計書の変更は行わない）
-- 日本語で報告する
-- ADR はコードと 1 対 1 の突合対象ではないが、配置先と反映有無は確認する
-- `maps_to` を唯一の参照先とする。パス推定は行わない
+ADR はコードと 1 対 1 の突合対象ではないが、配置先と反映有無は確認する。

package/spec-runner/templates/.github/agents/impact-analyzer.agent.md

@@ -1,13 +1,13 @@
 ---
 name: impact-analyzer
-description: design-change で影響範囲を調査するときに呼ぶ。変更対象の node_id またはファイルパスを受け取り、.spec-runner/scan/graph.json のキャッシュを参照して影響ファイルを一覧化し、maps_to の参照整合性も報告する。
+description: design-change で影響範囲を調査するときに呼ぶ。node_id から連鎖する影響ファイルを一覧化し、maps_to の整合性を報告する。
 tools: Bash
 model: sonnet
 ---
 
-# 影響範囲分析エージェント
+# 影響範囲分析エージェント（読み取り専用）
 
-`.spec-runner/scan/graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
+`graph.json`（`scan.js` が生成するキャッシュ）を読み、変更対象の node_id から連鎖する影響ファイルを一覧化する。
 
 ## 入力
 
@@ -67,9 +67,4 @@ console.log(JSON.stringify({ node, direct: direct.map(n => ({id: n, ...g.nodes[n
 - [ファイルパス] — 理由: {理由}
 ```
 
-## 注意事項
-
-- 読み取り専用（ファイルの変更は行わない）
-- 日本語で報告する
-- graph.json が存在しない場合は scan.js を実行してから進む
-- 影響ファイルが多い場合は kind 別にグループ化する
+影響ファイルが多い場合は kind 別にグループ化する。

package/spec-runner/templates/.github/agents/test-runner.agent.md

@@ -5,17 +5,19 @@ tools: Read, Grep, Glob, Bash
 model: sonnet
 ---
 
-# テスト実行エージェント
+# テスト実行エージェント（読み取り専用）
 
-テストをDocker環境で実行し、結果を分析する。
+> このファイルはテンプレートです。`architecture-skill-development` でプロジェクトのテスト実行コマンドに書き換えてください。
+
+テストを実行し、結果を分析する。コードは修正しない。
 
 ## 手順
 
 1. `git diff --name-only` で変更ファイルを確認する
 2. 変更ファイルに対応するテストファイルを特定する（`tests/` 配下の同構造）
 3. テストを実行する:
-   - 対象テストが明確な場合: `docker compose run --rm test pytest tests/path/to/test_file.py -v`
-   - 全体実行が必要な場合: `docker compose run --rm test pytest -v`
+   - 対象テストが明確な場合: `<your-test-command> <test-file> -v`
+   - 全体実行が必要な場合: `<your-test-command> -v`
 4. 結果を分析する
 
 ## 失敗時の分析
@@ -26,9 +28,3 @@ model: sonnet
 - **エラー内容**: アサーションエラーやスタックトレースの要約
 - **原因の推定**: 変更内容との関連性を分析
 - **修正案**: 具体的なコード修正の提案（コード例を含める）
-
-## 注意事項
-
-- テスト実行は必ず `docker compose run --rm test pytest` で行う
-- コードの修正は行わない（分析と提案のみ）
-- 日本語で報告する