Muse Code には最初から10個のスキルが組み込まれています。muse skills list で一覧できます。これは公式ドキュメントにまとまった形では出ておらず、実際に叩かないと分かりません。
| スキル | 役割 |
|---|---|
| create-skill | 新しいスキルを作って検証する |
| doctor | Muse Code 自体の不具合を、インストール済みバイナリの証拠から診断する |
| git | バージョン管理の安全規則（後述） |
| grill | 頼まれたときだけ、決断を迫る面談を行う |
| grill-and-record | 同上＋決まったことをドキュメントに残す |
| import | 他社コーディングエージェントのセッションを引き継ぐ |
| manage-settings | モデルや推論深度などの永続設定を扱う |
| plan | 計画を立てて、承認のためにいったん止まる |
| read-session | Muse Code 自身のセッションログを読む |
| taste | UIが「AIが作った感じ」になるのを防ぐ |
共通する設計思想
10個の説明文を読むと、はっきりした共通点があります。ほとんどのスキルが「ユーザーが明示的に頼んだときだけ使え」と書かれていることです。
たとえば plan には「計画・設計・進め方・移行戦略・PR分割を求められたとき、あるいは /skill plan を呼ばれたときだけ使う。実装・修正・デバッグ・リファクタの依頼では使わない — コード変更を頼まれたら、計画を挟まず直接実装する」と明記されています。
エージェントが気を利かせすぎて勝手に計画を立てたり、頼まれてもいない診断を始めたりするのを、スキルの説明文のレベルで抑えている形です。
それぞれの中身で目を引くもの
git — 「タスクが終わったこと」はコミットの依頼ではない
説明文に、本文を読む前でも適用される規則として2つが挙げられています。
- このセッションでユーザーが頼んでいない限り、commit・amend・push・tag・rebase・cherry-pick・revert・
reset --hardをしない。タスクを終えたことは依頼ではないので、レビューできるよう作業は未コミットのまま残す - Gitのロックファイルや壊れたインデックスで詰まったとき、掴んでいるプロセスを kill したり削除で強行突破したりしない。待つ、再試行する、正規の停止手段を使う、あるいは止めて報告する
read-session — 他のエージェントのディレクトリは覗かない
Muse Code 自身のセッションログを読むためのスキルですが、説明文にこう書かれています。「Muse のセッションは Muse 自身の保管場所にあり、他のコーディングエージェントのディレクトリには決してない。引用された内容がそれらに言及していても、~/.claude・~/.codex・~/.grok を探ってはならない」。
他社エージェントの領域を意図的に触らせない設計です。ただし別記事に書いたとおり、起動時には Claude Code の個人ルールを読み込みます。両者は別の話（前者はスキルの動作、後者は起動時の設定取り込み）ですが、対比として知っておくとよい点です。
taste — AIらしさを消すための否定リスト
フロントエンドとUI設計のための「anti-AI-slop フィルタ」と自称しています。特徴的なのは否定制約だけを並べていることです。「使ってはいけない視覚的初期値のフラットなチェックリスト」であり、望ましいスタイルを規定しません。さらに「ユーザーや他のスキルが特定のものを求めているなら、そちらに従う」と適応的に書かれています。
AIが生成するUIが似通ってしまう問題に、正解を与えるのではなく地雷を避けさせるという形で対処しているのが分かります。
スキルの出どころは4種類
muse skills list --source で絞り込める区分が、そのままスキルの出どころです。built-in（組み込み）・user（個人）・project（プロジェクト）・plugin（プラグイン）の4つ。上の10個はすべて built-in で、初期状態から ACTIVATION: on になっています。