mcpField
S
shell-snippet-fmt

shell-snippet-fmt

github.com/petr-korobeinikov開発162 回インストール2 日前に更新
リポジトリ

shell-snippet-fmt について

shell-snippet-fmt は、動作を変えずにシェルスニペットを読みやすく整えるスキルです。1 行 120 列以内の制限と、長いコマンドを安全に継続する方法を定めています。

主な機能

  1. 011 行 120 列の上限
  2. 02コマンドを安全に継続する位置
  3. 03引用文字列と heredoc の規則
  4. 04ドキュメントやスクリプトの整形指針

活用シーン

  1. 01ドキュメント内の長いシェルコマンドの折り返し
  2. 02長いコマンド行を含むスクリプトの編集
  3. 03チャットや差分内のシェルスニペットの確認

インストール

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

$npx skills add https://github.com/petr-korobeinikov/skills --skill shell-snippet-fmt

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

詳細

shell-snippet-fmt

シェルスニペットは、各行が120桁以内に収まるよう常に整形してください。 行が上限を超える場合は、 安全な位置で改行し、行末に \ を付けて続けてください。

理由

120桁の上限を設けることで、幅の狭いターミナル、 GitHub の差分、 左右に並べたレビュー画面、 チャットウィンドウでもスニペットを読みやすくできます。 シェルコマンドの意味を変えずに改行する、移植性のある唯一の方法は、明示的な \ による継続です — シェルは引用符で囲まれた文字列やヒアドキュメント内の空白をそのまま保持するため、 そこで改行するとプログラムの動作が変わってしまいます。

ルール

  • シェルスニペットの各行は、視覚上の幅が120桁以下でなければなりません （バイト幅にかかわらず、文字ごとに1桁として数えます）。
  • 行が上限を超える場合は、 上限内に収まる範囲で最も後ろにある安全な位置で改行し、 行末に \ を置いてください。
  • \ の後には何も付けません — スペースもコメントも付けず、 改行だけにしてください。
  • 継続行は、コマンドの開始位置から4つのスペース分インデントします。
  • スニペットがすでに1行で120桁以内に収まっている場合は、 1行のままにすることも、 複数行のほうが明確であれば改行することもできます （複雑なパイプライン、多数のフラグ、ヒアドキュメント、短いトークンに混じる長いURLなど）。 簡潔さよりも読みやすさを優先してください。 120桁は厳格な上限であり、目標ではありません。

安全な改行位置

シェルが結果を1つの論理コマンドとして解釈できる位置でのみ改行してください。

  • フラグの前（--flag または -f value）。
  • パイプの前（|）。
  • 論理演算子の前（&&、||）。
  • リダイレクトの前（>、>>、<、2>&1）。
  • それぞれが単独で完結するトークンである場合、位置引数の間。

絶対に改行しない箇所

  • 引用符で囲まれた文字列の中 — '...' の中では \<newline> がそのまま保持されます （シングルクォートはエスケープを解釈しないため）、 そのため出力されたテキストには余分なバックスラッシュと改行が入ります。 "..." の中では、POSIX は \<newline> を行継続として扱い、 両方を暗黙に削除して前後のテキストを連結します。 どちらの場合も、出力される文字列は1行の場合と異なります。
  • ヒアドキュメントの本文（開始位置の <<EOF と終端の間） — 内容はコマンドにそのまま渡されるため、 \<newline> を挿入するとデータの一部になります。
  • 引用符で囲まれていないトークン — 分割すると単語の区切りが変わります。
  • URL、 パス、 識別子、 その他の分割できない要素。
  • 分割できないトークンだけで120桁を超える場合は、 行を上限より長いままにし、 上限を意図的に緩和したことが読者に伝わるよう周囲の文章に例外を記載してください。

例

悪い例 — 138桁の1行：

docker run --rm -it --name foo -v "$PWD:/work" -w /work -e FOO=bar -e BAZ=qux ghcr.io/example/tool:1.2.3 build --target prod --output dist

良い例 — \ で改行し、各行が120桁以内：

docker run --rm -it --name foo \
    -v "$PWD:/work" \
    -w /work \
    -e FOO=bar \
    -e BAZ=qux \
    ghcr.io/example/tool:1.2.3 \
    build --target prod --output dist

次の3つの例（パイプ、論理演算子、ヒアドキュメント）は、改行の規則がわかりやすいよう短くしてあります — 「役立つ場合にのみ改行する」というルールは変わりませんが、 改行が必要な場合は、ここに示した形式を使ってください。

パイプは継続行の先頭に置き、 前の行の末尾に \ を付けます。

curl -sSL https://example.com/data.json \
    | jq '.items[]' \
    | head -20

論理演算子も同じ形式にします。

docker build -t image:tag . \
    && docker push image:tag \
    && echo "deployed"

ヒアドキュメント — コマンドの周囲を改行し、 ヒアドキュメントの本文には手を加えません（\ を付けず、元の行をそのまま残します）。

ssh -o ConnectTimeout=10 \
    -o StrictHostKeyChecking=no \
    deploy@host bash <<'EOF'
cd /app
./run --restart
EOF

悪い例 — \ と改行の間にコメントを入れると、行継続が無効になります。

docker run \  # mount the work dir
    -v "$PWD:/work" image

\ の後に改行ではなくスペースと # が続くため、 シェルは行の継続をやめ、 次の行の -v を別のコマンドとして解釈します。 コメントはコマンドの上に独立した行として記述し、 行末の \ の後には置かないでください。

悪い例 — 引用符で囲まれた文字列の中で改行すると、プログラムの出力が変わります。

echo 'this is a very long error message that needs to clearly demonstrate \
exceeding the 120-character width limit when written on one line'

シングルクォートでは \<newline> が \ と改行としてそのまま出力されます。 ダブルクォートでは POSIX がそれを削除して隣接するテキストを連結します — どちらの場合も、結果は1行の場合と異なります。 行が120桁を超えても、文字列全体をそのままにしてください。

echo 'this is a very long error message that needs to clearly demonstrate exceeding the 120-character width limit when written on one line'

長いURL、パス、ハッシュなど、分割できないトークンにも同じことが当てはまります。

curl -O https://github.com/very-long-org-name/very-long-repo-name/releases/download/v1.2.3-rc.4/binary-name-linux-amd64.tar.gz

上限を意図的に緩和したことが読者に伝わるよう、 上限を超える行について周囲の文章に記載してください。

適用範囲

作成または編集する、あらゆるシェルスニペットに適用されます。

  • チャットの回答内のフェンス付きコードブロック。
  • SKILL.md／README.md／ドキュメント内のスニペット。
  • scripts/ 配下のスクリプト。
  • Makefile のレシピ。
  • CI 設定（GitHub Actions の run:、GitLab の script:）。
  • Dockerfile の RUN 命令。
  • インストール手順やワンライナー。

ファイルの編集中に、折り返されていない長いコマンドを見つけた場合は、 同じ編集の一部として整形してください。

コメント

Markdown 対応