コマンド

このページでは、実装済みの shk CLI コマンドとオプションについて説明します。

グローバルオプション

shk init

対話型の初回セットアップです。スターター用の shk.toml ポリシー、パッケージマネージャーの強化、Git pre-commit フック、AI エディターフック、同梱のエージェントスキルをセットアップします。

shk init
shk init --strict
shk init --force
shk init --yes
shk init --yes --no-npm-hardening
shk init --yes --tool claude-code,cursor --log-blocked
shk init --yes --no-git-hook --no-ai-hooks --no-skills

ターミナルでは、shk init はポリシープロファイルを尋ね、どのステップを実行するかを確認します。フックのステップには shk.toml が必要なため、ポリシーファイルが最初に書き込まれます。標準入力がターミナルではなく、セットアップ用のフラグも渡されていない場合、shk init は shk.toml のみを書き込む動作にフォールバックします。

オプション:

package.json が検出された場合、shk init はパッケージマネージャーのサプライチェーン強化を適用できます。npm プロジェクトでは、ignore-scripts=true や min-release-age=7 などのプロジェクト .npmrc 設定を書き込みます。pnpm、Yarn、Bun プロジェクトでは、対応する公開経過日数の制限設定を pnpm-workspace.yaml、.yarnrc.yml、bunfig.toml に書き込みます。--yes モードを含め、このステップをスキップするには --no-npm-hardening を渡します。

shk policy init はスターター用の shk.toml のみを書き込み、その他のセットアップステップをスキップします。

shk policy init
shk policy init --strict
shk policy init --force

shk status

プロジェクトの健全性を簡潔にまとめて表示します。

shk status

status コマンドは、shk.toml が存在するか、Git pre-commit フックと管理対象の AI ツールフックがインストールされているか、バンドルされた AI スキルがインストールされているか、そして新しい shk リリースが利用可能かを報告します。

更新チェックは shk status と shk doctor version に限定されます。scan コマンドやフックコマンドは、バージョン通知のためにネットワークへ接続しません。

shk audit

.shk/audit.log のメタデータのみのエントリをプレビューします。

shk audit
shk audit --json
shk audit --since 7d
shk audit --tool cursor
shk audit --reason action-guard
shk audit --limit 20
shk audit --no-paths

audit コマンドは、ローカルのフックおよびシークレットマネージャーの監査エントリを、生のマッチ値、プロンプト本文、コマンドテキストを出力せずに要約します。人間向け出力には、サマリー、ルール/ツール/理由/アクションカテゴリ別の件数、最近のイベントが含まれます。JSON 出力は自動化向けに同じレポート構造を出力します。

オプション:

shk audit は読み取り専用です。ログが存在しない場合は正常終了し、セットアップのガイダンスを表示します。無効な JSON 行はスキップされ、パース警告としてカウントされます。

shk mcp audit

サーバーの起動、コマンドの解決、変数の展開、ネットワークリクエストを一切行わずに、MCP サーバー設定ファイルを静的に検査します。

shk mcp audit
shk mcp audit path/to/project
shk mcp audit --json
shk mcp audit --sarif
shk mcp audit --global
shk mcp audit --fail-on medium

デフォルトのスキャンはプロジェクトローカルのファイルに限定されます。--global を付けると、現在のユーザーのホームディレクトリ配下にあるユーザーレベルのファイルも追加で読み取ります。存在しないファイルは黙ってスキップされます。 設定ファイルの読み取りは 1 ファイルあたり 1 MiB および 1,000 サーバーエントリまでに制限され、パス解決後も選択されたプロジェクトまたはホームのスコープ内に留まる必要があります。スコープ外へ抜けるシンボリックリンク、サイズ超過のファイル、過大なサーバーマップ、通常ファイル以外のファイルは、読み取られる代わりに mcp.config_unreadable を生成します。Unix ではハードリンクされた設定ファイルも拒否されます。

プロジェクト設定ファイルの場所:

--global で追加される場所:

ルール:

設定された引数、プロセス変数、ヘッダー、URL の値は、既存のシークレットルールエンジンも通過します。${VAR}、$VAR、${input:token} のような参照は平文の値として扱われません。既存の [[allowlist]] エントリが適用されます。レポートにはプロセス変数の値、ヘッダーの値、生のマッチ値は含まれません。

サーバーの --env-file <path>、--env-file=<path>、または --envfile 引数で指定されたファイルも読み取られ、シークレットおよび dotenv ルールでスキャンされます。これらの検出結果は通常の secret.* / env.* ルール ID を維持し、メッセージはサーバーとクライアントを示すように書き換えられます。相対パスは設定ファイルのディレクトリ（--global ファイルではホームディレクトリ）を基準に解決され、~/ は展開され、${VAR} 形式の参照はたどられず、存在しないファイルはスキップされます。MCP 設定監査を参照してください。

--json は findings、summary.by_severity、秘匿化された servers インベントリを返します。--sarif は shk scan --sarif と同じルールメタデータ形式で SARIF 2.1.0 を出力します。この 2 つの出力フラグは同時に指定できません。人間向け出力では、--verbose を渡さない限り情報レベルの検出結果は表示されません。

終了コード:

shk completions

シェル補完スクリプトを生成します。

shk completions bash > /usr/local/etc/bash_completion.d/shk
shk completions zsh > "${fpath[1]}/_shk"
shk completions fish > ~/.config/fish/completions/shk.fish

対応シェルは bash、zsh、fish、powershell、elvish です。

shk scan

リポジトリまたはパスをスキャンして、シークレット、PII（個人情報）、設定済みのカスタムルールを検出します。対応するドキュメント形式（.docx、.xlsx、.pptx、テキストレイヤー付き .pdf ファイル）からもテキストを抽出します。

shk scan
shk scan ./src
shk scan . --json
shk scan . --json --with-value-hash
shk scan . --sarif
shk scan . --sarif --audit
shk scan . --verbose
shk scan . --fail-on medium
shk scan . --include-binary
shk scan . --follow-symlinks
shk scan --staged
shk scan . --changed-since origin/main
shk scan --git-history
shk scan --git-history --preview
shk scan --git-history --ref HEAD~50..HEAD
shk scan --git-history --since 30.days.ago
shk scan . --no-color

オプション:

走査に関する注意:

• 隠しファイルと隠しディレクトリ（.env、.envrc、.npmrc など）はスキャンされます。.git ディレクトリ自体は常にスキップされます。
• Git リポジトリ内では .gitignore と .git/info/exclude のルールが尊重されます。shk doctor は .env を .gitignore に含めることを推奨しているため、Git リポジトリ内の gitignore された .env はディレクトリスキャンの対象外です。それでもスキャンしたい場合は明示的に指定してください（shk scan .env）。

--git-history は、作業ツリーやインデックスではなく、Git 履歴のコミット済み blob をスキャンします。デフォルトでは git log --all を使用するため、ローカルブランチ、タグ、リモート追跡 ref が対象になります。ファイルが存在していたコミットから古い blob を読み取るため、削除済みのシークレットも検出できます。未コミットの変更や到達不能なオブジェクトはスキャンされません。

--changed-since は、選択したブランチ差分で Git が列挙するファイルについて、現在の作業ツリーの内容をスキャンします。削除されたファイルはスキップされ、未追跡ファイルは含まれません。プルリクエスト CI では origin/main のような安定したベースを使用してください。

広範囲の履歴スキャンを行う前に --preview を使うと、選択されたスコープ、候補のコミット/パス数、ユニーク blob 数、ポリシーでフィルタリングされた blob 数、最大 10 件のサンプル <commit>:<path> ラベルを確認できます。--json を付けると、プレビューは同じメタデータを機械可読な JSON として出力し、0 で終了します。

ドキュメントスキャンに関する注意:

• Office の検出結果は <file>:<internal-entry> の形式でラベル付けされます（例: report.docx:word/document.xml や workbook.xlsx:xl/sharedStrings.xml）。パスで検出結果を抑制する場合は、[[allowlist]].path に同じラベルを使用してください。
• PDF の検出結果は PDF ファイルのパス自体でラベル付けされます（例: report.pdf）。
• PDF 対応は埋め込みのテキストレイヤーを使用します。画像のみの PDF は OCR されず、抽出可能なテキストが見つからない場合は scan.document_text_empty を生成します。

終了コード:

shk allowlist suggest

JSON スキャンレポートから [[allowlist]] TOML スニペットを生成します。提案にはルールとパスのメタデータが含まれ、レポートが --with-value-hash 付きで生成されている場合は value_hash を含めることもできます。生のマッチ値は決して出力されません。

shk scan . --json --fail-on critical > report.json
shk allowlist suggest --from report.json
shk scan . --json --with-value-hash --fail-on critical > report-with-hashes.json
shk allowlist suggest --from report-with-hashes.json --value-hash --reason "Intentional fixture" --expires 2026-12-31

オプション:

value_hash は決定的で、公開ルール ID をキーとしているため、一般的なメールアドレスや電話番号のような低エントロピーの値は辞書攻撃で復元できる可能性があります。その露出が許容できる場合を除き、値ハッシュを含むレポートをサードパーティのシステムにアップロードしないでください。

shk scan --hook-mode

標準入力から AI ツールフックの JSON ペイロードを読み取り、抽出したフック本文をスキャンして、ツール固有のフック出力を表示します。

shk scan . --hook-mode cursor < payload.json
shk scan . --hook-mode claude-code --audit < payload.json
shk scan . --hook-mode cursor --log-blocked < payload.json
shk scan . --hook-mode codex < payload.json
shk scan . --hook-mode codex --post < payload.json
shk scan . --hook-mode copilot < payload.json
shk scan . --hook-mode antigravity < payload.json
shk scan . --hook-mode windsurf < payload.json

フックモードで対応するツールは claude-code、codex、cursor、copilot、antigravity、windsurf（Windsurf Cascade）です。Cascade はフックの標準出力を無視するため、--hook-mode windsurf は標準出力の判定ペイロードではなく、終了コード 2 と標準エラー出力のメッセージでブロックを通知します。

フックモードに関する注意:

• --hook-mode は --staged、--changed-since、--git-history と併用できません。
• --audit はメタデータのみの JSON 行を .shk/audit.log に追記し、常に 0 で終了し、プロジェクトの shk.toml を必要とします。
• --log-blocked は pre フックのブロック動作を維持したまま、メタデータのみのブロックエントリを .shk/audit.log に追記し、プロジェクトの shk.toml を必要とします。--post と併用すると、非ブロッキングの post 監査エントリを書き込みます。
• --post は非ブロッキングで、常に 0 で終了します。検出結果はレビュー用にツール出力に報告されます。
• Cursor の pre フックスキャンは、デフォルトで pre-commit のしきい値を使用します。
• Codex の UserPromptSubmit ペイロードは hook_event_name が UserPromptSubmit の場合にスキャンされます。ブロック時は {"decision":"block","reason":...} を返します。
• Claude Code の UserPromptSubmit ブロックは、標準出力に {"decision":"block","reason":...,"hookSpecificOutput":{"suppressOriginalPrompt":true}} を出力して 0 で終了します。Claude Code はこの JSON を終了コード 0 のときのみ解析し、reason（ルール ID、重要度、プロンプトの行番号、修正方法）がユーザーに表示され、suppressOriginalPrompt によって機密性の高いプロンプトテキストがブロックメッセージに含まれないようになります。プロンプトは引き続きブロックされ、消去されます。
• shk hooks install-ai --tool codex でインストールされるプロジェクトローカルの Codex フックは、サブディレクトリから起動してもリポジトリルートを解決できるよう、. ではなく $(git rev-parse --show-toplevel) をスキャンします。
• Copilot の preToolUse と permissionRequest の拒否は、Copilot のフック規約に合わせて、終了コード 0 の標準出力 JSON で返されます。userPromptSubmitted の出力は Copilot に処理されないため、プロンプトスキャンによるブロックは助言的な警告になります。
• Antigravity の PreToolUse ペイロード（{"toolCall":{"name":...,"args":{...}}}）は、PascalCase の引数名（CommandLine、TargetFile、CodeContent、Url など）で解析されます。ブロック時は {"decision":"deny","reason":...} を、許可時は {"decision":"allow"} を返します。Antigravity の post フックは PostToolUse の出力スキーマに従って常に {} を出力しますが、post スキャンは実行時エラーのテキストがあればログに記録できます。
• Windsurf Cascade のペイロードは agent_action_name とネストされた tool_info（command_line、user_prompt、mcp_tool_arguments、mcp_result、file_path、編集文字列）を使用します。ブロック時は終了コード 2 で、メッセージは標準エラー出力に出力されます。Cascade は判定ペイロードを消費しないため、標準出力は {} です。

shk mask

標準入力またはファイルから機密性の高い値を秘匿化します。

shk mask < prompt.txt
shk mask prompt.txt
shk mask prompt.txt --output out.txt
shk mask report.docx --output report.redacted.docx
shk mask --json < prompt.txt
shk mask --redaction match < prompt.txt
shk mask --redaction partial < prompt.txt
shk mask --min-severity medium < prompt.txt
shk mask --hook-mode cursor < payload.json

オプション:

--pseudonymize と併用できないオプション: --hook-mode、--min-severity、--redaction。

FILE が指定されない場合、shk mask は EOF まで標準入力を読み取ります。対話型の ターミナルでは、入力リダイレクト（shk mask < prompt.txt）を使うか、 ファイルパス（shk mask prompt.txt）を指定して実行してください。

mask --output は、機密性の高い env ファイルや保護対象のホーム設定ファイルへの書き込みを拒否します。バイナリまたは非 UTF-8 の入力は、人間向け出力ではそのまま通過し、JSON 出力では mask.binary_passthrough として報告されます。

Office ドキュメントのマスキングは .docx、.xlsx、.pptx ファイルに対応しており、元のドキュメントを変更しないよう常に --output が必要です。JSON 出力では masked_content として [DOCUMENT_WRITTEN] が報告され、書き換え後のドキュメントからの検出結果が含まれます。PDF のマスキングには対応していません。テキストレイヤー付き PDF の検出結果は shk scan で検出し、PDF の変換や秘匿化は専用の PDF ツールで行ってください。

Office 出力はトランザクショナルです。shk は同じディレクトリに一時アーカイブを作成して確定・同期してから --output を置き換えます。圧縮されたドキュメントがメモリやディスクを使い果たさないよう、ZIP エントリ数と展開後サイズには上限が設けられています。

--pseudonymize は出力の隣に <output>.shk-meta.json を書き込みます。このサイドカーファイルには、正規化バージョン、トークン幅、キーのフィンガープリント、列の種類、件数が記録されます。元の値やトークンは決して含まれません。トークンはプロジェクトローカルであり、同じ保存済みキーとソルトを使用した場合にのみ、同じ入力から同じトークンが得られます。プロジェクト終了時にはキーをローテーションまたは削除してください（shk pseudonymize を参照）。

--pseudonymize と --json を併用すると、そのメタデータのみが出力されます（masked_content と検出結果は省略されます）。

テーブルモードはセル全体を置き換えます（email、phone、name、custom:<label>）。欠損値ではないのに宣言された email または phone の種類として解析できない値は [UNPARSED] になり、メタデータでカウントされ、復元マップから復元することはできません。テキストモードは重要度と許可リスト（allowlist）を無視します。email / phone / name のマッチはトークンになり、secret.* とマッピングされていない検出は [REDACTED] になります。氏名: や Name: のような名前ラベルはそのまま残り、名前のみがトークン化されるため、同一人物についてテーブルモードのトークンと一致します。xlsx テーブルモードでは、テーブルより上の空行はスキップされ、ふりがな（rPh）は無視され、r 属性のないセルは直前のセルの後に配置されます。選択された数式セルは定数に変換されるのではなく拒否されます。xlsx テーブルモードは、選択されたシート上の選択された値セルをインライン文字列として書き換え、参照されなくなった共有文字列の内容を削除します。他のセルやシートから参照されている値はそのまま残ります。テーブルモードはワークブック全体のサニタイズ処理ではありません。XLSX 処理は、10,000 エントリまたは展開後 256 MiB を超えるアーカイブ、64 MiB を超える XML エントリ、1,000,000 セルを超えるグリッドを拒否します。--map は暗号文のみを書き込みます。平文のマップエクスポートは存在せず、復元マップは 64 MiB までに制限されます。復元では、1 つのトークンが複数の入力に対応する場合は最初に出現した元の値を使用し、完全に一致する既知のトークンのみを置き換えます。--map を使用する場合、出力の拡張子は復元形式を保持する必要があります。.csv/.tsv は実際の区切り文字と一致し、xlsx は .xlsx のままとし、Office テキスト出力は入力の拡張子を維持し、プレーンテキスト出力にはテーブルや Office の拡張子を使用してはいけません。CSV/TSV の復元では各フィールドをエスケープするため、元の区切り文字、引用符、改行がテーブル構造を壊すことはありません。入力、出力、マップ、メタデータのパスはすべて異なる必要があり、既存の通常ファイルの出力先はアトミックに置き換えられます。pseudonymize による変更はプロジェクトごとに直列化され、復元用データとメタデータは出力が見えるようになる前にコミットされます。key import は既存のキーの置き換えを拒否します。先に既存のキーを明示的に削除またはローテーションしてください。--check-remaining はシークレット/PII ルールを強制的に有効にし、許可リストとインライン抑制をバイパスします。スキャナーが出力をスキップする場合（[scan] の exclude / include パターン、または max_file_size_bytes を超えるファイル）は、合格ではなく 2 で終了します。--json を付けた場合、終了コード 1 の残留結果の前にメタデータが出力されます。それ以外のすべての失敗（使い方、I/O、キーストア、無効な [pseudonymize] 設定）は 2 で終了するため、終了コード 1 は常に残留検出を意味します。CSV/TSV ファイルはストリーミング処理されるため、テーブルモードはファイル全体をメモリに読み込みません。標準入力はバッファリングされます:

shk mask orders.csv --pseudonymize --columns "Email:email,Phone:phone" --output orders.pseudo.csv
shk mask book.xlsx --pseudonymize --sheet 顧客 --columns "Email:email" --output book.pseudo.xlsx
shk mask notes.md --pseudonymize --output notes.pseudo.md --map notes.shk-map
shk mask --pseudonymize --format csv --columns "Email:email" --output stdin.pseudo.csv < rows.csv
shk mask orders.csv --pseudonymize --dry-run
shk mask out.pseudo.csv --pseudonymize --columns "Email:email" --output checked.csv --check-remaining
shk pseudonymize restore --file notes.pseudo.md --map notes.shk-map --output notes.restored.md
shk pseudonymize key show
shk pseudonymize key export --instructions

テキストと CSV/TSV には UTF-8 が必要です。非 UTF-8 の入力（Shift_JIS を含む）は変換のヒントを表示して 2 で終了します。出力は、キーを持つ人にとっては依然として個人データです。アップロード前に、受け取り側の AI サービスのデータ保持および学習利用の規約を確認してください。.shk-map ファイルは git の管理外に置いてください（デフォルトの doctor.ignore には *.shk-map が含まれています）。--check-remaining を法的な証明や完全性の証明として扱わないでください。

Office テキストモードは、DOCX のメインドキュメント、XLSX のワークシート/共有文字列テキスト、PPTX のスライド、ノート、コメントのテキストを処理します。DOCX のヘッダー/フッターや PPTX のグラフ、マスターなど、その他のパッケージパーツは現在のスコープ外であり、--check-remaining の対象にもなりません。

shk pseudonymize

プロジェクトの仮名化キーを管理し、暗号化された .shk-map から元の値を復元します。トークンは shk mask --pseudonymize によって生成されます。

shk pseudonymize key show
shk pseudonymize key rotate
shk pseudonymize key rotate --yes
shk pseudonymize key delete --yes
shk pseudonymize key export --instructions
shk pseudonymize key import --stdin
shk pseudonymize restore --file notes.pseudo.md --map notes.shk-map --output notes.restored.md

キーは [env].secret_store で選択されたバックエンド（デフォルトでは OS キーリング、または 1Password）に保存されます。Env シークレットストアを参照してください。復元では、1 つのトークンが複数の入力に対応する場合は最初に出現した元の値を使用し、完全に一致する既知のトークンのみを置き換えます。

shk clipboard

OS のクリップボードのテキストをスキャンまたはマスクします。クリップボードは他の信頼できない入力と同様に扱われます。clipboard scan は生のマッチ値を決して出力せず、clipboard mask は秘匿化されたテキストのみを出力します。

shk clipboard scan
shk clipboard scan --json
shk clipboard scan --fail-on critical
shk clipboard mask
shk clipboard mask --json
shk clipboard mask --write
shk clipboard mask --write --redaction partial

shk clipboard scan のオプション:

shk clipboard mask のオプション:

終了コードは共通のセマンティクスに従います。clipboard scan は検出結果が失敗しきい値に達すると 1 で終了し、両方のサブコマンドはクリップボードが利用できない場合（たとえば Linux でディスプレイサーバーがない場合）に 2 で終了します。テキスト以外のクリップボード内容（画像など）と空のクリップボードは、空のテキストとして扱われます。

ポリシーは shk scan や shk mask と同様に、カレントディレクトリの shk.toml から解決されます。

Linux に関する注意: clipboard mask --write の後、X11/Wayland のクリップボード内容は書き込みを行ったプロセスが所有します。クリップボードマネージャーがない場合、置き換えられたテキストはコマンド終了後に保持されないことがあります。macOS と Windows には影響しません。

shk doctor

プロジェクトの診断を実行します。

shk doctor
shk doctor --json
shk doctor --strict

shk doctor はカレントディレクトリに対して利用可能な診断を実行します。フルチェックには、実行中および PATH で解決される shk 実行ファイル、Git フック、管理対象の AI ツールフック、ignore の網羅状況、平文の env ファイル、GitHub Actions のチェックアウト強化、そして package.json がある場合は npm/パッケージマネージャーのサプライチェーン強化が含まれます。

PATH 上に複数の異なる shk 実行ファイルがある場合（たとえばインストーラー、Homebrew、npm によるインストールが別々に存在する場合）、doctor は PATH が最初に選択する実行ファイルと、それに隠される場所を報告します。シンボリックリンクを通じて同じバイナリに解決されるパスは重複排除され、隠された実行ファイルが実行されることはありません。

助言的な警告はデフォルトでは非ブロッキングのままです。shk doctor --strict は助言的な警告が 1 つでもあると 1 で終了するため、フルスイートを CI で使用できます。実行時エラーや設定エラーは従来どおりのエラー終了動作を維持します。JSON 出力には ok、strict、warningCount、shkExecutable、およびメタデータのみの envSecretStore フィールドが含まれます。設定の失敗も有効な JSON として出力され、2 で終了します。フルスイートは 1Password の静的な設定チェックのみを行います。明示的なライブの op --version / op whoami チェックが必要な場合は shk doctor env を使用してください。--strict はフルスイートでのみ受け付けられます。shk doctor --strict <subcommand> はエラーで終了します。

shk doctor ignore

Git および AI 向けの ignore ファイル全体で ignore の網羅状況を確認します。

shk doctor ignore
shk doctor ignore ./path
shk doctor ignore ./path --fix

ignore 診断は、存在する場合に .gitignore、.cursorignore、.cursorindexingignore、.codeiumignore、.clineignore、.aiderignore、.continueignore、.tabnineignore、.ignore、.aiignore を確認します。

また、Claude Code の .claude/settings.json（permissions.deny に推奨されるアクションガードの拒否エントリが含まれているか、推奨されるサンドボックス設定が存在するか）と、Codex の .codex/config.toml のフック/サンドボックス設定についても、それらのファイルが存在する場合に報告します。

--fix は shk.toml を必要とし、不足している必須パターンを .gitignore に追記します。

shk doctor env

プロジェクトルートの平文 .env ファイルを確認し、設定されている env シークレットストアのバックエンドを報告します。

shk doctor env
shk doctor env --dotenvx
shk doctor env ./path

.env.example、.env.sample、dotenvx 関連ファイル（.env.keys、.env.vault）、dotenvx で暗号化された env ファイル、shk env encrypt の出力ファイルは、平文 env ファイルの警告から除外されます。暗号化された env ファイルに新たに追加または編集された平文の値が含まれている場合、doctor env はその平文のキー名を報告し、shk env encrypt <file> --in-place の再実行を推奨します。--dotenvx を付けると、.env.keys や .env.vault などの既知の dotenvx 関連ファイルについても報告します。

[env].secret_store = "1password" の場合、診断は env.project_id、env.onepassword.vault、op の解決（SHK_OP_PATH、既知のパス、または PATH）、CLI バージョン（最低 2.24.0）、サインイン状態（op whoami）も確認します。secret_store = "keyring" の場合は、OS キーリングが有効なバックエンドであることを報告します。

shk doctor workflows

GitHub Actions ワークフローのチェックアウトステップにおける認証情報の永続化を確認します。

shk doctor workflows
shk doctor workflows ./path
shk doctor workflows --fix

この診断は .github/workflows/*.yml および *.yaml をスキャンし、persist-credentials: false を設定していない actions/checkout ステップを報告します。この設定がないと、actions/checkout はワークフローの GitHub トークンを後続のステップが読み取れる Git 認証情報ファイルに残すため、侵害された、あるいは注入された後続ステップがトークンを外部に持ち出すことができます。

--fix は shk.toml を必要とし、フラグの付いたチェックアウトステップに persist-credentials: false を追加します（必要に応じて with: ブロックを作成するか、明示的な true を反転します）。既存の書式、コメント、ファイルの行末（LF または CRLF）は保持されます。これはプロジェクト専用の強化補助であり、GitHub Actions の完全なリンターではありません。

shk doctor version

GitHub の最新リリースバージョンを確認します。

shk doctor version
shk doctor --json version

このコマンドは更新が利用可能かどうかを報告します。インストール済みのバイナリは変更しません。

shk env encrypt / shk env decrypt

shk ネイティブの暗号化で dotenv ペイロードを暗号化および復号します。これは外部の dotenvx コマンド統合とは別のものです。dotenvx のサポートは引き続き shk env dotenvx で利用でき、ネイティブ暗号化により shk は外部の dotenv 暗号化ツールなしで動作できます。

shk env encrypt .env --in-place
shk env run -- npm test
shk env key import
shk env key export --instructions
shk env decrypt .env --output .env.local
shk env encrypt .env --output .env.shk
shk env encrypt .env.production --env production --output .env.production.shk
shk env run -f .env.production --env production -- npm start
shk env decrypt .env.production.shk --env production --output .env.production.local

暗号化キーペアはプロジェクトと環境ラベルごとに生成され、公開鍵は DOTENV_PUBLIC_KEY* として .env ファイルに書き込まれ、秘密鍵は設定された env シークレットストア（shk.toml の [env].secret_store）に DOTENV_PRIVATE_KEY* として保存されます。デフォルトでは OS キーリングが使用され、チームは 1Password をオプトインで選択できます。値は KEY="encrypted:..." として書き込まれ、キー名と dotenv ファイルの形式は保持されます。encrypt で --in-place を使うと、.env のファイル名を維持したまま平文の値を暗号化された値に置き換えます。代わりに別の暗号化ファイルを書き出すには --output を使用します。既存の出力ファイルは --force を渡さない限り拒否されます。decrypt は平文が誤って標準出力に書き出されないよう、常に --output を必要とします。日常的な利用には shk env run を推奨します。これは値をメモリ上で復号し、結果として得られるアプリケーション変数のみを子プロセスに注入します。

shk env encrypt が書き込むファイルには、DOTENV_PUBLIC_KEY* ブロックの前にコメントのみの [SHK_NATIVE_ENV] ヘッダーが含まれます。これにより、既存の暗号化 dotenv 値の形式を保ちつつ、ファイルを読んだときにネイティブの shk 出力であることが分かります。

暗号化された env ファイルに変数を追加または更新するには、その行を平文で編集してから、すぐに暗号化を再実行します。

# .env に行を追加または編集する（例: NEW_API_KEY=...）
shk env encrypt .env --in-place
shk doctor env

既存の encrypted: 値は暗号化されたまま残り、次回の encrypt 実行では平文の値のみが暗号化されます。doctor env は暗号化された env ファイルに平文のキーが残っている場合に警告するため、コミットやリリースの前に再暗号化の漏れを見つけるのに役立ちます。

既存の dotenvx ユーザーは、キーを一度インポートしてから実行時コマンドを切り替えます。

shk env dotenvx import-keys .env.keys
shk env run -f .env -- npm test

shk env run、decrypt、encrypt は、まずネイティブの shk キーを使用します。存在しない場合は、設定された env シークレットストアからインポート済みの dotenvx DOTENV_PRIVATE_KEY* 値を再利用し、必要に応じて公開鍵を導出し、そのキーをネイティブストアへ取り込もうとします。これにより、既存の dotenvx で暗号化されたファイルを使い続けながら、通常の実行経路から外部の dotenvx バイナリを取り除けます。ネイティブコマンドがインポート済みキーの取り込みを報告した後、プロジェクトで shk env dotenvx run が不要になった場合は、shk env dotenvx delete --all でインポート済みの dotenvx コピーを削除できます。取り込み時に警告が表示された場合は、インポート済みの dotenvx コピーを残すか、shk env key import でキーをインポートしてください。

shk env run は -f, --file <file> を複数回指定でき、ファイルが指定されない場合は .env をデフォルトとします。--env または --key が指定されない限り、プロジェクトのデフォルトキーを使用します。shk env dotenvx run とは異なり、外部の dotenvx バイナリを呼び出さず、DOTENV_PRIVATE_KEY* を子プロセスに渡しません。

shk env key

.env.keys をコミットせずに、ローカルの復号キーを登録し、安全なチーム引き継ぎ手順を表示します。

shk env key import
shk env key import --env production --stdin
shk env key import --key DOTENV_PRIVATE_KEY_STAGING --force
shk env key list
shk env key delete --env staging
shk env key delete --all
shk env key export --env production --instructions
shk env key migrate --to 1password
shk env key migrate --to keyring

import は現在のプロジェクト用に 1 つの DOTENV_PRIVATE_KEY* 値をネイティブの env シークレットストアに保存します。--force を渡さない限り、すでに保存されているキーの置き換えは拒否されます。--stdin がない場合は、入力をエコーせずにキーの入力を求めます。--stdin を付けると、パスワードマネージャーの CLI から読み取れます。

op read "op://Project/prod/DOTENV_PRIVATE_KEY_PRODUCTION" \
  | shk env key import --env production --stdin

list は現在のプロジェクト用にインデックスされたネイティブキーの名前のみを表示し、キーの中身は決して表示しません。delete は保存されたネイティブキーを削除し、明示的な対象（--all、--key <DOTENV_PRIVATE_KEY*>、または --env <name>）を必要とします。古いバージョンで作成されインデックスされていないキーも、正確な --key または --env の対象指定で削除できます。

export には --instructions が必須で、意図的に生のキーの中身を表示しません。キー名、このマシンにキーがすでに存在するかどうか、そして推奨されるローカル引き継ぎフロー（チームのパスワードマネージャーにキーを保存し、チームメンバーと vault のアクセス権を共有し、受け取り側に shk env key import を実行してもらう）を表示します。

shk env key migrate

env の秘密鍵を shk.toml で設定されたバックエンドから別のバックエンドにコピーし、成功時に env.secret_store を更新します。

1Password バックエンドへの移行や利用には、1Password CLI（op）のバージョン 2.24.0 以降と、認証済みの op セッションが必要です。移行前に op --version、op whoami、shk doctor env を実行して前提条件を確認してください。キーリングへの移行では移行先に op は不要ですが、現在の移行元バックエンドが 1Password の場合は、キーを読み取るために引き続き op が利用可能である必要があります。

# 一般的なキーリング → 1Password への移行
# 1. secret_store を "keyring" のままにして shk.toml に project_id と vault を設定する
# 2. migrate を実行する（キーのコピー後に shk.toml を "1password" に更新する）
shk env key migrate --to 1password

# 移行先を確認してから、移行元のコピーを明示的に削除する。

# 1Password が設定されている状態で OS キーリングにロールバックする
shk env key migrate --to keyring

移行では、インデックスされたキーに加えて、プロジェクトツリー全体の .env / .env.keys ファイルから参照されているキー（たとえば一致する DOTENV_PUBLIC_KEY* 名によるもの）をコピーします。.git、node_modules、target ディレクトリは除外されます。インデックスエントリもプロジェクト内の env 参照もなく、移行元バックエンドにのみ存在するキーは自動的には検出されません。移行前に明示的な shk env key delete --key … で削除するか、手動で移行先にインポートしてください。

このコマンドは、現在の設定がすでに壊れたバックエンドを指している場合でも、移行開始前に移行先バックエンドを開くことはありません。env.secret_store からキーを読み取り、--to に書き込みます。shk.toml ですでに設定されているバックエンドへ migrate を再実行することは拒否されます。

成功時のフロー:

1. キーを移行先バックエンドにコピーします。
2. ポリシーファイルが存在する場合、shk.toml の env.secret_store を --to の値に更新します。
3. ロールバック用に移行元のキーを保持します。

移行先を確認した後、移行元のキーを明示的に削除してください。対応バックエンドには移植可能な条件付き削除操作がないため、移行では自動的に削除されません。

[env] / [env.onepassword] の設定については設定を、1Password の脅威モデルに関する注意については README を参照してください。

shk env dotenvx

dotenvx の秘密鍵を設定された env シークレットストアに保存し、dotenvx 経由でコマンドを実行するときにのみ注入します。

shk env dotenvx import-keys .env.keys
shk env dotenvx list
shk env dotenvx run -- npm test
shk env dotenvx run -f .env.production -- npm start
shk env dotenvx run --env production -- npm start
shk env dotenvx run --key DOTENV_PRIVATE_KEY_PRODUCTION -- npm start
shk env dotenvx delete --env production
shk env dotenvx delete --key DOTENV_PRIVATE_KEY_PRODUCTION
shk env dotenvx delete --all

このコマンドグループは、shk.toml の [env].secret_store で設定された env シークレットストアに dotenvx の秘密鍵を保存します。デフォルトのバックエンドは OS キーリング（プラットフォームのサポート状況に応じて macOS Keychain、Windows Credential Manager、または Linux Secret Service / keyutils）です。secret_store = "1password" の場合、同じキーが設定された vault にタグ付きの 1Password アイテムとして保存されます。

import-keys は .env.keys 形式のファイルから DOTENV_PRIVATE_KEY と DOTENV_PRIVATE_KEY_<ENV> のエントリのみを読み取ります。生のキー値は決して表示されません。run は現在のプロジェクト用に保存されたキーを読み取り、それらの値を子プロセスの環境にのみ存在させて dotenvx run -- <command> を呼び出します。delete は明示的な対象（--all、--key <DOTENV_PRIVATE_KEY*>、または --env <name>）を必要とします。

生の秘密鍵を表示したり書き出したりすると .env.keys を設定されたシークレットストアに移す目的が損なわれるため、shk env dotenvx には意図的に生のキーのエクスポートがありません。キーの中身を表示しない安全な引き継ぎのガイダンスには shk env key export --instructions を使用してください。

run のオプション:

delete のオプション:

shk secrets push

生のシークレット値を表示せずに、dotenv ペイロードを AWS Secrets Manager または GCP Secret Manager にプッシュします。

# dotenv ファイル全体を 1 つのシークレットとして保存する。
shk secrets push --provider aws --target app/prod/dotenv --from .env.production

# 各 dotenv キーをターゲットプレフィックス配下の個別のシークレットとして保存する。
shk secrets push --provider gcp --mode per-key --target-prefix app/prod/ --from .env.keys

# プロバイダー CLI を呼び出さずに、書き込み内容とターゲット名をプレビューする。
shk secrets push --profile prod --dry-run

オプション:

動作に関する注意:

• shk secrets push はプロジェクトルートを必要とし、そのルートから shk.toml を読み取ります。
• --no-scan が渡されない限り、ソースファイルはプッシュ前に PII スキャンされます。
• blob モードには --target が、per-key モードには --target-prefix が必要です。
• per-key モードは dotenv 形式の KEY=value 行を受け付け、重複キーを拒否し、キーを [A-Z_][A-Z0-9_]* として検証します。
• AWS と GCP への書き込みは公式の aws および gcloud CLI を通じて行われます。引数はシェルを介さず直接渡されます。

shk hooks install

shk scan --staged を実行する Git pre-commit フックをインストールします。

shk hooks install
shk hooks install --pre-commit

このコマンドには Git リポジトリとプロジェクトの shk.toml が必要です。フックは管理用マーカーを使用しており、再実行できます。

shk hooks install-ai

対応ツール向けの管理対象 AI ツールフックをインストールします。

shk hooks install-ai
shk hooks install-ai --dry-run
shk hooks install-ai --audit
shk hooks install-ai --log-blocked
shk hooks install-ai --tool cursor
shk hooks install-ai --tool claude-code --global
shk hooks install-ai --tool claude-code --apply-deny
shk hooks install-ai --apply-sandbox
shk hooks install-ai --tool cursor --fail-closed
shk hooks install-ai --tool copilot
shk hooks install-ai --tool antigravity
shk hooks install-ai --tool windsurf # Windsurf (Cascade)

オプション:

--tool を指定しない場合、このコマンドは Claude Code、Codex、Cursor、Copilot、Antigravity、Windsurf を対象とします。dry-run でないインストールにはプロジェクトの shk.toml が必要です。

プロジェクトインストールでは、コミットされた設定ファイルがすべてのチームメンバーのマシンで動作するよう、管理対象フックコマンドの可搬性を保ちます。Claude Code のコマンドは "${CLAUDE_PROJECT_DIR:-.}" を、Cursor のコマンドは "${CURSOR_PROJECT_DIR:-.}" をスキャンし（いずれも実行時にエディターのフックシェルが展開し、変数がない場合は . にフォールバックします）、Codex のコマンドは $(git rev-parse --show-toplevel) をスキャンします。Copilot、Antigravity、Windsurf のコマンドはパス引数を取らず、shk scan --hook-mode がフックプロセスの作業ディレクトリからプロジェクトルートを解決します。埋め込まれたパスが存在しないか別のチェックアウトを指している場合（たとえば展開されていない変数や移動されたクローン）、フックモードは cwd ベースのプロジェクトルート探索にフォールバックします。

インストールされるエントリ:

Antigravity には統合された権限エンジン（Deny > Ask > Allow、リソースは action(target) 形式）もありますが、これらのリストは Antigravity の設定 UI と内部のプロジェクトごとの設定で管理されます。そこに貼り付けるための推奨 Deny エントリを表示するには shk hooks install-ai --tool antigravity --apply-deny を使用してください。いずれにせよ、shk の PreToolUse フックが同等の実行時ブロックを提供します。

管理対象エントリには "_shk_managed": true または # shk-managed-start / # shk-managed-end のタグが付けられます。Copilot と Windsurf はスキーマに準拠した設定を保つため、代わりに --hook-mode <tool> コマンド文字列で管理対象エントリを識別します。再実行すると管理対象エントリは置き換えられ、管理対象外のエントリはそのまま残ります。

管理対象フック、スキル、生成されたワークフロー、保存済み dotenvx キーの削除についてはアンインストールを参照してください。

pre フックモードでは、shk はコンテンツスキャンの前にアクションガードも実行します。フックペイロード内に見える場合、機密ファイルへのアクセス、環境変数のダンプコマンド、破壊的なファイルシステム操作、データベースへの直接的な変更コマンド、権限やシステムの変更、外部への転送コマンド、パッケージマネージャーの操作をブロックします。これは shk.toml の [action_guard] で調整できます。--audit は非ブロッキングのままで、--log-blocked はアクションカテゴリのみを記録します。

アクションガードの許可パターンは、デフォルトで個々のシェルセグメントに適用されます。最初のコマンドに対するパターンは、後続の &&、||、パイプ、セミコロン区切りのコマンドを暗黙的に許可しません。複合コマンドの許可には区切り文字を含め、信頼できるコマンド全体をカバーする必要があります。

shk ci init github

バンドルされた cargo-dist インストーラーから shk をインストールし、すべてのプルリクエストと main へのプッシュで shk scan を実行する GitHub Actions ワークフローを生成します。

shk ci init github
shk ci init github --dry-run
shk ci init github --mode audit
shk ci init github --fail-on critical
shk ci init github --upload-sarif
shk ci init github --shk-version v0.7.0
shk ci init github --output .github/workflows/security.yml --force

オプション:

生成されるワークフローには permissions: contents: read と、cancel-in-progress: true を持つ concurrency ブロックが含まれるため、同じ ref での再実行は進行中のジョブを置き換えます。--upload-sarif を付けると、生成されるワークフローは security-events: write と actions: read も付与します。プライベートリポジトリでは GitHub Code Security が必要です。CLI は、生成されるリリースダウンロードコマンドが正しい形式を保つよう、--repo と --shk-version の安全でない値を拒否します。

生成される YAML、ブロッキングと監査モードでのロールアウト、リリースの固定（ピン留め）、PR の Required Check 設定を網羅した完全なガイドは、GitHub Actions 連携を参照してください。

shk skills

shk にバンドルされた Claude Code / Codex / Cursor / Copilot / Antigravity / Windsurf のスキルを管理します。スキルはバイナリに埋め込まれており、必要に応じてプロジェクトディレクトリに配置されます。

shk skills list
shk skills status
shk skills install
shk skills install --tool claude-code
shk skills install --tool codex
shk skills install --tool cursor
shk skills install --tool copilot
shk skills install --tool antigravity
shk skills install --tool windsurf
shk skills install --tool all --global
shk skills install --dry-run
shk skills install --force

shk skills list

インストール可能な組み込みスキルを表示します。

shk skills status

対応するすべてのツール（プロジェクトパスとグローバルパス）のインストール状態を表示します。

shk skills install

shk スキルを現在のプロジェクトのスキルディレクトリにインストールします。

オプション:

インストール先:

すべてのインストール先は、オープンエージェントスキル標準のディレクトリ + SKILL.md レイアウトを使用しており、これは Claude Code がスキルを読み込むレイアウトでもあります。スキルファイルはビルド時に shk バイナリに埋め込まれており、ネットワークアクセスは不要です。

バージョン 0.3.17 までは Claude Code のスキルをフラットな .claude/skills/shk.md ファイルとして書き込んでいましたが、Claude Code はこれを読み込みません。shk skills install を再実行すると新しいレイアウトで書き込まれ、レガシーのフラットファイルは削除されます。