wellwelwel/blue-spec

Blue Spec コマンドのシミュレーション

このスキルは、コマンドのシミュレーションが一見簡単に思えて誤った方法で行われ、ユーザーの時間と信頼を無駄にするのを防ぐために存在します。過去の厳しいセッションを経て、4つの譲れないルールと1つのメソッドが確立されました。これらを正確に守ってください。

ユーザーが /bluespec.* コマンド（charter、detect、plan、harden、verify）を「シミュレーションして」「デモして」「実際に見せて」「実行して」「動作を確認したい」と依頼した場合、またはコマンドの振る舞いを事前にプレビューしたい場合に、このスキルを使用してください。

開始前の準備（必須）

以下の2つが決まるまでは、シミュレーションを開始したり、シナリオを構築したり、フィクスチャをコピーしたりしないでください。この順序で進めます。

1. ユーザーはシミュレーションする Blue Spec コマンドを指定しなければなりません。 これは必須です。推測したり、こちらで選択したりしないでください。ユーザーがコマンド（charter、detect、plan、harden、verify）を指定していない場合は、何をする前にどれかを尋ねてください。複数のコマンドを指定した場合は、実行する順序を確認してください。
2. 次にフィクスチャを列挙して提案し、ユーザーに選択させます。 コマンドが決まったら、利用可能なフィクスチャ（.claude/skills/simulate/fixtures/ 内）を番号付きリストで表示し、それぞれのシナリオの1行説明を添えて、ユーザーに番号で選んでもらいます。黙ってデフォルトのフィクスチャを使用しないでください。フィクスチャが1つしかない場合でも、それを提示し、使用前に確認を取ってください。どのフィクスチャもコマンドに合わない場合は、その旨を伝え、新しいフィクスチャの追加を提案してください（フィクスチャセクション参照）。

コマンドが指定され、フィクスチャが選択された後にのみ、以下のルールとメソッドに進みます。

このスキルが存在する理由（最初に読んでください）

Blue Spec コマンドは スタンドアロンのプログラムではありません。これは、AIエージェントがセキュリティワークのフェーズを実行する方法を指示する命令ファイル（spec/commands/bluespec.<phase>.md、エージェントが読むスキルとしてスキャフォールドされています）です。「コマンドを実行する」とは、エージェントがその指示に従うことを意味します。エージェントから独立した決定論的な結果を出力するバイナリは存在しません。したがって、「シミュレーション」とは、エージェントがコマンドのステップを実際に実行し、実際のシナリオに対して作業内容を表示しながら進めることです。

避けるべき失敗パターン：コマンドが出力すると想像した内容をナレーションし、ターミナルのようにフォーマットして、あたかも実行したかのように提示すること。それは劇です。ユーザーは創作された出力と実際の出力を見分けることができず、正当に「茶番だ」と言うでしょう。以下のすべての内容は、シミュレーションをユーザーが検証可能で現実のものにするために設計されており、パフォーマンスではありません。

4つの厳格なルール

ルール 1: ./temp 以下でシナリオを実行する

シミュレーションが触れるすべてのもの（フィクスチャ、フェーズが生成する .bluespec/memory/ のアーティファクト、あらゆる入力）を、リポジトリルートの ./temp 内に構築し、システムの /tmp では決して行わないでください。

• /tmp はユーザーから見えません。ユーザーはそれらのファイルをエディタで開くことができないため、そこで行うすべてのことは「信じてください」になります。./temp はユーザーのワークスペース内にあり、開いて検査できます。
• ./temp は git で無視されるため、シミュレーションがコミットを汚染することはありません。
• ユーザーの作業が終わったら ./temp をクリーンアップするか、検査のために残しておくかを尋ねてから実行します。

フィクスチャ：すべてのシミュレーションをフィクスチャから開始する

このスキルと一緒に、ニュートラルなサンプルプロジェクトが .claude/skills/simulate/fixtures/<name>/ の各ディレクトリに同梱されています。コマンドが必要とするシナリオに合うフィクスチャを選択するか、新しいものを追加します（後述参照）。各フィクスチャは小さな実際のプロジェクトであり、堅牢なコードと脆弱なコードの両方をニュートラルなペアとして意図的に含んでおり、コマンドはラベルを読むのではなくコードを分析する必要があります。

利用可能なフィクスチャ：

• image-upload-service: 画像アップロードを受け付け、それを返す小さな ESM HTTP サービス。
• template-toolkit: テンプレートレンダリングとテキスト解析のための公開可能な ESM npm パッケージ（ライブラリと tmpl CLI）。

常に、シミュレーションはフィクスチャをそのまま ./temp にコピーすることから始めてください。 ./temp がすでに存在し空でない場合は、最初にクリアして、各実行をクリーンな状態から始めます（<name> は選択したフィクスチャに置き換えてください）：

rm -rf ./temp && mkdir -p ./temp
cp -R .claude/skills/simulate/fixtures/<name>/. ./temp/

その後、ルール4に従って上流のフェーズを実際に実行することで、./temp 内にチェーンを構築します。これにより、コマンドが読み取る .bluespec/memory/*.md アーティファクトは、手書きではなく、自身のフェーズによって生成されます。コマンドのステップを ./temp に対して実行し、その仕様書に忠実に従い（ルール3）、各ステップの出力をルール2に従って表示します。

フィクスチャを追加するには、.claude/skills/simulate/fixtures/<new-name>/ を作成し、小さな実際のプロジェクトとして自身の package.json を持たせ、堅牢なコードと脆弱なコードをニュートラルなペアとして保持し、明らかなコメントや名前を追加せず、上記リストに追加します。現在のフィクスチャがカバーしていない素材（異なる言語やスタック、機密情報の取り扱い、認証、データベースなど）をコマンドが必要とする場合に追加してください。

ルール 2: プロンプトと応答をチャットメッセージ内のフェンス付きコードブロックで公開する

これは、習得に最も時間がかかったルールです。ツール（Bash、Read）を実行すると、ユーザーのインターフェースにはそのツールの IN と OUT の切り詰められたプレビューが表示されます。どれだけ表示されるかは制御できず、通常は途中で切れます。主張を裏付ける証拠がツール呼び出しの出力内にのみ存在する場合、ユーザーはそれを見ることができず、それを説明する文章は創作であると受け取られます。

したがって：

• ツールを実行した後、関連する生の出力をフェンス付きコードブロック（トリプルバッククォート）にコピーして、通常のチャットメッセージ内に貼り付けてください。フェンス付きブロックはどのインターフェースでも完全かつ同一にレンダリングされます。これがユーザーが意図する「黄色い文字」、つまりマークダウンコードブロックです。
• コマンドのプロンプトとインタラクション（/bluespec.<phase> の実行中に表示されるもの：ステップバイステップ、スコープの決定、判定結果など）もフェンス付きコードブロックに入れ、トランスクリプトのようにスタイル付けします。
• 「上記の出力はXを示しています」とツール呼び出しを指して書かないでください。貼り付けたフェンス付きブロックを指し示してください。ユーザーはそれを完全に読むことができます。
• トランスクリプト内の数字や行が実際の実行から得られたものである場合、貼り付けた生の出力と一致しなければなりません。貼り付けた生の出力によって裏付けられていないトランスクリプト行を書く場合、それは創作です。やめてください。

信頼できるパターン：コマンドを実行し、生の出力を ./temp 下のファイルにリダイレクトし（例：./temp/run.log）、その後 Read でそのファイルを読み（Read結果は完全に表示されます）、その内容をフェンス付きブロックに貼り付けます。ユーザーは ./temp/run.log を開いて検証することもできます。

最後にまとめて表示するのではなく、進みながら表示してください。 トリガーはステップごとです：ステップがユーザーが見るべきものを生成した瞬間（読み取った入力、そのトランスクリプト、書き込んだアーティファクト）、それを同じメッセージ内のフェンス付きブロックに貼り付け、次のステップに進む前に実行します。次のフェーズや修正を開始しようとしていて、前のステップの出力がまだ画面に表示されていない場合は、停止して最初に貼り付けてください。ユーザーがコマンドの出力を表示するよう促さなければならない場合、そのルールはすでに破られています。

ルール 3: あなた自身がコマンドである — 仕様書に一字一句従う

「コマンドを実行する」とは、あなたが spec/commands/bluespec.<phase>.md をステップバイステップで実行することであり、自分のやり方でフェーズを実行してそれをコマンドと呼ぶことではありません。

• 最初にその仕様書を開き、それを唯一の真実の情報源として扱ってください。 そのステップを順番に実行してください。記憶やこのスキルの要約からフェーズを実行しないでください。
• 仕様書でゲートされている確認停止をすべて実際に実行してください。 harden はコードを編集する前に確認が必要です。フル detect スキャンはトークン消費が多いため確認が必要です。仕様書が提示するように指示している内容をトランスクリプトブロックで提示し、待機してください。確認なしにコードを編集したり、ゲートされたステップを実行したりしないでください。
• スコープ、判定、修正、優先順位、発見事項を、仕様書のステップが決定する方法で、実際のシナリオに基づいて決定してください。出力の行を正当化する仕様書のステップを指し示せない場合、あなたは自分自身として行動しています。停止して仕様書に従ってください。

ルール 4: 各フェーズへの入力は、あなた自身ではなく、前のフェーズの実行から得られなければならない

チェーンは charter → detect → plan → harden → verify であり、各フェーズは前のフェーズが書き込んだものを読み取ります。期待する答えが書かれた下流のアーティファクト（verify が確認または捕捉すべき内容を正確に記録した harden.md）を手で作成することは失敗です。下流のフェーズはあなたの予測に対してテストされ、現実に対してではないため、あなたが見逃したものを見逃すことになります。

• すべての上流アーティファクトは、そのフェーズを実行し、自身の仕様書に従い、ルール2に従って表示して生成してください。verify をデモするには、detect（コードを読み取る）を実行し、次に plan（detect.md を読み取る）を実行し、次に harden（plan.md を読み取り、コードを編集する）を実行します。ユーザーがチェーンの中間から始めた場合でも、不足しているアーティファクトをこの方法で順番に構築してください。
• アーティファクトに、実行が実際に生成したものを言わせてください。ギャップも含めて：Partial、Blocked、予期しなかった発見事項。不自然にきれいなアーティファクトは、このルールが破られた証拠です。
• 意図的に異なるシナリオを作ることは問題ありません（harden がすべてを適用し、その後コードが元に戻され、verify がその乖離を捕捉しなければならないなど）。ただし、乖離は可視的に導入してください（表示されたツール呼び出しで元に戻し、実際のアーティファクトを保持し）、実行が生成しなかったレコードを手書きで作成しないでください。

メソッド：ステップバイステップ

各フェーズは前のフェーズを読み取り、1つのアーティファクトを書き込みます。このチェーンを理解し、決して破らないでください：

フェーズ	読み取るもの	書き込むもの
charter	プロジェクトコンテキスト	.bluespec/memory/charter.md
detect	コード	.bluespec/memory/detect.md
plan	detect.md のみ、コードは決して読まない	.bluespec/memory/plan.md
harden	plan.md のみとチャーター、ユーザーのコードを編集する	.bluespec/memory/harden.md
verify	harden.md とコード、記録と現実を突き合わせ、何も変更しない	.bluespec/memory/verify.md

次に、シミュレーションしているコマンドに対して：

1. フィクスチャをそのまま ./temp にコピーします（ルール1）。
2. 各上流フェーズを順番に ./temp に対して実行してチェーンを構築します（ルール4）。
3. ターゲットのフェーズを spec/commands/bluespec.<phase>.md に従って一字一句実行します（ルール3）。
4. すべての入力、トランスクリプト、アーティファクトを進みながらフェンス付きブロックに表示します（ルール2）。各出力アーティファクトを実際のファイルとして書き込み、その後 Read して表示します。

何かを提示する前の正直さチェック

• これは実際に実行されたのか、それとも私が起こると思うことをタイピングしているだけか？
• すべてのトランスクリプト行は、貼り付けた生の出力、またはユーザーが開ける ./temp ファイルによって裏付けられているか？それとも切り詰められたツール呼び出しに基づいていないか？（ルール2）
• これまでのすべてのステップの出力をすでに貼り付けたので、ユーザーが尋ねる必要はないか？（ルール2）
• 各フェーズの仕様書に従い、確認停止も含めて、自分自身として行動するのではなく、従ったか？（ルール3）
• 各上流アーティファクトは、そのフェーズを実行して生成されたものであり、私が望む結果を手書きしたものではないか？（ルール4）
• シナリオは ./temp 下にあり、/tmp に隠れていないか？（ルール1）

いずれかの答えが「いいえ」の場合、送信する前に修正してください。ユーザーは、磨き上げられた創作よりも、控えめでも実際の出力を見たいと思います。