自分自身を検査する仕組み

Muse Code には、自分自身の動きを検証するための仕組みが2つあります。コマンドの muse trace と、組み込みスキルの doctor です。

muse trace — 記録されたトレースを検査する

muse trace inspect [OPTIONS]

muse trace inspect --help で確認できるフラグに、扱えるものの範囲が現れています。

• fixture — 固定の入力データ
• session-log — セッション単位のログ
• run-log — 実行単位のログ
• task-log — タスク単位のログ
• render-mode — 表示の仕方
• format — 出力形式

ログが session / run / task の3層に分かれているのは、イベントログのストリーム構造と対応しています。層ごとに切り出して見られるということです。

fixture が扱えるのは、再現用の固定データを流して挙動を確認する使い方を想定しているためでしょう。

doctor スキル — 製品自体の不具合を診断する

組み込みスキルの doctor は、説明文がはっきりしています。「インストール済みバイナリの証拠から、Muse Code の製品・ランタイムの問題を診断する」。

そして使ってはいけない場面が明記されています。

• 通常のリポジトリのコード不具合
• ベンチマーク課題
• 実装のデバッグ
• ビルドやテストのハング
• 第三者プロジェクトの問題

つまり「Muse Code 自体がおかしい」ときだけのスキルです。ユーザーが明示的に doctor を呼んだとき、Muse Code 自体のデバッグを頼まれたとき、あるいは「さっきのセッションで何が起きたか」を尋ねられたときに限定されています。

read-session スキル

関連して read-session があります。Muse Code 自身のセッションログを見つけて読むスキルです。「失われた・上書きされた作業を復旧してほしい」「以前のセッションの続きをやりたい」といった要求に対応します。

説明文には、セッションの保管場所についての注意も含まれています。Muse のセッションは Muse 自身の保管場所にあり、~/.claude・~/.codex・~/.grok を探ってはならないと明記されています。他社エージェントのセッションを扱う場合は、代わりに import スキルを使う流れです。

まとめ