hk

hk - Git フックマネージャー

jdx の hk は、組み込みの並列処理、ファイルロック（競合状態なし）、ステージ済みファイルのみの処理を備えた、Git フックとしてリンターやフォーマッターを実行するツールです（lint-staged を別途用意する必要はありません）。設定には、Apple の型付き設定言語である Pkl を使用します。

メンタルモデル

hk のセットアップは、常に 3 つのステップで行います。プロジェクトにあるものを検出し、階層からステップを組み合わせ、フックを接続します。

detect project type + tools
         ↓
compose hk.pkl (tiered steps)
         ↓
wire: mise.toml + .hk-hooks/ + prepare script

セットアップのワークフロー

1. 検出

hk --version                    # get current version for amends URL
ls package.json go.mod Cargo.toml pyproject.toml flake.nix Makefile
cat mise.toml package.json      # existing tools, package manager, scripts

以下を特定します。

• 言語とフレームワーク
• パッケージマネージャー（JS では pnpm/bun/npm/yarn、cargo、go、pip など）
• すでに設定されているフォーマッター（prettier、biome、ruff、gofmt など）
• すでに設定されているリンター（eslint、golangci-lint、ruff、clippy など）
• テストランナー（vitest、jest、go test、cargo test、pytest など）
• チームで共有するリポジトリかどうか、およびブランチ保護を厳格なサーバー側の保護にするか、ローカルフックによる助言的な保護にするか

2. ステップを選択（階層別）

Tier 1 - 共通（常に追加）：

ステップ	組み込み機能
trailing-whitespace	Builtins.trailing_whitespace
newlines	Builtins.newlines
check-merge-conflict	Builtins.check_merge_conflict

Tier 2 - 一般的なツール（該当する場合に追加）：

ステップ	組み込み機能	使用条件
typos	Builtins.typos	常に（高速なスペルチェック）
gitleaks	カスタム	常に（シークレット検出）
rumdl	Builtins.rumdl	*.md ファイルがある場合

Tier 3 - 言語固有（references/builtins-by-language.md を参照）：

判定ファイル	追加するステップ
package.json + biome.json/biome.jsonc	biome（または ultracite）、eslint
package.json（biome なし）	prettier、eslint
tsconfig.json	型チェック（tsc/tsgo/astro check/svelte-check）
go.mod	go_fmt、go_vet、golangci_lint、gomod_tidy
Cargo.toml	cargo_fmt、cargo_clippy
pyproject.toml/requirements.txt	ruff（フォーマット＋リンター）、mypy
flake.nix/*.nix	nix_fmt（nixfmt）、deadnix
*.sh/*.zsh	shfmt、shellcheck

Tier 4 - プロジェクト固有（設定ファイルから検出）：

判定条件	ステップ
commitlint.config.* が存在する	commitlint を使う commit-msg フック
.dependency-cruiser.* または check:deps が存在する	グラフ全体のアーキテクチャチェック
.yamllint* が存在する	yamllint
チームで共有するリポジトリ	no-commit-to-branch（pre-commit）、ブランチガード（pre-push）。オーナーがオプトアウトできる、助言的なプライベートリポジトリ保護には、以下のソフト保護 pre-push アセットを使用します。
pnpm-lock.yaml が存在する	pnpm のビルドスクリプト判定チェック - assets/pnpm-build-scripts-check.mjs をコピーします（以下を参照）
テストランナーが検出された	テストステップ（vitest/jest/go test/cargo test/pytest）

3. フックを接続

作成または更新するファイルは 3 つと、任意の追加ファイルです。

1. mise.toml - hk、pkl、ツールのバイナリを追加
2. hk.pkl - 設定
3. .hk-hooks/pre-commit - バージョン管理対象のフックラッパー（hk run pre-commit -q を実行します。-q は成功したすべてのステップの出力を抑制します。references/output-noise.md を参照）
4. .hk-hooks/pre-push - 任意。プッシュ時のチェックまたはブランチガード用です。助言的なプライベートリポジトリのブランチ保護には、assets/soft-protected-branch-pre-push.sh からコピーします。

続いて：

chmod +x .hk-hooks/*
git config --local core.hooksPath .hk-hooks

JS プロジェクトでは、package.json の prepare スクリプトにも追加します。

"prepare": "[ -n \"$CI\" ] && exit 0 || git config --local core.hooksPath .hk-hooks"

core.hooksPath を直接設定してください。この場合、hk install は使用しないでください。最新の hk/Git では hk install は正常に実行され、hk が生成する独自のフックを接続しますが、このスキルで設定するバージョン管理対象の .hk-hooks/ ラッパーとは、気づかないうちに異なる構成になります（ラッパーには HK=0 によるバイパス、mise の検出、-q が含まれます）。接続方法は、バージョン管理対象のものに統一してください。prepare 時に hk をインストールしておく必要はありません。コミット時にラッパーが hk を検出し、見つからない場合は明確なエラーを表示します。

JS 以外のプロジェクトでは、core.hooksPath を手動で設定するか、Makefile の setup ターゲットで設定します。

4. 検証

hk check --all      # verify all steps pass on existing files
hk validate         # verify hk.pkl is valid Pkl

---

推奨パターン

hk.pkl のグローバル設定

常に以下を先頭（amends/import 行の後）に記述します。

exclude = List("node_modules", "dist", ".next", ".git")  // add project-specific dirs
display_skip_reasons = List()   // suppress skip noise
terminal_progress = false        // disable OSC terminal-progress escape sequences (NOT stdout noise — see references/output-noise.md)

pre-commit フックでは常に以下を使用します。

["pre-commit"] {
    fix = true        // auto-fix and re-stage
    stash = "git"     // isolate staged changes
    steps { ... }
}

バイナリファイルの除外

末尾の空白、改行、誤字のチェックでは、バイナリファイルとフォントファイルを常に除外してください。

local binary_excludes = List(
    "*.png", "*.jpg", "*.jpeg", "*.gif", "*.webp", "*.ico",
    "*.woff", "*.woff2", "*.ttf", "*.eot", "*.pdf", "*.zip"
)

["trailing-whitespace"] = (Builtins.trailing_whitespace) {
    exclude = binary_excludes
}

手順を静かに実行する — フックラッパーにフラグを1つ追加

hk ≥ 1.51.0 では、.hk-hooks/pre-commit ラッパーで hk run <hook> -q を指定すれば、静かに実行できます。-q は成功時にすべての手順をネイティブに静かにします。つまり、成功 → 0バイト、失敗 → 失敗した手順の標準出力と標準エラーがすべて残ります（hk の進行状況表示のみが抑制されます）。手順ごとのラップも、ツールごとの段階分けも不要で、手順は通常のコマンドを実行します。

["vitest"] {
    check = "pnpm exec vitest run"   // chatty on success — silenced by wrapper-level -q
}

--silent は絶対に使用しないでください。これも成功時は0バイトになりますが、失敗時に診断情報が破棄され（See .../output.log のみが表示されます）、安全ではありません。安全な選択肢は -q だけです。-n、HK_LOG、RUST_LOG は手順の成功時の出力には影響しません。仕組み、TTY と非 TTY の違い、測定結果については references/output-noise.md を参照してください。

グラフ全体のチェック

リポジトリ全体のグラフを検査するツールには {{files}} を渡さないでください。該当するツールには、dependency-cruiser、knip、サプライチェーンスキャナー、リンクチェッカー、型チェック全体、カバレッジゲートがあります。チェックで常にグラフ全体を確認する必要がある場合は、glob を指定せずに通常の手順として設定してください。（どのサプライチェーンスキャンを実行するか、その重大度をブロックと報告のどちらにするかは supply-chain-hardening スキルが判断します。このスキルが担当するのは設定です。）

glob を指定しない理由は、ツールが受け付ける対象だけではありません。変更がステージ済みファイルの削除だけの場合、glob を指定した手順はまったく実行されません。hk は glob を解決してファイルが0件になると、その手順を実行計画に含めません。一方、glob を指定しない手順は引き続き実行されます（「0 files」と表示されます）。そのため、ファイルの削除によって破られる不変条件（リンクチェッカー、未参照チェック、マニフェストとツリーの整合性ゲートなど）を確認するには、glob を指定しない必要があります。そうしないと、本来チェックが必要な状況でチェックが実行されません。

dependency-cruiser の場合：

local depcruise_step = new Step {
    check = "pnpm --silent check:deps"
}

長いコマンドと設定パスを JS プロジェクト側に置けるよう、パッケージスクリプトを使用してください。

"check:deps": "depcruise src --config .dependency-cruiser.cjs --output-type err-long --no-progress --no-cache"

グラフ全体のチェックは、完全な quality、check、CI、または pre-push フックに置くのがおすすめです。ステージ済みファイルを対象とする pre-commit に追加するのは、手順を測定し、通常のコミットに許容できる遅延であることを確認してからにしてください。

.hk-hooks/pre-commit ラッパー

これは Git が実際に実行するファイルです（.git/hooks/ とは異なり、Git で追跡されます）。hk の出力を取り込まず、exec を使って、色、進行状況、失敗時の診断情報がそのままストリーム出力されるようにしてください。-q フラグが抑制するのは成功時の表示だけです（クリーンな実行では0バイト）。手順が失敗した場合は、標準出力と標準エラーがすべて引き続き出力されます。また、このラッパーは HK=0 によるバイパスを追加し、hk が PATH にない場合は mise 経由で検出します。

#!/bin/sh
# hk pre-commit hook — tracked wrapper. Streams hk output directly.

# HK=0 bypasses all hooks (mirrors `HK=0 git commit`).
if [ "${HK:-1}" = "0" ]; then
  exit 0
fi

# Find hk: on PATH, else via mise (covers shells without mise activated).
HK_BIN=""
if command -v hk >/dev/null 2>&1; then
  HK_BIN="$(command -v hk)"
elif command -v mise >/dev/null 2>&1; then
  HK_BIN="$(mise which hk 2>/dev/null || true)"
fi

if [ -z "$HK_BIN" ]; then
  echo "hk not found. Install tools with: mise install" >&2
  exit 1
fi

exec "$HK_BIN" run pre-commit -q "$@"

hk に処理を委譲するだけのフックには、よりシンプルなラッパーを使用してください。

#!/bin/sh
exec hk run commit-msg "$@"

#!/bin/sh
exec hk run pre-push "$@"

pre-push でのソフト保護ブランチ

これは、小規模、非公開、または共有リポジトリで、サーバー側のブランチ保護が利用できないか、意図的に注意喚起にとどめる場合に限って使用してください。ただし、共同作業者が main／master への直接プッシュを避けるよう促す必要がある場合に適しています。利用できる場合は、サーバー側のブランチルールを優先してください。これはセキュリティ境界ではありません。フックはクローンごとに設定され、core.hooksPath が必要で、--no-verify で回避できます。

assets/soft-protected-branch-pre-push.sh を .hk-hooks/pre-push にコピーし、実行可能にしてください。

cp /path/to/skill/assets/soft-protected-branch-pre-push.sh .hk-hooks/pre-push
chmod +x .hk-hooks/pre-push
git config --local core.hooksPath .hk-hooks

パターン：

• Git の pre-push 標準入力を解析し、現在のブランチではなく remote_ref に基づいてブロックします。現在のブランチを確認する方法では、git push origin feature:main のようなプッシュを検出できません。
• refs/heads/main および refs/heads/master への直接プッシュは、デフォルトでブロックします。
• リポジトリのオーナーは、リポジトリローカルの設定でオプトアウトできるようにします。 git config --local hooks.allowMainPush true
• 単発の自動化で使う回避手段は、明示的に指定します。 HK_ALLOW_MAIN_PUSH=1 git push
• リポジトリのドキュメントやエージェント向けの手順に、注意喚起を目的とするものであることと、オプトアウト方法を記載します。

pnpm ビルドスクリプトの判定チェック

ライフサイクルスクリプト（preinstall／install／postinstall、または binding.gyp）を持つ依存関係については、pnpm-workspace.yaml の allowBuilds に判定を記録する必要があります。判定が記録されていないと、pnpm 11 はインストールを 失敗させます（ERR_PNPM_IGNORED_BUILDS）。ただし、チェックを何もマスクしていない場合に限ります。 グローバルな ignoreScripts が設定されたマシンでは、インストールもクリーンな状態からの再インストールも成功し、 CI またはプラットフォームビルドで初めて失敗します。

assets/pnpm-build-scripts-check.mjs を .hk-hooks/ にコピーし、依存関係ツリーを変更する可能性がある ファイルに対してステップをグロブします。

["pnpm-build-scripts"] {
    glob = List("package.json", "pnpm-lock.yaml", "pnpm-workspace.yaml")
    check = "node .hk-hooks/pnpm-build-scripts-check.mjs"
}

パターン：

• 設定を読み取るだけで、何も実行しません。 チェッカーはインストール済みのマニフェストと pnpm-workspace.yaml を解析します。pnpm には実行せずに検出するモードがなく、pnpm 自身のレポート （pnpm ignored-builds、.modules.yaml）はマスク設定のもとで計算されるため、不足している判定ではなく マスクを報告します。CI と同じ結果を再現する唯一のローカルコマンドである pnpm install --ignore-scripts=false は、この設定でブロックされるスクリプトを再び有効にするため、 チェックとしては使えません。
• 評価できないものが原因で、決してビルドを失敗させません：node_modules がない場合や、 pnpm プロジェクトでない場合は警告して終了コード 0 で終了します（新しいクローンでの型チェック ステップと同じ方針です）。
• 機械処理には --json を使用します。人向けの出力では一覧を上限まで表示し、実際の合計件数も報告します。
• パッケージに true と false のどちらを設定するかは、ユーザーのセキュリティ上の判断です。 その判断はサプライチェーン強化スキルが担います。このステップが求めるのは、判定が存在することだけです。

既知の制限：インストール済みのツリーを読み取るため、このプラットフォーム向けに解決されたオプション依存関係が対象です。 linux-x64 パッケージでのみ提供される postinstall は、ローカルチェックでは検出できません。このギャップを埋められるのは、 対象プラットフォームで実行する CI ジョブだけです。

Pkl 構文リファレンス

必須の先頭行

amends "package://github.com/jdx/hk/releases/download/v1.56.1/[email protected]#/Config.pkl"
import "package://github.com/jdx/hk/releases/download/v1.56.1/[email protected]#/Builtins.pkl"

amends と import のバージョンは、インストール済みの hk のバージョン（hk --version）に必ず合わせてください。 また、hk ≥ 1.51.0 を必須としてください。ラッパーレベルの -q による成功時の静音化（上記参照）には、 このバージョンが必要です。このスキルは hk = "latest" をインストールするため、新しい環境は条件を満たします。 古いバージョンに固定されているリポジトリでは、hk をアップグレードしてください。

組み込みステップ（そのまま使用）

["trailing-whitespace"] = Builtins.trailing_whitespace

組み込みステップ（オーバーライドあり）

["trailing-whitespace"] = (Builtins.trailing_whitespace) {
    exclude = List("*.png", "*.jpg")
    batch = true
}

出力制御

実行単位（推奨）： hk run <hook> に指定するフラグです。

フラグ	効果
-q	成功時は静音（hk ≥ 1.51.0）：成功時は 0 バイト、失敗時は失敗したステップの stdout と stderr をすべて保持します。ラッパーに指定してください。
--silent	成功時も失敗時も 0 バイトになり、診断情報が失われます。絶対に使用しないでください。
-n / --no-progress	ステップ成功時の出力には影響しません（進捗表示のみを制御します）。

ステップ単位： hk の装飾出力を抑える 2 つの設定です。どちらもコマンド自体の出力は抑制しません （コマンド自体の出力を抑制するのはラッパーレベルの -q だけです）。

["typecheck"] {
    check = "pnpm exec tsc --noEmit"
    output_summary = "stderr"   // end-of-run summary stream: "stderr" (default) | "stdout" | "combined" | "hide"
    hide = false                // true removes this step's status markers (the ✔/✖ lines)
}

-q がない場合、失敗時に hk は出力を2 回表示します（ライブストリームと最後のサマリー）。 output_summary = "hide" を指定すると重複するサマリーは省けますが、先頭を保持する出力切り詰めでのみ安全です。 ラッパーレベルの -q ならこれを回避できます。失敗時の出力が小さく 1 回だけになるため、先頭と末尾のどちらを保持する切り詰めでも安全です。 references/output-noise.md を参照してください。

カスタムステップ

["typecheck"] {
    glob = List("*.ts", "*.tsx")       // optional: only run when these files staged
    check = "pnpm exec tsc --noEmit"   // silent on success — no wrapper needed
    // fix = "command to auto-fix"     // optional
}

テンプレート変数

変数	値
{{files}}	ステップのグロブに一致するステージ済みファイルの、スペース区切りの一覧
{{commit_msg_file}}	コミットメッセージファイルへのパス（commit-msg フックのみ）
{{workspace}}	workspace_indicator ファイルを含むディレクトリ
{{workspace_files}}	ワークスペースディレクトリからの相対パスで示したファイル
{{root}}	リポジトリのルート。tests {} ブロック内でも、サンドボックスではなく実際のルートを指します。そのため before でチェッカーをコピーできます
{{tmp}}	テストごとのサンドボックスディレクトリ。tests {} 内でのみ使用でき、使用すると tmpdir が自動的に有効になります

複数行のインラインスクリプト

["no-commit-to-branch"] {
    check = """
      branch=$(git rev-parse --abbrev-ref HEAD)
      if [ "$branch" = "main" ] || [ "$branch" = "master" ]; then
        echo "Direct commits to '$branch' are not allowed."
        exit 1
      fi
      """
}

ローカル変数（複数のフックでステップを共有）

local fast_steps = new Mapping<String, Step> {
    ["trailing-whitespace"] = Builtins.trailing_whitespace
    ["shfmt"] = (Builtins.shfmt) { batch = true }
}

hooks {
    ["pre-commit"] { fix = true; stash = "git"; steps = fast_steps }
    ["check"] { steps = fast_steps }
    ["fix"] { fix = true; stash = "git"; steps = fast_steps }
}

グループによる順次実行

グループ内のステップは並列で実行され、グループは順番に実行されます。

steps {
    ["format"] = new Group {
        steps = new Mapping<String, Step> {
            ["prettier"] { ... }
            ["eslint"] { ... }
        }
    }
    ["validate"] = new Group {   // runs after format completes
        steps = new Mapping<String, Step> {
            ["typecheck"] { ... }
            ["test"] { ... }
        }
    }
}

または、depends を使って実行順序を細かく指定できます。

["eslint"] {
    depends = List("prettier")   // waits for prettier to finish
    ...
}

---

mise.toml の追加項目

[tools]
hk = "latest"
pkl = "latest"        # required for hk.pkl parsing

# Add as needed based on detected steps:
typos = "latest"      # Tier 2: spell check
gitleaks = "latest"   # Tier 2: secret detection
rumdl = "latest"      # Tier 2: markdown lint (if .md files present)
yamllint = "latest"   # Tier 4: YAML lint (if .yamllint* present)

---

メンテナンス

新しいステップを追加する

適切なセクションの hk.pkl に追加します。利用可能なビルトインは hk builtins で確認するか、カスタムステップを作成してください。

hk のバージョンを更新する

hk --version   # check current

hk.pkl 内の両方の URL をインストール済みバージョン（最低 v1.51.0）に更新します。例：

amends "package://github.com/jdx/hk/releases/download/v1.56.1/[email protected]#/Config.pkl"
import "package://github.com/jdx/hk/releases/download/v1.56.1/[email protected]#/Builtins.pkl"

フックを一時的に回避する

HK=0 git commit -m "wip"             # skip all hk hooks
HK_SKIP_STEPS=vitest git commit      # skip specific step

失敗するステップをデバッグする

hk check -v                          # verbose output
hk check -v --step typecheck         # single step only
hk run pre-commit -v                 # simulate hook run

ローカル開発者向けのオーバーライド

hk.local.pkl（gitignore 対象）を作成して、ローカルの設定をオーバーライドします。

amends "./hk.pkl"
hooks {
    ["pre-commit"] {
        steps {
            ["vitest"] {
                check = "pnpm exec vitest run --testPathPattern=fast"
            }
        }
    }
}

---

注意点

問題	解決方法
pkl: command not found	mise.toml に pkl = "latest" を追加し、mise install を実行します
amends のバージョン不一致	amends/import URL のバージョンを hk --version の出力に合わせます
ビルトインは snake_case、ステップ名は kebab-case	Builtins.trailing_whitespace → ["trailing-whitespace"]
フックは実行されるが、何も一致しない	glob パターンを確認します。ファイルの一致状況を確認するには hk check -v を使います
{{files}} にツールが処理できるファイルがないとステップが失敗する	glob が決めるのはステップが 実行される対象 であり、ツールが 受け付ける対象 ではありません。空の対象セットに対して何もしないのではなく、終了コードが 0 以外になるツールが複数あります。渡されたすべてのパスがそれぞれの ignorePatterns に含まれる場合、oxfmt は「Expected at least one target file」というエラーを出します。lint 対象のファイルがない場合、oxlint も同様です。各ステップの glob は、そのツールが実際に処理する対象に合わせ、lint と format は別々のステップにしてください。*.json に一致する glob を使う統合ステップは、JSON だけのコミットで失敗します
バイナリファイルでスペルチェックが失敗する	typos/trailing-whitespace/newlines の各ステップに、バイナリファイルの除外を追加します
Git worktree で hk install が失敗する	v1.35.0 以降は自動で処理されます。古いバージョンを使う場合は .hk-hooks/ と core.hooksPath を使います
修正によって意図しないファイルがステージングされる	ステップで明示的な stage glob を使うか、ステップの glob が修正対象のファイルを含むようにします
成功時の出力が多すぎる	pre-commit ラッパーに -q を追加します（hk run pre-commit -q、hk ≥ 1.51.0）。成功時は 0 バイト、失敗時は失敗したステップの出力全体が表示されます。--silent は絶対に使わないでください（失敗時の診断情報が表示されなくなります）。references/output-noise.md を参照してください
フックが CI で不要に実行される	prepare スクリプトに [ -n "$CI" ] && exit 0 を追加します
hk.local.pkl の amends が反映されない	1 行目を amends "./hk.pkl" にする必要があります
ドキュメントに記載されたビルトインが見つからない	ビルトインのセットは、インストール済みの hk ではなく、amends/import URL のバージョンに紐づいています。使う前にそのタグの pkl/builtins/ を確認してください。たとえば statix は 1.56.1 にはありませんが、deadnix、lychee、check_symlinks、check_case_conflict、hk_test はすべて含まれています
hk --all でファイルが見落とされるように見える	対象となるのは追跡対象のファイルのみです。サイズを理由に除外したディレクトリ内の未追跡ツリーは、もともと対象外です。そのため、除外設定が追跡対象のファイルを不必要に隠している可能性があります。除外を残す前に hk check --all --stats で確認してください
意図的に不正な frontmatter を含むフィクスチャで vale が失敗する	Vale は解析できない frontmatter をスキップせず、エラー（E201）で処理を停止します。そのため、意図的に不正なフィクスチャは lint のフィクスチャと同様に、ステップから除外する必要があります
マシンがオフラインだと pinact が毎回失敗する	すべてのアクション参照を GitHub API（/repos/<owner>/<repo>/commits/<ref>）経由で解決し、オフラインモードがないため、API に接続できないと必ず失敗します（3.10.1 では終了コード 1）。未固定のアクションに対して報告される内容と同じです。pre-commit ではなく CI に追加してください。これがフックで zizmor に --offline を指定する理由と同じです
ステップテストが作業ツリーにフィクスチャを書き込む	tmpdir = true を指定せず、相対パスだけを使うと、リポジトリ内に書き込まれたファイルが残ります。{{tmp}}/... を使ってください。references/testing-steps.md を参照してください

---

参考資料

• references/builtins-by-language.md - エコシステムに応じたステップの選択
• references/complete-examples.md - さまざまなスタック向けの hk.pkl 設定一式
• references/output-noise.md - ステップを適切に静かに保つ方法（ラッパーレベルの -q、hk のネイティブ制御、ハーネスによる切り捨て時の注意点）
• references/testing-steps.md - tests {} と hk test：各フィールド、{{tmp}} サンドボックスのルール、before と {{root}} を使ったリポジトリ全体のチェッカーのテスト方法、および Builtins.hk_test が取り込むもの
• assets/soft-protected-branch-pre-push.sh - アドバイザリ型のローカルブランチ保護とクローンごとの所有者によるオプトアウトを設定するには、.hk-hooks/pre-push にコピーします
• tests/soft-protected-branch-pre-push.bats - アドバイザリ型ブランチ保護アセットの動作テスト
• assets/pnpm-build-scripts-check.mjs - 依存関係のビルドスクリプトに allowBuilds の設定がない場合にコミットを失敗させるには、.hk-hooks/ にコピーします
• tests/pnpm-build-scripts-check.bats - ビルドスクリプト設定チェッカーの動作テスト
• hk のドキュメント - 公式ドキュメント
• hk builtins - 使用可能なすべての組み込みリンターを一覧表示します