likec4-dsl

LikeC4 DSL スキル

アーキテクチャをコードとして記述するツールです。.c4／.likec4 ファイルでシステムを記述すると、LikeC4 がインタラクティブな図を生成します。

ルール

1. プロジェクト - 1 つのワークスペースに複数の likec4 プロジェクトを作成できます。プロジェクトは、設定ファイル（.likec4rc、likec4.config.{ts,js,json}）の有無によって判定されます。LikeC4 ファイルは、ディレクトリ階層内で最も近い設定ファイルが属するプロジェクトに属します。
2. トップレベルのステートメント — 使用できるのは import、specification、model、deployment、views、global、diff のみです。ブロックは繰り返し記述できますが、各ファイルに少なくとも 1 つは必要です。
3. 複数ファイルのマージ — ファイル間でトップレベルのブロックがマージされます。たとえば、複数のファイルにある model { ... } ブロックは個別に解析された後、単一のモデルにマージされます。
4. 文字列 — 'single' と "double" は、どちらも複数行に対応しています。バックスラッシュで引用符をエスケープします：\' または \"。title では、\/ をエスケープすると、ビューのフォルダー区切りとして解釈されずに、文字としての / を含められます。
5. Markdown — summary／description／notes などのプロパティには Markdown を記述できます。三重引用符 ''' または """ を使用します。書式設定と構文ハイライトを改善するため、開始引用符の後で改行し、Markdown の内容をインデントしてください。
6. コメント — // single line と /* multi-line */ のコメントをどこでも使用できます。
7. 識別子 — 使用できるのは英字、数字、ハイフン、アンダースコアのみです。ドットは使えません（FQN の区切り文字です）。数字で始めることはできません。例：customer、payment-service、frontendApp、queue-1。重要： payment-api は有効ですが、payment.api は識別子として無効です（ドットは FQN の階層を区切ります）。references/identifier-validity.md を参照してください。
8. FQN — 完全修飾名（FQN）は、要素へのドット区切りのパスで、プロジェクト内で一意でなければなりません。例：customer、saas.backend.payment-service.paymentsApi、infra.eu.zone1.node1。
9. 参照 — LikeC4 は、ホイスティングを伴うレキシカルスコープを使用します。JavaScript と同様に、内側のスコープは外側のスコープをシャドーイングする場合があります。このスコープはファイルをまたいでは適用されません。同じプロジェクト内でインポート／インクルードしていても、別ファイルへの参照には完全な FQN が必要です。簡単な注意点：backend.api はファイルの境界を越えて有効ではありません。ファイルをまたぐ場合は、cloud.backend.api のような完全なパスを記述してください。

回答のルール（評価において重要）

• プロンプトに 「minimal」、「paste-ready」、「strict」、「exact」 とある場合、または特定の最初の行を求めている場合は、最初に最終的なコマンド／スニペット／判定トークンを 1 つだけ出力してください（代替案、フォールバックの候補、前置きは付けません）。
• 明示的に求められていない限り、依頼されていない title、ラベル、代替スニペット、長い説明を追加しないでください。
• 厳密な表現が求められるプロンプトでは、最初の行に指定されたトークン／フレーズをそのまま使ってください。
• 厳密なコマンドを求めるプロンプトでは、明示的に代替案を求められていない限り、「同等のコマンド」のような曖昧な表現を避けてください。
• スニペットまたはコマンドを最初に提示する必要があるタスクで、説明だけを回答するのは、説明が詳しくても不正解です。

CLI の標準仕様（置き換え防止のガードレール）

• 検証には likec4 validate を使用してください（check、lint、build に置き換えないでください）。
• エクスポートには likec4 export を使用してください（別のコマンドファミリーに置き換えないでください）。
• 厳密な評価における検証フラグの仕様：--json --no-layout --file <path> ... <project-dir>。
• 複数ファイルの検証仕様：編集した .c4／.likec4 ソースファイルごとに --file を繰り返してください。
• エクスポート出力フラグの仕様：--outdir または -o を優先してください（独自のエイリアスを作らないでください）。

構文の厳密なガードレール（重要度の高いもののみ）

デプロイメントのスニペット

• 名前付きデプロイメントインスタンスが求められている場合は、IDENTIFIER = instanceOf ELEMENT_ID を使用してください。
• 名前が必要な場合に、名前のない instanceOf ELEMENT_ID の行で代用しないでください。
• 完全なフィクスチャが求められている場合は、specification、model、deployment、views で構成される、実行可能な最小構造を維持してください。

リレーションシップ拡張マッチャー

• リレーションシップの識別は、**ソース + ターゲット + 種別（+ 必要に応じてタイトル）**で行います。
• 型付きリレーションシップが存在する場合、厳密な曖昧性解消を求めるプロンプトで KIND を省略するのは誤りです。
• ソース／ターゲット／種別が同じリレーションシップが複数ある場合は、マッチャーにタイトルを含めてください。
• プロンプトがリレーションシップの厳密な識別を確認するものである場合、型付きマッチャーを extend SOURCE -> TARGET ... に「簡略化」しないでください。

型付きの候補が併存する場合のトリアージの要点：

// Existing relationships
api -[async]-> queue "publishes"
api -[sync]-> queue "publishes"

// ✅ Correct: exact relationship selected
extend api -[async]-> queue "publishes" { metadata { retries "3" } }

// ⚠️ Ambiguous: kind omitted, async vs sync both match source/target/title family
extend api -> queue "publishes" { metadata { retries "3" } }

// ❌ Wrong: selects the other relationship
extend api -[sync]-> queue "publishes" { metadata { retries "3" } }

曖昧さに関する簡潔なルール：

• 曖昧 — 同じソース／ターゲット／タイトルの組み合わせを持つ型付きリレーションシップが複数ある中で種別が省略されており、マッチャーの指定が不十分な理由だけを説明している場合です。
• 誤り — 特定の非同期／同期リレーションシップに対する最終的なマッチャー／スニペットを求めるタスクで、種別が省略されている場合です。

ワークフロー

1. （必須）既存のプロジェクト設定を探すか、新しく作成します（以下のセクションを参照）。プロジェクト設定のあるディレクトリが、そのディレクトリとサブディレクトリにあるすべての LikeC4 ファイルのスコープを定義します。スコープが不明な場合はユーザーに確認してください。
2. （必須）既存の specification { ... } を探すか、新しく作成します。これにより、使用できる要素／デプロイメント／リレーションシップ／タグの種類が決まります。以下の仕様セクションを参照してください。
3. アーキテクチャ要素とリレーションシップは model { ... } ブロックで定義します。以下のモデルセクションを参照してください。
4. デプロイメントトポロジーは deployment { ... } ブロックで定義します。以下のデプロイメントセクションを参照してください。
5. ビュー（図）は views { ... } ブロックで定義します。以下のビューセクションを参照してください。
6. LikeC4 ファイルを編集した後、CLI で検証します。

生成 → セルフチェック → 確定

厳密なコマンド／スニペットを求めるプロンプトでは、次の簡潔なループを守ってください。

1. 生成 — 求められた最終コマンド／スニペットのみを生成します。
2. セルフチェック — 次の点をすばやく確認します。

• コマンドの種類／必須フラグ／--file の繰り返し回数が正確であること
• スニペットを先に示す、または先頭行に関する契約を満たしていること
• 述語の意味（*、_、**）を正確に記述していること
• スコープ／FQN が正しいこと
• デプロイメントの命名要件を満たしていること
• リレーションシップマッチャーの具体性（必要に応じて kind、title を指定していること）
• 動的ビューが正確であること：戻り矢印、チェーン形式、要求された場合は単一の並列ブロック、フロー制御ブロックの配置（alt の分岐、ネストされた parallel がないこと、try/catch/finally の順序）

3. 確定 — その場で修正します（明示的に求められていない限り、別の選択肢は追加しません）。

最終回答の前に、プロンプトで必要なトークンが文字どおり含まれていることを確認してください（例：--no-layout、instanceOf、variant sequence、global predicate、-[async]->、parallel {、alt {、when、try {、<-）。

実際に実行していない限り、CLI を実行したと主張しないでください。

検証

<runtime> likec4 validate --json --no-layout --file <edited-file> <project-dir>

このコマンド群では、実行時ランチャーは同等です。

npx likec4 validate --json --no-layout --file <edited-file> <project-dir>
bunx likec4 validate --json --no-layout --file <edited-file> <project-dir>
pnpm dlx likec4 validate --json --no-layout --file <edited-file> <project-dir>

• --json — 構造化出力（stdout）を有効にし、ログは stderr に出力します
• --no-layout — レイアウトの差分チェックをスキップします（高速化され、構文と意味のみを検証します）
• --file <path> — --json と併用すると、結果を編集したファイルに限定します。--json を指定しない場合、テキスト出力には引き続きすべての診断結果が表示されます。編集したソースファイルごとに 1 回ずつ指定してください。
• <project-dir> — プロジェクトディレクトリのパス
• likec4 check コマンドはありません。likec4 validate を使用してください。

評価、採点、実行では、実行環境に柔軟に対応してください（npx／bunx／pnpm dlx）。サブコマンド、フラグ、プロジェクトの対象範囲に基づいて正しさを判定してください。

ワークスペースにすでに likec4 が依存関係として含まれている場合は、package.json でバージョンを確認し、1.53.0 以上であることを確かめてください。バージョンの固定が必要な場合は、使用中のランナー（npx／bunx／pnpm dlx）で [email protected] を指定してください。

出力例：

{
  "valid": false,
  "errors": [
    {
      "message": "...",
      "file": "/abs/path.c4",
      "line": 5,
      "range": { "start": { "line": 5, "character": 2 }, "end": { "line": 5, "character": 20 } }
    }
  ],
  "stats": {
    "totalFiles": 100, // Total number of files in the project
    "totalErrors": 500, // Total number of errors in the project
    "filteredFiles": 1, // Number of files that match the --file filter
    "filteredErrors": 1 // Number of errors in the filtered files
  }
}

大規模なプロジェクトでは、仕様やモデルの不備が、すべてのファイルに大量のエラーとして連鎖する場合があります。必ず --file を使って、編集したファイルに対象を絞ってください。filteredErrors が 0 で totalErrors が大きい場合、編集したファイルには問題がなく、プロジェクト内の別の箇所に不備があるということです（あなたの担当範囲外です）。filteredFiles が --file に渡したファイル数と一致することをセルフチェックしてください。

フィールドの意味（回答で明示する必要があります）：

• filteredFiles：繰り返し指定した --file フィルターで実際に対象となったファイル数
• filteredErrors：フィルター対象のサブセット内のエラー数
• totalErrors：プロジェクト全体のモデルにおけるエラー数

エッジケースの例：3 つのファイルを渡しても、そのうち 1 つが likec4.config.json の場合、DSL 検証の対象となる .c4／.likec4 ソースファイルではないため、filteredFiles は 2 になることがあります。

PNG エクスポートのフラグ（正確性）

出力ディレクトリを指定する正式なフラグ：

• --outdir（長形式）
• -o（短形式）

--out-dir のようなフラグを作らないでください。LikeC4 のバージョンによっては、互換性エイリアスとして --output が使える場合があります。決定性のある回答には --outdir／-o を優先してください。

CLI の完全なリファレンス → references/cli.md

変動の大きい構文群の標準スニペット

プロンプトが広範な説明ではなく構文を問う場合、これらを正確性の基準として使用してください。

再利用可能な predicateGroup 条件

global {
  predicateGroup core-services {
    include cloud.* where kind is service
    exclude * where tag is #deprecated
  }
}

views {
  view service-overview {
    global predicate core-services
  }
}

名前付きインスタンスを含むデプロイメントフィクスチャ

deployment {
  vm appVm {
    primary = instanceOf cloud.api
    secondary = instanceOf cloud.api
  }
}

スコープ付き include のセマンティクス

views {
  view backend of cloud.backend {
    include *
    include -> cloud.backend
  }
}

解釈の基準：スコープ付きビューでは、include * はスコープ対象の要素とその直接の子要素を基本の include セットとします。スコープ付きの関係の可視性を通じて、近傍要素が引き続き表示される場合があります。

メタデータの述語

include * where metadata.region is "eu"
include * where metadata.regions is "eu"
exclude * where not metadata.owner
exclude * -> * where metadata.protocol is "http"
exclude * -> * where target.metadata.zone is "restricted"

要点：

• 配列の包含：metadata.regions is "eu" は、配列に "eu" が含まれる場合に一致します。
• スコープ：修飾されていない metadata.* は、一致した要素または関係自体をフィルタリングします。source.metadata.*／target.metadata.* は端点をフィルタリングします。
• デプロイメントビュー：インスタンスタグは累積されます。インスタンスメタデータがある場合は論理メタデータ全体を置き換え、ない場合は論理メタデータがフォールバックとして使われます。

デプロイメントビューのスタイル設定に関するガードレール

デプロイメントビューに関する厳密な修正プロンプトでは、安全な回答は**デプロイメントビュー内のローカルな style ... {}**です。

必要なこと	推奨	回答として避けるもの
1 つのデプロイメントビューにスタイルを適用する	deployment view prod { include prod.** style prod._ { color primary } }	deployment view prod { include prod.** with { color primary } }
デプロイメントビューの修正でスタイルを再利用する	そのデプロイメントビュー内のローカルな style ... {} ルール	global style theme

簡単な注意：デプロイメントビューでは、include ... with {} と global style ... をサポートされていない修正パターンとして扱います。代わりに、デプロイメントビュー内のローカルな style ... {} ルールを使用してください。

LikeC4 プロジェクトの設定

設定ファイル（likec4.config.json、.likec4rc、または likec4.config.{ts,js}）でプロジェクトを定義します。ファイルの場所によってプロジェクトのスコープが決まります（LikeC4 ファイルは、ディレクトリ階層内で最も近い設定ファイルのプロジェクトに属します）。

{
  "$schema": "https://likec4.dev/schemas/config.json",
  "name": "my-project",
  "title": "Project Title"
}

主なオプション：name（必須、ワークスペース内で一意の ID）、title（表示名） リファレンス全文 → references/configuration.md

仕様

名前付き語彙をすべて定義します。対象は、要素の種類、デプロイメントノードの種類、リレーションシップの種類、タグ、カスタムカラー トークンです。これらの種類を model または deployment ブロックで使用する前に記述する必要があります。

主な注意事項：すべての定義はファイル間で共通です。種類やタグの識別子が重複すると検証エラーが発生します。仕様を変更するとプロジェクト全体が再解析されるため、専用の spec.c4 ファイルに記述してください。

完全な構文、種類ごとのオプション、実例 → references/specification.md

モデル

要素とリレーションシップの階層構造です。要素には、種類（仕様で定義）、親要素内で一意の識別子、任意のプロパティと子要素を指定できます。

主な注意事項：入れ子になったリレーションシップ内では、this／it が現在の要素を指します。ファイルをまたぐ参照には完全修飾名（FQN）が必要です。親子間の直接的なリレーションシップは禁止されています。extend FQN { } は、要素を再定義せずに既存の要素へタグ、メタデータ、リンクを追加します。

完全な構文、拡張パターン、プロパティの表、実例 → references/model.md

スタイル

スタイルプロパティは、視覚的な外観を制御します。color、shape、border、opacity、size、padding、textSize、sizing、icon、iconColor、iconSize、iconPosition、multipleがあります。sizing fixed は、同じ size の要素をすべて同じ幅と高さで描画します（コンテンツは収まるよう縮小されます）。デフォルトの auto では、size は最小値として扱われます。リレーションシップのスタイルでは、これらに加えて矢印の形状を指定する line、head、tail を使用できます。

カラー トークンの完全な表、すべての形状の値、ボーダー／不透明度／サイズのトークン、アイコンパックのプレフィックス（aws:、azure:、gcp:、tech:、bootstrap:）、正しい使用パターン → references/style-tokens-colors.md

利用可能なアイコンを確認するには、CLI を使用します：likec4 list-icons（1 行に 1 つずつテキストで表示）。--group <name> でグループを絞り込めます。アイコングループと概算数：aws（約 307）、azure（約 614）、gcp（約 216）、tech（約 2000）、bootstrap（約 2051）（詳細は references/cli.md を参照）。

デプロイメント

instanceOf を使用して、論理モデルの要素を物理インフラストラクチャのノードに対応付けます。仕様の deploymentNode の種類を使用します。論理モデルのすべてのリレーションシップを自動的に継承します。デプロイメントレベルの追加のリレーションシップは、インラインで定義できます。

名前付きインスタンスと匿名インスタンス、複数環境のフィクスチャ、デプロイメントのリレーションシップ、デプロイメントフィルターのメタデータルール → references/deployment.md

ビュー

ビューは3種類あります。要素ビュー（view id または view id of element）、動的ビュー（dynamic view id）、デプロイメントビュー（deployment view id）です。ビューのプロパティは title、description、metadata、link です。

包含／除外述語、ビュー単位のスタイルルール、グループ、autoLayout、extends、navigateTo、グローバル述語グループ → references/views.md

クイック判断ツリー

「関係の入力述語が必要です」

Need inbound relation selection?
├─ From any source to target element → `include -> target`
├─ From explicit wildcard source     → `include * -> target`
└─ Include both directions around X  → `include -> X ->`

include -> X と include * -> X は関連していますが、あらゆる状況で互換性があるわけではありません。ユーザーや評価で指定された正確な形式を優先してください。

スコープ付き述語の真偽カード（*、_、**）

セレクター	ひとことで説明	典型的な用途
parent.*	parent の直接の子のみ	直近の構造を表示する
parent._	累積された結果との関係を持つ parent の直接の子	接続された直接の子だけを残す
parent.**	累積された結果との関係を持つ parent の再帰的な子孫	接続された深い階層の子孫を探索する

厳守事項：* を再帰的と説明しないでください。_ をすべてに一致するワイルドカードと説明しないでください。また、_／** の関係条件の意味を省略しないでください。

「図／ビューを作成する、またはフロー／シーケンスを表示する必要があります」

What kind of diagram?
├─ Interaction flow / sequence → Dynamic View
├─ Infrastructure / deployment → Deployment View
├─ From architecture model → Element View
│   ├─ Primary element known → Scoped view: `view name of element { ... }`
│   └─ Extend existing view → `view name extends other { ... }`
└─ Other → `view name { ... }`

「スタイルを設定する必要があります……」

Styling?
├─ Style element(s) in a view → view `style` rule, see `references/views.md`
├─ Style element(s) in some views, but not all
│   ├─ views in same file → local view rule, see `references/views.md`
│   └─ views in different files → global view rule, see `references/views.md`
├─ Style element globally → property inside element definition, see Model section
├─ Style all elements of a kind → property inside kind specification, see Specification section
├─ Style by tag → view rule, see `references/views.md`
├─ Style relationship(s) in a view → view rule, see `references/views.md`
├─ Style relationship globally → property inside relationship definition, see Model section
├─ Style all relationships of a kind → property inside kind specification, see Specification section
├─ Reuse same styles across views → see `references/views.md`

「複数のファイルにまたがって整理する必要があります」

Multi-file project?
├─ Import from another project → import { backend } from 'shared-project' (project name, not a file path)
├─ Cross-file lookup → short names do not inherit lexical/container scope across files; use full FQN
├─ Extend element → extend cloud.backend { service newSvc "New" }
├─ Extend relationship → extend cloud -> amazon { metadata { ... } }
├─ Metadata merge → Duplicate keys become arrays
├─ Organize views → views "Use Cases" { ... } (folder label)
└─ All blocks are mergeable across files

「フロー／シーケンスを表示する必要があります」

Flow / sequence diagram?
├─ Basic steps → source -> target "title"
├─ Response / backward → source <- target "returns"
├─ Parallel actions → one `parallel { ... }` block (also: `par { ... }`)
├─ Optional / repeated steps → `opt { ... }` / `loop { ... }` (optional title each)
├─ Mutually exclusive branches → `alt { when '...' { } else '...' { } }`
├─ Success + error handling → `try { } catch { } finally { }`
├─ Chained steps → customer -> frontend "x" -> backend "y"
├─ Step with notes → step { notes 'Markdown content' }
├─ Link to another view → step { navigateTo other-view }
├─ Sequence variant → dynamic view name { variant sequence }
└─ Full reference → references/dynamic-views.md

フロー制御ブロック（実験的機能）はすべてタイトルを省略でき、任意の深さにネストできます。ただし、parallel／par はネストできません。when／if／else が有効なのは、alt の直下のみです。loop／opt／parallel／try は alt の直接の子にはできません（ブランチの内部にネストしてください）。references/dynamic-views.md を参照してください。

戻り矢印の精度：

• プロンプトで応答矢印を戻すよう求められている場合は、新しい順方向矢印に置き換えず、<- のステップを優先してください。
• プロンプトでチェーン内の特定のホップに本文を付けるよう求められている場合は、そのホップだけにブロックを付けてください。
• プロンプトで1回のファンアウトを求められている場合は、1つずつの並列ブロックを複数作らず、兄弟アクションを1つの parallel { ... } ブロックにまとめてください。

厳密なプロンプトで避けるべきアンチパターン

アンチパターン	問題点	正しい対応
validate の代わりにコマンドファミリー（check／build）を使う	コマンドの厳密な契約に違反します	likec4 validate をそのまま使う
フラグを創作／推測する	移植性のない無効なコマンドが生じます	正式に文書化されたフラグのみを使う
1つの厳密な依頼に対して複数の代替スニペットを提示する	精度が下がり、厳密な出力の評価に失敗します	代替案を求められていない限り、最終回答を1つだけ出力する
曖昧なグラフで、種類／タイトルを指定せずに型付き関係を拡張する	誤った関係を対象にする可能性があります	必要に応じて、始点＋終点＋種類（＋タイトル）で一致させる

よくある間違いとデバッグ

モデルでエラーが発生した場合や、評価の回答が間違っているように見える場合は、次の内容を含む references/troubleshooting.md を読み込みます。

• 構文エラー — 識別子の形式（識別子ではドットを使用できません）、不明な種類、重複した FQN、不正な形式の where 述語
• モデルと階層 — 壊れた FQN 参照、親子関係の制約、ファイル間の可視性
• ビューの述語 — * と ** の混同、隣接要素の欠落、WHERE の大文字・小文字の区別
• デプロイ — instanceOf の FQN 解決、未定義の deploymentNode の種類
• 動的ビュー — フロー制御ブロック（parallel／opt／loop／alt／try）、alt 分岐の配置ルール、parallel のネスト禁止、応答矢印の対称性、正確な variant sequence キーワード
• 検証とインポート — 設定が見つからない、インポートパスの解決、上流エラーの連鎖
• パフォーマンス — 仕様を別ファイルに分ける、大きなビューを分割する
• 5 ステップのデバッグワークフロー — --file を使った検証優先の手順、FQN の整合性、述語の切り分け、仕様優先の検証
• 7 つのスキルのベストプラクティス — 応答の規律、関係の曖昧さの解消、FQN の使用、安全な編集ルール

参照インデックス

タスクが該当するトピックに関係する場合は、参照ファイルを読み込んでください。Claude は最初に SKILL.md を読み込み、これらのファイルは必要な場合にのみオンデマンドで読み込まれます。

ファイル	目的 — 次の場合に読み込みます...
references/specification.md	specification { } ブロックの作成・編集、element／deploymentNode／relationship／tag／color の種類の定義
references/model.md	model { } ブロックの作成・編集、要素の階層、関係、extend パターン、プロパティ名
references/deployment.md	deployment { } ブロックの作成・編集、instanceOf、名前付きインスタンス、複数環境のトポロジー、デプロイメントのメタデータフィルター
references/style-tokens-colors.md	色、形状、アイコン、関係線のスタイルを適用する場合、または正確なトークン名が必要な場合
references/views.md	ビューの作成、include／exclude ルール、ビュー内のスタイルルール、グループ、autoLayout、グローバル述語
references/predicates.md	複雑な where 条件、メタデータフィルター、with オーバーライド、グローバル述語グループ、再利用可能な述語
references/include-predicates-wildcards.md	ワイルドカードに関する混乱が疑われる場合（* と _ と **）、またはスコープ付きビューの正確なセマンティクスが必要な場合
references/dynamic-views.md	動的ビューの作成：ステップ、戻り矢印、連鎖ステップ、フロー制御ブロック（parallel／opt／loop／alt／try）、variant sequence
references/identifier-validity.md	識別子と FQN の混同、「名前にドットが含まれる」エラー、FQN の構築方法の理解
references/relationships-bidirectional.md	双方向関係の構文と <-> ビュー述語のパターン
references/diffs.md	モデルの変更計画（diff ブロック）、変更の適用または破棄、要素の安全な削除
references/bridge-leanix-drawio.md	LeanIX ブリッジ · drawio --profile leanix · ラウンドトリップ · マッピング · MCP とブリッジの違い · 同期／アーティファクト／管理対象セル
references/cli.md	CLI の完全なリファレンス：serve、build、export、codegen、mcp、format、フラグの使い分け
references/configuration.md	プロジェクト設定オプション、複数プロジェクトのセットアップ、include／exclude パス、ジェネレーター
references/examples.md	実用的な簡潔な例：extend、グループ、グローバル、動的ビュー、デプロイメント、rank
references/troubleshooting.md	エラー、予期しない出力、評価の失敗 — 6 つのエラーテーブル、5 段階のデバッグワークフロー、7 つのベストプラクティス