dotnet-api-docs

Name: dotnet-api-docs
Author: wshaddix

github.com/wshaddix開発8677 回インストール35 週間前に更新

リポジトリ

dotnet-api-docs について

.NETプロジェクトのAPIドキュメント生成を支援するスキルです。DocFXによるリファレンスやOpenAPIの対話型ドキュメントに加え、同期検証とバージョン管理の方法を扱います。

主な機能

01アセンブリからDocFXリファレンスを生成
02テンプレートとページ間リンクのカスタマイズ
03ScalarまたはSwagger UIの埋め込み
04ドキュメントとリンクの検証
05バージョン別ドキュメントと移行ガイドの管理

活用シーン

01.NETライブラリのAPIリファレンスサイト構築
02OpenAPI仕様を対話型ドキュメントとして表示
03CIでコメント不足やリンク切れを検出

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wshaddix/dotnet-skills --skill dotnet-api-docs

インストール後、Claude Code で/dotnet-api-docsを入力して読み込まれたか確認します。

詳細

dotnet-api-docs

.NET プロジェクト向けの API ドキュメント生成：アセンブリからの API リファレンス作成に向けた DocFX の設定（docfx.json の構成、メタデータの抽出、テンプレートのカスタマイズ、相互参照）、常に最新の API ドキュメントとしての OpenAPI 仕様（Scalar と Swagger UI の埋め込み、バージョン管理された OpenAPI ドキュメント）、ドキュメントとコードの同期（-warnaserror:CS1591 による CI 検証、リンク切れの検出、PR でのドキュメントビルドの自動化）、API 変更履歴のパターン（破壊的変更のドキュメント化、移行ガイド、非推奨 API の追跡）、バージョン管理された API ドキュメント（バージョンセレクター、複数バージョンの保守、URL パターン）。

バージョンの前提： DocFX v2.x（コミュニティーによる保守）。Microsoft.AspNetCore.OpenApi による OpenAPI 3.x（.NET 9 以降に組み込み）。最新の OpenAPI 可視化には Scalar UI を使用。コード例は .NET 8.0 以降を基準とします。

スコープの境界： このスキルの対象は、コードからの API ドキュメント生成、つまりソースコード、XML コメント、OpenAPI 仕様を閲覧可能なドキュメントに変換するツールとプロセスです。XML ドキュメントコメントの構文と作成規約は [skill:dotnet-xml-docs] の対象です。OpenAPI 仕様の生成と Swashbuckle からの移行は [skill:dotnet-openapi] の対象です。ドキュメントサイトの CI/CD デプロイは [skill:dotnet-gha-deploy] の対象です。ドキュメントプラットフォームの選定（Starlight、DocFX、Docusaurus）は [skill:dotnet-documentation-strategy] の対象です。

対象外： XML ドキュメントコメントの構文と作成については、[skill:dotnet-xml-docs] を参照してください。OpenAPI 仕様の生成と設定（Swashbuckle、Microsoft.AspNetCore.OpenApi のセットアップ）については、[skill:dotnet-openapi] を参照してください。ドキュメントサイトの CI/CD デプロイパイプラインについては、[skill:dotnet-gha-deploy] を参照してください。ドキュメントプラットフォームの選定と初期セットアップについては、[skill:dotnet-documentation-strategy] を参照してください。変更履歴の生成ツールと SemVer バージョン管理については、[skill:dotnet-release-management] を参照してください。

相互参照：[skill:dotnet-xml-docs] は XML ドキュメントコメントの作成、[skill:dotnet-openapi] は OpenAPI の生成、[skill:dotnet-gha-deploy] はドキュメントサイトのデプロイパイプライン、[skill:dotnet-documentation-strategy] はプラットフォームの選定、[skill:dotnet-release-management] は変更履歴ツールとバージョン管理について参照してください。

.NET API リファレンス向けの DocFX セットアップ

DocFX は、.NET アセンブリと XML ドキュメントコメントから直接 API リファレンスドキュメントを生成します。.NET プロジェクトからネイティブに docfx metadata で情報を抽出できる唯一のドキュメントツールです。

インストール

# Install DocFX as a .NET global tool
dotnet tool install -g docfx

# Or as a local tool (recommended for team consistency)
dotnet new tool-manifest
dotnet tool install docfx

設定（`docfx.json`）

{
  "metadata": [
    {
      "src": [
        {
          "files": ["src/**/*.csproj"],
          "exclude": ["**/bin/**", "**/obj/**"],
          "src": ".."
        }
      ],
      "dest": "api",
      "properties": {
        "TargetFramework": "net8.0"
      },
      "disableGitFeatures": false,
      "disableDefaultFilter": false
    }
  ],
  "build": {
    "content": [
      {
        "files": ["api/**.yml", "api/index.md"]
      },
      {
        "files": [
          "articles/**.md",
          "articles/**/toc.yml",
          "toc.yml",
          "*.md"
        ]
      }
    ],
    "resource": [
      {
        "files": ["images/**"]
      }
    ],
    "dest": "_site",
    "globalMetadataFiles": [],
    "fileMetadataFiles": [],
    "template": ["default", "modern"],
    "postProcessors": ["ExtractSearchIndex"],
    "markdownEngineName": "markdig",
    "noLangKeyword": false,
    "keepFileLink": false,
    "cleanupCacheHistory": false,
    "disableGitFeatures": false,
    "globalMetadata": {
      "_appTitle": "My.Library API Reference",
      "_appFooter": "Copyright 2024 My Company",
      "_enableSearch": true,
      "_enableNewTab": true
    }
  }
}

メタデータの抽出

metadata セクションでは、DocFX が .NET プロジェクトから API 情報を抽出する方法を制御します。

# Generate API metadata YAML files from projects
docfx metadata docfx.json

# This creates YAML files in the api/ directory:
#   api/MyLibrary.WidgetService.yml
#   api/MyLibrary.Widget.yml
#   api/toc.yml

主なメタデータ設定オプション：

プロパティ	用途	既定値
`src.files`	抽出元のプロジェクトファイル	必須
`dest`	YAML の出力ディレクトリ	`api`
`properties.TargetFramework`	ビルド対象の TFM	プロジェクトの既定値
`disableGitFeatures`	git blame 情報をスキップ	`false`
`filter`	API フィルター YAML へのパス	なし（すべてのパブリック API）

API のフィルタリング

生成されるドキュメントから内部型を除外します。

# filterConfig.yml
apiRules:
  - exclude:
      uidRegex: ^MyLibrary\.Internal\.
      type: Namespace
  - exclude:
      hasAttribute:
          uid: System.ComponentModel.EditorBrowsableAttribute
          ctorArguments:
            - System.ComponentModel.EditorBrowsableState.Never

docfx.json でフィルターを参照します。

{
  "metadata": [
    {
      "filter": "filterConfig.yml"
    }
  ]
}

テンプレートのカスタマイズ

DocFX は、独自のブランディング向けにテンプレートをオーバーライドできます。

docs/
  templates/
    custom/
      styles/
        main.css          # Custom CSS overrides
      partials/
        head.tmpl.partial # Custom head section (analytics, fonts)
        footer.tmpl.partial

docfx.json でカスタムテンプレートを参照します。

{
  "build": {
    "template": ["default", "modern", "templates/custom"]
  }
}

ページ間の相互参照

DocFX は、API ページと概念記事の間で uid ベースの相互参照をサポートしています。


See the @MyLibrary.WidgetService.CreateWidgetAsync(System.String) method for details.

For the full API, see <xref:MyLibrary.WidgetService>.

# In an API YAML override file (api/MyLibrary.WidgetService.yml)
# Add links to conceptual articles
references:
  - uid: MyLibrary.WidgetService
    seealso:
      - linkId: ../articles/getting-started.md
        commentId: getting-started

ドキュメントとしての OpenAPI 仕様

生成された OpenAPI 仕様は、コードと常に同期する最新の API ドキュメントとして機能します。このセクションでは、OpenAPI の出力をドキュメントとして使用する方法を扱います。OpenAPI の生成と設定については、[skill:dotnet-openapi] を参照してください。

Scalar UI の埋め込み

Scalar は、最新のインタラクティブな API ドキュメントビューアーを提供します。

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOpenApi();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.MapOpenApi();         // Serves OpenAPI JSON at /openapi/v1.json
    app.MapScalarApiReference(options =>
    {
        options.WithTitle("My API Documentation")
               .WithTheme(ScalarTheme.Purple)
               .WithDefaultHttpClient(ScalarTarget.CSharp, ScalarClient.HttpClient);
    });
}

app.Run();

Scalar は OpenAPI 仕様をインタラクティブなドキュメントページとしてレンダリングし、次の機能を備えています。

タグによるエンドポイントのグループ化
リクエスト／レスポンスの例
認証設定
エンドポイントをテストする「試してみる」機能

Swagger UI の埋め込み

Swashbuckle を使用するプロジェクトや、従来の Swagger UI が必要なプロジェクト向けです。

if (app.Environment.IsDevelopment())
{
    app.UseSwaggerUI(options =>
    {
        options.SwaggerEndpoint("/openapi/v1.json", "My API v1");
        options.RoutePrefix = "api-docs";
        options.DocumentTitle = "My API Documentation";
        options.DefaultModelsExpandDepth(-1); // Hide schemas by default
    });
}

バージョン管理された OpenAPI ドキュメント

異なる API バージョン用に複数の OpenAPI ドキュメントを提供します。

builder.Services.AddOpenApi("v1", options =>
{
    options.AddDocumentTransformer((document, context, ct) =>
    {
        document.Info.Version = "1.0";
        document.Info.Title = "My API";
        return Task.CompletedTask;
    });
});

builder.Services.AddOpenApi("v2", options =>
{
    options.AddDocumentTransformer((document, context, ct) =>
    {
        document.Info.Version = "2.0";
        document.Info.Title = "My API";
        return Task.CompletedTask;
    });
});

// Serves /openapi/v1.json and /openapi/v2.json
app.MapOpenApi();

静的ドキュメント用の OpenAPI エクスポート

ビルド時に OpenAPI 仕様をエクスポートし、静的ドキュメントサイトで使用します。

# Generate OpenAPI spec from the running application
dotnet run -- --urls "http://localhost:5099" &
APP_PID=$!
sleep 3
curl -s http://localhost:5099/openapi/v1.json > docs/openapi/v1.json
kill $APP_PID

または、Microsoft.Extensions.ApiDescription.Server パッケージを使用して、ビルド時に生成します。

<PackageReference Include="Microsoft.Extensions.ApiDescription.Server" Version="8.0.0">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
</PackageReference>

<PropertyGroup>
  <OpenApiGenerateDocuments>true</OpenApiGenerateDocuments>
  <OpenApiDocumentsDirectory>$(MSBuildProjectDirectory)/../docs/openapi</OpenApiDocumentsDirectory>
</PropertyGroup>

OpenAPI の生成設定と Swashbuckle の移行について詳しくは、[skill:dotnet-openapi] をご覧ください。

XML コメントからのドキュメントサイト生成

XML ドキュメントから DocFX（静的 HTML）へ

ライブラリの API リファレンスドキュメントに使用する主要なパイプラインです。

Source Code (.cs files)
    |
    v
XML Doc Comments (/// <summary>...)
    |
    v
Build with GenerateDocumentationFile=true
    |
    v
XML Doc File (MyLibrary.xml)
    |
    v
docfx metadata (extracts API structure)
    |
    v
YAML Files (api/*.yml)
    |
    v
docfx build (generates HTML)
    |
    v
Static HTML Site (_site/)

XML ドキュメントコメントを作成する際のベストプラクティスについては、[skill:dotnet-xml-docs] をご覧ください。

XML ドキュメントから Starlight へ（Markdown 抽出経由）

DocFX ではなく Starlight を使用するプロジェクトでは、API ドキュメントを Markdown として抽出します。

<GenerateDocumentationFile>true</GenerateDocumentationFile> を指定して XML ドキュメントファイルを生成します
変換ツールを使用して XML ドキュメントを Markdown ページに変換します
- xmldoc2md（コミュニティツール）：XML ドキュメントファイルを Markdown に変換します
- カスタムスクリプト：XML ファイルを解析し、各型の Markdown ページを生成します

# Using xmldoc2md
dotnet tool install -g XMLDoc2Markdown
xmldoc2md MyLibrary.dll docs/src/content/docs/reference/

# Output: one Markdown file per type in the reference/ directory

Starlight のビルドに含めます：

docs/src/content/docs/
  reference/
    MyLibrary.WidgetService.md    # Auto-generated from XML docs
    MyLibrary.Widget.md
    MyLibrary.WidgetStatus.md

リファレンスディレクトリからサイドバーを自動生成するよう設定します。

// astro.config.mjs
sidebar: [
  {
    label: 'API Reference',
    autogenerate: { directory: 'reference' },
  },
],

ドキュメントとコードの同期を維持する

CI でのドキュメント完全性の検証

CS1591 をエラーとして扱い、CI で XML ドキュメントの完全性を徹底します。


<PropertyGroup>
  <GenerateDocumentationFile>true</GenerateDocumentationFile>
</PropertyGroup>


<PropertyGroup Condition="'$(IsPublicLibrary)' == 'true'">
  <WarningsAsErrors>$(WarningsAsErrors);CS1591</WarningsAsErrors>
</PropertyGroup>

# CI command: build with warnings-as-errors for doc completeness
dotnet build -warnaserror:CS1591

これにより、XML ドキュメントがないパブリックメンバーがあるとビルドが失敗します。IsPublicLibrary 条件（またはプロジェクトごとの設定）を使用して、テストプロジェクトや内部ツールではなく、公開する NuGet パッケージにのみ適用します。

リンク切れの検出

CI でドキュメントのリンクを検証します。

# Build DocFX and check for broken cross-references
docfx build docfx.json --warningsAsErrors

# DocFX reports broken xref links as warnings -- the flag promotes them to errors

Starlight または Docusaurus のサイトでは、ビルド後にリンクチェッカーを使用します。

# Build the doc site
npm run build

# Check for broken links in the built output
npx broken-link-checker-local ./_site --recursive

PR でのドキュメントの自動ビルド

デプロイせずに、すべてのプルリクエストでドキュメントのビルドを検証します。デプロイワークフローの設定については、[skill:dotnet-gha-deploy] をご覧ください。通常、検証ステップは CI ワークフローの一部として実行されます。

# In CI: verify docs build without errors
dotnet build -warnaserror:CS1591          # XML doc completeness
docfx metadata docfx.json                 # API metadata extraction
docfx build docfx.json --warningsAsErrors # Full doc site build

これにより、ドキュメントの回帰（ドキュメントの欠落、相互参照のリンク切れなど）をメインブランチに取り込む前に検出できます。

API 変更履歴のパターン

破壊的変更のドキュメント化

利用者がすばやく確認できるよう、構造化された形式で破壊的変更を記録します。

## Breaking Changes in v3.0

### Removed APIs

| API | Replacement | Migration |
|-----|-------------|-----------|
| `WidgetService.Create(string)` | `WidgetService.CreateAsync(string, CancellationToken)` | Add `await` and `CancellationToken` parameter |
| `Widget.Name` setter | `WidgetService.RenameAsync(Guid, string)` | Use service method instead of direct property mutation |
| `IWidgetRepository` (interface) | `IWidgetRepository<T>` (generic) | Update implementations to use generic interface |

### Changed Behavior

- `WidgetService.CreateAsync` now validates name uniqueness within a category.
  Previously, duplicate names were silently allowed.
- `Widget.Status` defaults to `Draft` instead of `Active`.
  Existing code that assumes newly created widgets are active must call `widget.Activate()`.

### New Required Dependencies

- `Microsoft.Extensions.Caching.Memory` is now a required dependency for `WidgetService`.
  Register with `builder.Services.AddMemoryCache()`.

メジャーバージョン間の移行ガイド

必要な作業ごとに移行ガイドを構成します。

# Migrating from v2.x to v3.0

## Step 1: Update Package References

```xml

<PackageReference Include="My.Library" Version="2.*" />


<PackageReference Include="My.Library" Version="3.0.0" />

ステップ 2：コンパイルエラーを修正する

非同期 API の変更

同期メソッドはすべて削除されています。同期呼び出しを非同期の代替手段に置き換えます。

// Before (v2.x)
var widget = service.Create("name");

// After (v3.0)
var widget = await service.CreateAsync("name", cancellationToken);

ジェネリックリポジトリインターフェイス

// Before (v2.x)
public class MyRepo : IWidgetRepository { }

// After (v3.0)
public class MyRepo : IWidgetRepository<Widget> { }

ステップ 3：動作に関する前提を更新する

作成後に Widget.Status == Active であることを前提とするコードパスをすべて確認します
DI の登録に builder.Services.AddMemoryCache() を追加します


### Deprecated API Tracking

Use the `[Obsolete]` attribute with message pointing to the replacement. Document deprecation timelines:

```csharp
/// <summary>
/// Creates a widget synchronously.
/// </summary>
/// <remarks>
/// This method will be removed in v4.0. Use
/// <see cref="CreateAsync(string, CancellationToken)"/> instead.
/// </remarks>
[Obsolete("Use CreateAsync instead. This method will be removed in v4.0.", error: false)]
public Widget Create(string name)
{
}

非推奨 API は専用のドキュメントで管理します。

# Deprecated APIs

| API | Deprecated In | Removed In | Replacement |
|-----|---------------|------------|-------------|
| `WidgetService.Create(string)` | v2.5 | v4.0 (planned) | `CreateAsync(string, CancellationToken)` |
| `Widget.Name` setter | v3.0 | v4.0 (planned) | `WidgetService.RenameAsync(Guid, string)` |
| `WidgetOptions.EnableCache` | v3.1 | v5.0 (planned) | `WidgetOptions.CachePolicy` |

変更履歴の形式に関する規約と SemVer のバージョニング戦略については、[skill:dotnet-release-management] をご覧ください。

バージョン管理された API ドキュメント

ドキュメントサイトのバージョンセレクター

DocFX のバージョン管理されたドキュメント：

DocFX は、異なるプロジェクトのバージョンを対象にすることで、バージョン固有のメタデータ抽出をサポートしています。

{
  "metadata": [
    {
      "src": [{ "files": ["src/**/*.csproj"], "src": ".." }],
      "dest": "api/v2",
      "properties": { "TargetFramework": "net8.0" },
      "globalNamespaceId": "v2"
    }
  ]
}

メジャーバージョンごとにブランチまたはタグを分けて管理し、それぞれからドキュメントをビルドします。

# Build docs for v2.x (current branch)
docfx build docfx.json

# Build docs for v1.x (from tag)
git checkout v1.x
docfx build docfx.json --output _site/v1
git checkout main

Starlight のバージョン管理されたドキュメント：

ディレクトリベースのバージョン管理、または @lorenzo_lewis/starlight-utils プラグインを使用します。Starlight のバージョン管理の設定については、[skill:dotnet-documentation-strategy] を参照してください。

Docusaurus のバージョン管理されたドキュメント：

Docusaurus には、npx docusaurus docs:version によるバージョン管理機能が組み込まれています。Docusaurus のバージョン管理の設定については、[skill:dotnet-documentation-strategy] を参照してください。

複数のアクティブなバージョンのドキュメントを管理する

複数のアクティブなメジャーバージョンを同時にサポートする場合：

メジャーバージョンごとのブランチ戦略： メインブランチに docs/v1、docs/v2 ディレクトリを維持するか、v1.x、v2.x ブランチを分けて管理します
概念に関する共通ドキュメント： バージョンに依存しないガイド（アーキテクチャ、概念）は共通の場所に置き、バージョン固有の API リファレンスは別のディレクトリに置きます
バージョンバナー： 古いバージョンのドキュメントに、最新バージョンを案内する通知バナーを追加します

URL パターン

バージョン管理された API ドキュメントでは、一貫性のある URL パターンを使用します。

https://docs.mylib.dev/                     # Latest stable version
https://docs.mylib.dev/v2/                  # Specific version
https://docs.mylib.dev/v2/api/WidgetService # Specific type in specific version
https://docs.mylib.dev/latest/              # Alias for latest stable
https://docs.mylib.dev/next/                # Pre-release / unreleased docs

バージョン指定のない URL が最新の安定バージョンを指すようにリダイレクトを設定します。これにより、新しいバージョンの公開後も既存のリンクを有効に保てます。

エージェントが注意すべき点

OpenAPI 仕様の設定を生成しないでください -- OpenAPI 生成のセットアップ（builder.Services.AddOpenApi()、ドキュメントトランスフォーマー、Swashbuckle の移行）は [skill:dotnet-openapi] の対象です。このスキルでは、生成された OpenAPI 出力をドキュメントとして使用する方法を扱います。
XML ドキュメントコメントの構文ガイダンスを書かないでください -- XML タグの構文、規約、<inheritdoc>、GenerateDocumentationFile は [skill:dotnet-xml-docs] の対象です。このスキルでは、XML ドキュメントから生成されたドキュメントサイトまでのパイプラインを扱います。
CI デプロイ用 YAML を生成しないでください -- ドキュメントサイトのデプロイワークフロー（GitHub Pages のアクション、DocFX のデプロイ）は [skill:dotnet-gha-deploy] の対象です。このスキルでは、ドキュメントのビルド検証とローカルでの生成を扱います。
docfx metadata にはビルド可能なプロジェクトが必要です -- DocFX が API メタデータを抽出するには、プロジェクトが正常にコンパイルされる必要があります。CI パイプラインでは、必ず docfx metadata の前に dotnet build を実行してください。
DocFX は 2022 年 11 月以降、コミュニティによって保守されています -- Microsoft はリポジトリを移管しました。現在も活発に保守され、広く使用されています。代替案を検討する新規プロジェクトについては、[skill:dotnet-documentation-strategy] を参照してください。
DocFX の modern テンプレートには v2.75 以降が必要です -- それ以前のバージョンでは、Mermaid のサポートや最新のスタイルが含まれない default テンプレートが使用されます。インストール済みのバージョンは docfx --version で確認してください。
-warnaserror:CS1591 は公開ライブラリのプロジェクトだけに適用してください -- テストプロジェクト、コンソールアプリ、内部ツールに適用すると、不必要なドキュメント作成の負担が生じます。MSBuild の条件を使用して、公開パッケージだけを対象にしてください。
filterConfig.yml による API フィルタリングでは、名前空間文字列ではなく UID 正規表現を使用します -- パターン ^MyLibrary\.Internal\. は、そのプレフィックスで始まる UID に一致します。docfx metadata --log verbose でフィルターパターンをテストし、正しくフィルタリングされることを確認してください。
破壊的変更のドキュメントには、移行用のコード例を含める必要があります -- 置き換え後のコードを示さず、削除された API を列挙するだけの表では不十分です。必ず変更前と変更後のコードスニペットを含めてください。
バージョン管理されたドキュメントの URL では、バージョン指定のないパスを最新の安定バージョンへリダイレクトする必要があります -- 新しいバージョンを公開するときに、既存のリンクを壊さないでください。サーバー側のリダイレクト、またはルート URL にクライアント側のリダイレクトページを設定してください。
OpenAPI UI（Scalar、Swagger UI）は開発環境でのみ公開してください -- MapScalarApiReference と UseSwaggerUI は、if (app.Environment.IsDevelopment()) のガードで囲みます。インタラクティブな API ドキュメントを本番環境で公開することは、セキュリティ上の考慮事項です。

Markdown 対応

ログインしてコメント

基本情報

作者: wshaddix
リポジトリ: wshaddix/dotnet-skills
カテゴリ: 開発
インストール数: 77
GitHub スター: 86

問題を報告

dotnet-api-docs

dotnet-api-docs について

主な機能

活用シーン

インストール

詳細

dotnet-api-docs

.NET API リファレンス向けの DocFX セットアップ

インストール

設定（docfx.json）

メタデータの抽出

API のフィルタリング

テンプレートのカスタマイズ

ページ間の相互参照

ドキュメントとしての OpenAPI 仕様

Scalar UI の埋め込み

Swagger UI の埋め込み

バージョン管理された OpenAPI ドキュメント

静的ドキュメント用の OpenAPI エクスポート

XML コメントからのドキュメントサイト生成

XML ドキュメントから DocFX（静的 HTML）へ

XML ドキュメントから Starlight へ（Markdown 抽出経由）

ドキュメントとコードの同期を維持する

CI でのドキュメント完全性の検証

リンク切れの検出

PR でのドキュメントの自動ビルド

API 変更履歴のパターン

破壊的変更のドキュメント化

メジャーバージョン間の移行ガイド

ステップ 2：コンパイルエラーを修正する

非同期 API の変更

ジェネリックリポジトリインターフェイス

ステップ 3：動作に関する前提を更新する

バージョン管理された API ドキュメント

ドキュメントサイトのバージョンセレクター

複数のアクティブなバージョンのドキュメントを管理する

URL パターン

エージェントが注意すべき点

コメント

設定（`docfx.json`）