npm - @k2works/claude-code-booster - Versions diffs - 6.2.0 → 6.3.0 - Mend

@k2works/claude-code-booster 6.2.0 → 6.3.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.

Files changed (618) hide show

package/lib/assets/docs/article/getting-start-tdd/fsharp/chapter03.md DELETED Viewed

@@ -1,227 +0,0 @@
----
-type: Article
-title: "第 3 章: 明白な実装とリファクタリング"
-description: "前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。"
-tags: [article, getting-start-tdd, fsharp]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 3 章: 明白な実装とリファクタリング
-## 3.1 はじめに
-前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。この章では、残りの TODO（リスト生成とプリント）を実装し、**match 式** と **パイプライン演算子** を活用してリファクタリングします。
-**TODO リスト**:
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-## 3.2 match 式によるリファクタリング
-テスト駆動開発の流れを確認しておきましょう。
-> 1. レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを 1 つ書く。
-> 2. グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
-> 3. リファクタリング：テストを通すために発生した重複をすべて除去する。
->
-> レッド・グリーン・リファクタリング。それが TDD のマントラだ。
->
-> — テスト駆動開発
-現在の `if/elif/else` による実装を、F# らしい **match 式** でリファクタリングします。
-### Before: if/elif/else
-```fsharp
-let generate (number: int) : string =
-    if number % 3 = 0 && number % 5 = 0 then "FizzBuzz"
-    elif number % 3 = 0 then "Fizz"
-    elif number % 5 = 0 then "Buzz"
-    else string number
-```
-### After: match 式（タプルパターン）
-```fsharp
-let generate (number: int) : string =
-    match (number % 3, number % 5) with
-    | (0, 0) -> "FizzBuzz"
-    | (0, _) -> "Fizz"
-    | (_, 0) -> "Buzz"
-    | _ -> string number
-```
-テストを実行して、リファクタリング後もすべて通ることを確認します。
-```bash
-$ dotnet test
-  合計: 6、成功: 6、失敗: 0、スキップ: 0
-```
-F# の `match` 式は Rust の `match` 式と非常によく似ています。タプル `(number % 3, number % 5)` に対してパターンを照合し、`_` はワイルドカード（任意の値にマッチ）です。Rust との違いは、矢印記号が `=>` ではなく `->` である点です。
-## 3.3 1 から 100 までのリスト生成
-### Red: リスト生成のテスト
-1 から 100 までの FizzBuzz の結果をリストとして返す関数をテストします。
-```fsharp
-[<Fact>]
-let ``一から百までのリストを生成する`` () =
-    let list = generateList 100
-    Assert.Equal(100, list.Length)
-    Assert.Equal("1", list.[0])
-    Assert.Equal("Fizz", list.[2])
-    Assert.Equal("Buzz", list.[4])
-    Assert.Equal("FizzBuzz", list.[14])
-```
-```bash
-$ dotnet test
-error FS0039: 値またはコンストラクター 'generateList' が定義されていません。
-```
-### Green: 明白な実装
-F# のリスト内包表記と `List.map` を使って実装します。
-```fsharp
-let generateList (count: int) : string list =
-    [ 1..count ] |> List.map generate
-```
-```bash
-$ dotnet test
-  合計: 7、成功: 7、失敗: 0、スキップ: 0
-```
-> 明白な実装
->
-> シンプルな操作を実現するにはどうすればいいだろうか——そのまま実装しよう。
->
-> — テスト駆動開発
-`[ 1..count ]` は F# の **リスト内包表記** で、1 から count までのリストを生成します。Rust の `(1..=count)` や Python の `range(1, count + 1)` に相当します。`|>` パイプライン演算子で `List.map generate` に渡し、各要素を `generate` 関数で変換します。
-**TODO リスト**:
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [x] 1 から 100 までの数
-- [ ] プリントする
-## 3.4 プリント機能
-### 学習用テスト
-プリント機能は、生成したリストの各要素を出力するものです。学習用テストとして、F# のリスト反復処理を確認します。
-> 学習用テスト
->
-> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
->
-> — テスト駆動開発
-F# では `List.iter` で各要素に対して副作用のある処理を実行できます。
-```fsharp
-[<Fact>]
-let ``リストの各要素を処理できる`` () =
-    let mutable result = []
-    [ "1"; "2"; "Fizz" ] |> List.iter (fun s -> result <- s :: result)
-    Assert.Equal(3, result.Length)
-```
-### Print 関数の実装
-```fsharp
-let printFizzBuzz (count: int) : unit =
-    generateList count |> List.iter (printfn "%s")
-```
-`printfn "%s"` は F# の書式付き出力関数です。`%s` は文字列のフォーマット指定子で、`printf` の F# 版です。戻り値の `unit` は Rust の `()` や Java の `void` に相当します。
-**TODO リスト**:
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [x] 1 から 100 までの数
-- [x] プリントする
-## 3.5 テストコードのリファクタリング
-テストを論理的なグループに構造化します。F# ではモジュールを使ってテストをグルーピングできます。
-```fsharp
-module Tests
-open Xunit
-open FizzBuzzFSharp.FizzBuzz
-module FizzBuzzRunnerTests =
-    [<Fact>]
-    let ``数を文字列にして返す_1を渡したら文字列1を返す`` () =
-        Assert.Equal("1", generate 1)
-    [<Fact>]
-    let ``数を文字列にして返す_2を渡したら文字列2を返す`` () =
-        Assert.Equal("2", generate 2)
-    [<Fact>]
-    let ``三の倍数のときはFizzを返す`` () =
-        Assert.Equal("Fizz", generate 3)
-    [<Fact>]
-    let ``五の倍数のときはBuzzを返す`` () =
-        Assert.Equal("Buzz", generate 5)
-    [<Fact>]
-    let ``三と五の倍数のときはFizzBuzzを返す`` () =
-        Assert.Equal("FizzBuzz", generate 15)
-    [<Fact>]
-    let ``一から百までのリストを生成する`` () =
-        let list = generateList 100
-        Assert.Equal(100, list.Length)
-        Assert.Equal("1", list.[0])
-        Assert.Equal("Fizz", list.[2])
-        Assert.Equal("Buzz", list.[4])
-        Assert.Equal("FizzBuzz", list.[14])
-```
-## 3.6 他言語との比較
-| 概念 | Java | Python | Rust | F# |
-|------|------|--------|------|-----|
-| テストフレームワーク | JUnit 5 | pytest | cargo test | xUnit |
-| テスト実行 | `./gradlew test` | `pytest` | `cargo test` | `dotnet test` |
-| 文字列変換 | `String.valueOf(n)` | `str(n)` | `n.to_string()` | `string n` |
-| 剰余判定 | `n % 3 == 0` | `n % 3 == 0` | `n % 3 == 0` | `n % 3 = 0` |
-| リスト生成 | `IntStream.rangeClosed` | `[f(n) for n in range]` | `(1..=n).map(f).collect()` | `[1..n] \|> List.map f` |
-| パターンマッチ | `switch`(Java 21+) | `match`(3.10+) | `match` | `match...with` |
-## 3.7 まとめ
-この章では以下のことを学びました。
-- **match 式** によるタプルパターンマッチング
-- **パイプライン演算子** `|>` によるデータ変換の連鎖
-- **リスト内包表記** `[1..count]` によるリスト生成
-- `List.map` と `List.iter` によるリスト操作
-- **明白な実装** でシンプルな操作をそのまま実装する手法
-- **リファクタリング** でテストモジュールを構造化する考え方
-- Red-Green-Refactor サイクルの完了
-第 1 部の 3 章を通じて、TDD の基本サイクル（仮実装 → 三角測量 → 明白な実装 → リファクタリング）を一通り体験しました。次の第 2 部では、開発環境の自動化（バージョン管理、パッケージ管理、CI/CD）に進みます。

package/lib/assets/docs/article/getting-start-tdd/fsharp/chapter04.md DELETED Viewed

@@ -1,188 +0,0 @@
----
-type: Article
-title: "第 4 章: バージョン管理と Conventional Commits"
-description: "前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。"
-tags: [article, getting-start-tdd, fsharp]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 4 章: バージョン管理と Conventional Commits
-## 4.1 はじめに
-前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。この章からは「動作するきれいなコード」を書き続けるために必要な **ソフトウェア開発の三種の神器** を整備していきます。
-> 今日のソフトウェア開発の世界において絶対になければならない 3 つの技術的な柱があります。三本柱と言ったり、三種の神器と言ったりしていますが、それらは
->
-> - バージョン管理
-> - テスティング
-> - 自動化
->
-> の 3 つです。
->
-> — 和田卓人
-**バージョン管理** と **テスティング** に関しては第 1 部で触れました。本章ではバージョン管理をさらに深掘りし、**コミットメッセージの規約** について解説します。
-## 4.2 コミットメッセージの重要性
-これまでの作業では、区切りごとにリポジトリにコミットしてきました。しかし、コミットメッセージの書き方に一貫性がないと、後からプロジェクトの履歴を追うのが難しくなります。
-チーム開発では特に、誰がいつ何のためにコードを変更したのかを明確にすることが重要です。そこで役立つのが **Conventional Commits** です。
-## 4.3 Conventional Commits
-本プロジェクトでは [Angular ルール](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) に基づいた **Conventional Commits** の書式を採用します。
-### コミットメッセージのフォーマット
-```
-<タイプ>(<スコープ>): <タイトル>
-<空行>
-<ボディ>
-<空行>
-<フッタ>
-```
-### タイプの種類
-| タイプ | 説明 | 例 |
-|--------|------|-----|
-| `feat` | 新機能の追加 | `feat: FizzBuzz のコアロジックを実装` |
-| `fix` | バグの修正 | `fix: 15 の倍数の判定順序を修正` |
-| `refactor` | リファクタリング | `refactor: match 式でパターンマッチに変更` |
-| `test` | テストの追加・修正 | `test: 三角測量のテストケースを追加` |
-| `docs` | ドキュメントの変更 | `docs: README にセットアップ手順を追加` |
-| `chore` | ビルド・ツールの変更 | `chore: Cake ビルドスクリプトを追加` |
-| `style` | コードスタイルの変更 | `style: Fantomas で自動フォーマット` |
-### F# プロジェクトでの例
-```bash
-# テスト追加
-$ git commit -m 'test: 数を文字列にして返す'
-# 機能実装
-$ git commit -m 'feat: generate 関数で match 式による FizzBuzz 判定を実装'
-# リファクタリング
-$ git commit -m 'refactor: パイプライン演算子でリスト生成を簡潔に記述'
-```
-## 4.4 Git の基本操作
-### リポジトリの初期化
-```bash
-# プロジェクトディレクトリで Git リポジトリを初期化
-$ git init
-# .gitignore を作成
-$ echo "bin/
-obj/
-.vs/
-*.user
-coverage/
-test-results/" > .gitignore
-# 初期コミット
-$ git add .
-$ git commit -m "feat: initial commit"
-```
-### 基本的なワークフロー
-```bash
-# 変更内容を確認
-$ git status
-# 特定のファイルをステージング
-$ git add src/Library.fs tests/Tests.fs
-# コミット
-$ git commit -m 'feat: generate 関数で FizzBuzz 判定を実装'
-# 履歴の確認
-$ git log --oneline
-```
-### 意味のある単位でのコミット
-TDD の各フェーズでコミットすることで、変更の意図が明確になります。
-```bash
-# Red フェーズ: テストの追加
-$ git add tests/Tests.fs
-$ git commit -m 'test: 三の倍数で Fizz を返すテストを追加'
-# Green フェーズ: 実装
-$ git add src/Library.fs
-$ git commit -m 'feat: 三の倍数で Fizz を返す実装を追加'
-# Refactor フェーズ: リファクタリング
-$ git add src/Library.fs
-$ git commit -m 'refactor: match 式でパターンマッチに変更'
-```
-## 4.5 Git フロー
-### ブランチ戦略
-| ブランチ | 用途 |
-|---------|------|
-| `main` | リリース可能な安定版 |
-| `develop` | 開発中の最新コード |
-| `feature/*` | 機能開発用ブランチ |
-### 作業の流れ
-1. `develop` ブランチから作業を開始
-2. TDD サイクル（Red → Green → Refactor）を実行
-3. Conventional Commits の書式でコミット
-4. テストが通ることを確認してプッシュ
-### Feature Branch ワークフロー
-```bash
-# 新機能開発用のブランチを作成
-$ git checkout -b feature/add-fizzbuzz-type
-# 開発作業（TDD サイクル）
-# ... コーディング ...
-# 変更をコミット
-$ git add .
-$ git commit -m "feat: FizzBuzzType 判別共用体を追加"
-# develop ブランチに統合
-$ git checkout develop
-$ git merge feature/add-fizzbuzz-type
-$ git branch -d feature/add-fizzbuzz-type
-```
-### F# プロジェクトでの .gitignore
-.NET プロジェクトでは以下のファイルをバージョン管理から除外します。
-```
-bin/
-obj/
-.vs/
-*.user
-coverage/
-test-results/
-```
-## 4.6 まとめ
-この章では以下を学びました。
-| 概念 | 説明 |
-|------|------|
-| Conventional Commits | コミットメッセージの標準的な書式 |
-| タイプ | feat, fix, refactor, test, docs, chore, style |
-| スコープ | 変更の影響範囲（任意） |
-| Git フロー | main / develop / feature ブランチ戦略 |
-次章では、NuGet によるパッケージ管理と Fantomas による静的解析を導入します。

package/lib/assets/docs/article/getting-start-tdd/fsharp/chapter05.md DELETED Viewed

@@ -1,276 +0,0 @@
----
-type: Article
-title: "第 5 章: パッケージ管理と静的解析"
-description: "前章では Conventional Commits によるコミットメッセージの規約を学びました。"
-tags: [article, getting-start-tdd, fsharp]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-# 第 5 章: パッケージ管理と静的解析
-## 5.1 はじめに
-前章では Conventional Commits によるコミットメッセージの規約を学びました。この章では、**パッケージ管理** と **静的コード解析** を導入し、コードの品質を自動でチェックできるようにします。
-## 5.2 NuGet によるパッケージ管理
-### NuGet とは
-> NuGet は .NET のパッケージマネージャです。パッケージの追加、削除、更新、依存関係の解決を自動で行います。
-Java の Gradle、Node の npm、Python の uv、Ruby の Bundler、Rust の Cargo に相当するのが NuGet です。
-### .fsproj ファイルの構成
-F# プロジェクトの設定は `.fsproj` ファイルで管理されます。本プロジェクトのライブラリプロジェクトは以下の構成です。
-```xml
-<Project Sdk="Microsoft.NET.Sdk">
-  <PropertyGroup>
-    <TargetFramework>net8.0</TargetFramework>
-    <GenerateDocumentationFile>true</GenerateDocumentationFile>
-  </PropertyGroup>
-  <ItemGroup>
-    <Compile Include="Library.fs" />
-  </ItemGroup>
-</Project>
-```
-テストプロジェクトの設定は以下の通りです。
-```xml
-<Project Sdk="Microsoft.NET.Sdk">
-  <PropertyGroup>
-    <TargetFramework>net8.0</TargetFramework>
-    <IsPackable>false</IsPackable>
-    <GenerateProgramFile>false</GenerateProgramFile>
-    <IsTestProject>true</IsTestProject>
-  </PropertyGroup>
-  <ItemGroup>
-    <Compile Include="Tests.fs" />
-    <Compile Include="Program.fs" />
-  </ItemGroup>
-  <ItemGroup>
-    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
-    <PackageReference Include="xunit" Version="2.5.3" />
-    <PackageReference Include="xunit.runner.visualstudio" Version="2.5.3" />
-    <PackageReference Include="coverlet.collector" Version="6.0.0" />
-  </ItemGroup>
-  <ItemGroup>
-    <ProjectReference Include="..\FizzBuzzFSharp\FizzBuzzFSharp.fsproj" />
-  </ItemGroup>
-</Project>
-```
-F# プロジェクトの重要な特徴として、`<Compile Include>` の **順序が意味を持つ** 点があります。F# コンパイラはファイルを上から下へ順に処理するため、依存先のファイルを先に記述する必要があります。
-### 主要なコマンド
-| コマンド | 説明 |
-|---------|------|
-| `dotnet new` | 新しいプロジェクトを作成 |
-| `dotnet build` | プロジェクトをビルド |
-| `dotnet test` | テストを実行 |
-| `dotnet run` | アプリケーションを実行 |
-| `dotnet add package <name>` | パッケージを追加 |
-| `dotnet restore` | 依存パッケージを復元 |
-### NuGet の特徴
-- **`obj/project.assets.json` による再現性** — 依存パッケージのバージョンを固定し、環境間の差異を排除
-- **Central Package Management** — `Directory.Packages.props` で複数プロジェクトのパッケージバージョンを統一管理
-- **`bin/` と `obj/` ディレクトリ** — Rust の `target/`、Node の `node_modules/` に相当（`.gitignore` に追加）
-## 5.3 Fantomas によるコードフォーマット
-### Fantomas とは
-> Fantomas は F# の公式コードフォーマッターです。コードスタイルを統一し、チーム内のスタイル議論を排除します。
-Rust の rustfmt、Go の gofmt、Python の Ruff format、TypeScript の Prettier に相当します。
-### インストールと実行
-```bash
-# グローバルツールとしてインストール
-$ dotnet tool install -g fantomas
-# フォーマットチェック（CI 向け）
-$ fantomas --check src/ tests/
-# 自動フォーマット
-$ fantomas src/ tests/
-```
-### コードスタイル例
-Fantomas はデフォルトで F# のスタイルガイドに従ったフォーマットを適用します。
-```fsharp
-// Before（手動フォーマット）
-let generate(number:int):string=match(number%3,number%5)with|(0,0)->"FizzBuzz"|(0,_)->"Fizz"|(_,0)->"Buzz"|_->string number
-// After（Fantomas 適用後）
-let generate (number: int) : string =
-    match (number % 3, number % 5) with
-    | (0, 0) -> "FizzBuzz"
-    | (0, _) -> "Fizz"
-    | (_, 0) -> "Buzz"
-    | _ -> string number
-```
-## 5.4 FSharpLint によるコード複雑度チェック
-### 循環的複雑度（Cyclomatic Complexity）
-FSharpLint には **FL0071**（CyclomaticComplexity）ルールが内蔵されており、関数の循環的複雑度を計測できます。
-> 循環的複雑度とは、コードの線形独立なパスの数を数値化した指標です。条件分岐（`if`/`elif`/`else`）、`match` 式のケース、`for`/`while` ループ、条件内のブール演算子によってインクリメントされます。
-| 複雑度の範囲 | 意味 |
-|-------------|------|
-| 1〜7 | 低複雑度: 管理しやすく、問題なし |
-| 8〜15 | 中程度の複雑度: リファクタリングを検討 |
-| 16〜25 | 高複雑度: リファクタリングが強く推奨される |
-| 26 以上 | 非常に高い複雑度: 関数を分割する必要がある |
-### FSharpLint の導入
-dotnet tool としてインストールします。
-```bash
-# ローカルツールとしてインストール
-$ dotnet new tool-manifest  # 初回のみ
-$ dotnet tool install dotnet-fsharplint
-```
-### fsharplint.json による閾値設定
-プロジェクトルートに `fsharplint.json` を作成し、閾値を設定します。
-```json
-{
-    "cyclomaticComplexity": {
-        "enabled": true,
-        "config": {
-            "maxComplexity": 7
-        }
-    }
-}
-```
-他言語の複雑度チェック（C# の SonarAnalyzer `S3776`、Rust の Clippy `cognitive-complexity-threshold = 7`、PHP の PHPMD `reportLevel: 7`、Python の Ruff `max-complexity = 7`）と同じ基準値 **7** を設定します。
-### 実行してみる
-```bash
-# 複雑度チェック
-$ dotnet dotnet-fsharplint lint --lint-config fsharplint.json FizzBuzzFSharp/Library.fs
-========== Linting FizzBuzzFSharp/Library.fs ==========
-========== Finished: 0 warnings ==========
-========== Summary: 0 warnings ==========
-```
-現在の FizzBuzz 実装では、各関数が短く単純なため、閾値 7 を超える関数はありません。
-### 複雑度違反の例
-閾値を超えるとこのように検出されます。
-```
-The cyclomatic complexity of this section is 8, which exceeds the maximum
-suggested complexity of 7.
-Error on line 4 starting at column 8
-    let complexFunction x =
-        ^
-See https://fsprojects.github.io/FSharpLint/how-tos/rules/FL0071.html
-```
-### F# で複雑度を低く保つコツ
-F# の `match` 式は判別共用体のケースごとに複雑度がカウントされます。ヘルパー関数に分割することで複雑度を低く保てます。
-```fsharp
-// ヘルパー関数で複雑度を分散
-let private isFizz number = number % 3 = 0
-let private isBuzz number = number % 5 = 0
-let private isFizzBuzz number = isFizz number && isBuzz number
-```
-### Cake への追加
-`build.cake` に FSharpLint タスクを追加します。
-```csharp
-Task("FSharpLint")
-    .Does(() =>
-{
-    var exitCode = StartProcess("dotnet", new ProcessSettings
-    {
-        Arguments = "dotnet-fsharplint lint --lint-config fsharplint.json FizzBuzzFSharp/Library.fs"
-    });
-    if (exitCode != 0)
-    {
-        throw new Exception("FSharpLint チェックに失敗しました。F# コードの複雑度を下げてください。");
-    }
-    Information("FSharpLint チェック: OK（全関数が閾値以下）");
-});
-Task("Check")
-    .IsDependentOn("Test")
-    .IsDependentOn("Complexity")
-    .IsDependentOn("FSharpLint");
-```
-`dotnet dotnet-cake --target=FSharpLint` で F# の複雑度チェックを単独実行、`dotnet dotnet-cake --target=Check` で C#/F# 両方の全品質チェックをまとめて実行できます。
-### 他言語との比較
-| 言語 | 複雑度チェックツール | 設定 |
-|------|---------------------|------|
-| F# | FSharpLint（FL0071） | `fsharplint.json: maxComplexity: 7` |
-| C# | SonarAnalyzer（S3776） | `.editorconfig: dotnet_diagnostic.S3776.severity = warning` |
-| Rust | Clippy（cognitive_complexity） | `clippy.toml: cognitive-complexity-threshold = 7` |
-| PHP | PHPMD | `reportLevel: 7` |
-| Java | PMD | `CyclomaticComplexity` |
-| Python | Ruff（McCabe） | `max-complexity = 7` |
-| TypeScript | ESLint | `complexity: ["error", { max: 7 }]` |
-| Ruby | RuboCop | `Metrics/CyclomaticComplexity` |
-| Go | golangci-lint（gocognit） | `.golangci.yml: gocognit.min-complexity: 7` |
-## 5.5 コードカバレッジ
-### coverlet によるカバレッジ計測
-coverlet は .NET のクロスプラットフォームカバレッジツールです。
-```bash
-# カバレッジ付きでテスト実行
-$ dotnet test --collect:"XPlat Code Coverage"
-```
-テスト結果は `TestResults/` ディレクトリに Cobertura XML 形式で出力されます。
-## 5.6 他言語との比較
-| ツール | 役割 | 他言語の対応ツール |
-|--------|------|-------------------|
-| NuGet | パッケージ管理 | npm, Bundler, Cargo, Go Modules |
-| Fantomas | コードフォーマット | Prettier, rustfmt, gofmt, Ruff |
-| FSharpLint（FL0071） | コード複雑度チェック | Clippy cognitive_complexity, SonarAnalyzer S3776, PHPMD |
-| coverlet | カバレッジ計測 | c8, tarpaulin, go test -cover |
-## 5.7 まとめ
-この章では以下を導入しました。
-| ツール | 役割 |
-|--------|------|
-| NuGet | パッケージ管理と依存関係の解決 |
-| .fsproj | F# プロジェクトの設定とファイル順序管理 |
-| Fantomas | F# コードの自動フォーマット |
-| FSharpLint | 循環的複雑度チェック（閾値 7） |
-| coverlet | テストカバレッジの計測 |
-次章では、これらのツールを **タスクランナー**（Cake）でまとめて実行できるようにし、**CI/CD** パイプラインを構築します。