スキル名の区切り文字（ハイフン / ドット）を選択可能に

[ysak-y]

概要

一部の LLM プラットフォームは Agent Skills 準拠のハイフン区切りのスキル名しか使えないため（参考: spec-kit #2354）、miko のスキル名の区切り文字を選択できるようにしました。あわせてスキル名内のアンダースコアをハイフンに統一しています。

方式

1. install.sh が言語選択に続けて区切り文字を対話で確認します。デフォルトはどこでも動作するハイフン区切り（/miko-setup）で、ドット区切り（/miko.setup、従来形式）も選べます。非対話実行時はプロンプトなしでハイフンになります
2. 選択は .miko/config の separator= に保存され、スキルディレクトリ名とファイル内のスキル名参照（frontmatter の handoffs 含む）がインストール・アップグレード時に自動変換されます。後から変更する場合は miko を削除して再インストールします
3. tone_guide（日英）に「出力でスキル名に言及するときは config の separator に従う」を明記し、LLM が生成する案内文のスキル名表記も設定に追従させます
4. スキル名の _ を - に統一（miko.new_cap → miko.new-cap 等 6 スキル）。ハイフン区切り選択時に miko-new_harae のような混在表記になるのを避けるためです
5. 既存インストールは upgrade 時に separator=. が補完されドット区切りのまま。旧アンダースコア名のスキルは削除確認のうえ新名で再配置されます

あわせて修正

• upgrade.sh が macOS 標準の bash 3.2 で中断する問題（protected_skills が空のときの set -u 下での空配列展開）
• bash 3.2 で変数直後にマルチバイト文字が続くと変数名の解釈に失敗する問題（${VAR} ブレース化）

レビューの手引き

コミットを段階で分けています:

• 8c3e1ac + aa008d8: 初版（setup スキルでの初回確認方式 + 切り替えスクリプト）
• 84b1ac5: アンダースコア → ハイフンの機械的リネームのみ（+116/−116 の対称置換。削除行がすべて旧名・追加行がすべて新名を含むことを検証済み）
• 1f67518: インストール時プロンプト方式への変更 + tone_guide 追記
• dbdb68f: switch_separator.sh / skills_manifest の廃止（区切り文字の変更は再インストールに一本化）

初版で導入して後続コミットで廃止したものがあるため、ブランチ全体の Files changed で見るのが確実です。実質は install.sh / upgrade.sh / miko.setup / tone_guide / README / リネームに収まります。

テスト

ローカル tarball を使い、すべて macOS 標準 /bin/bash（3.2）で実施:

• 対話インストール（疑似 tty）: 「2」回答 → ドット配置 / 空回答 → ハイフン配置
• 非対話インストール → プロンプトなしでハイフン配置、_ を含むスキル名ゼロ、参照の残存ゼロ
• 実際の v1.3.2（main の HEAD）をインストール → 本ブランチへアップグレード → 旧アンダースコア名 6 スキルが削除確認に列挙され、承認後に新名で再配置。separator=. が補完されドット維持
• プロテクト済みカスタムスキルは upgrade で無傷
• ~/work/boron-student で実際にインストールし、動作確認

🤖 Generated with Claude Code

https://claude.ai/code/session_01TZs89bL3xt4Yy7iVY3ooE2

[kikaineko]

SKILL.md内部は ドット区切りであることを明記してください

[ysak-y]

e5140eb

[kikaineko]

Suggested change

	- `separator=.` → ドット区切りで表記する
	- `separator=dot` → ドット区切りで表記する
	- `separator=hyphen` → ハイフン区切りで表記する

[ysak-y]

9b0d462 な感じで全体で dot/hyphen 表記にしました

[kikaineko]

defaultは dot であるってすればいいかと思います

[ysak-y]

9fc08ca

[kikaineko]

このへん、これ使えないですかね？（無理かな？）
https://github.com/studyplus/miko/tree/main/migrations

[ysak-y]

こんな感じで作成してみました。手元で試したところ期待通りの挙動してくれましたがわざわざ LLM でやらなくてもという気もややします。 (が動くので強い気持ちはないです)

3ad1b80

[kikaineko]

まぁLLMでやる必要ないんですが、update.shにいれるとずっと消せないなぁっていう。
あと、そういう意味では migrationにshellかいて、それを実行してって指示すればいいかなとは思ってます

[ysak-y]

こんな感じでいかがでしょうか？
9760706

[ysak-y]

動作確認してて気がついたのですが、マイグレーション実行の箇所にバグがあったのでついでに修正しました。
d1ed468

下記 Claude Code による解説。

バグの再現（後続の read 用に渡した入力を claude -p が食ってしまう）:

printf 'y\n' | { claude -p 'ok とだけ出力してください' > /dev/null; if read -r ans; then echo "read の結果: [$ans]"; else echo "read が EOF で失敗（claude が stdin を消費した）"; fi; }

→ 出力: read が EOF で失敗（claude が stdin を消費した）

修正版（d1ed468 と同じく claude の stdin を /dev/null に切り離す）:

printf 'y\n' | { claude -p 'ok とだけ出力してください' > /dev/null < /dev/null; if read -r ans; then echo "read の結果: [$ans]"; else echo "read が EOF で失敗"; fi; }

→ 出力: read の結果: [y]

仕組み: claude -p は stdin がパイプのとき、その内容を追加入力として EOF まで読み切ります（echo hello | claude -p '要約して' が動くのはこの仕様のため)。上の例では read に渡すつもりの y\n が claude に渡ってしまい、read の番になったときには stdin が EOF になっています。

upgrade.sh での発現条件: stdin が tty の対話実行（bash <(curl ...)）では claude は入力を読みに行かないので発症しません。echo y | bash upgrade.sh のようなパイプ実行・CI などの非対話実行で、migration が 1 件以上走り、かつその後の削除確認プロンプト（read）に到達する、という組み合わせで発症します（set -e のため read の EOF 失敗で upgrade 全体が exit 1 で中断)。

[kikaineko]

動作確認してて気がついたのですが、マイグレーション実行の箇所にバグがあったのでついでに修正しました。

ひーーー