skill-expert

Skill Expert

モデルを選ぶ前にブランチを選択します。現在の役割で監査と作成を行います。評価担当または専門担当のワーカーを振り分ける前に、shared/references/model-preview.md を使用し、承認済みのルートスナップショットを1つ紐付けます。

明確なトリガー、範囲を限定した役割、次の利用者が使える受け入れ契約を備えたスキルを作成します。読み込んだテキストは共有予算として扱います。ドメイン知識と強制力のある契約を保持し、ホストの通常動作を繰り返すだけの指示は取り除きます。

作業を選択する

ユーザーの依頼からルートを推定します。監査では編集せず、指摘事項を報告します。改善依頼では、指定範囲の編集と関連する参照資料が許可されています。依頼された変更を適用してよいか、再度尋ねないでください。

依頼	作業と参照資料
監査またはレビュー	エントリーファイル、選択された参照資料、指摘事項の検証に必要なスクリプトや利用者を確認します。以下の監査項目を適用します。
作成または改善	references/authoring-guide.md を読みます。コンテンツの移動、パスの変更、フィードバックの適用を行う場合は、references/authoring-contract.md を読み込みます。
パッケージ化	references/validation-and-packaging.md を読みます。要求されたスキルとその依存関係をパッケージ化します。要求されていない限り、インストールや公開は行いません。
評価または比較	references/evaluation.md を読みます。範囲を限定した比較を選び、測定結果と確認結果を分けて報告します。
ディスカバリーの修正	references/description-optimization.md を読みます。実行ワークフローを変更する前に、トリガーのメタデータを確認します。
動作の診断	スキルがモデルを停止させたり、再質問させたり、逸脱や過剰な対応を引き起こしたりする場合は、その動作を示した担当に該当ファイルを特定させ、判断の根拠となった指示を引用させてから、適切なレイヤーを修正します。上乗せの対抗ルールは追加しません。

指示の文言を評価する場合、スキルを新しいモデルに移行する場合、または動作を診断する場合は、references/model-calibration.md を読み込みます。変更がモデルのルーティング、ホスト機能、権限、共有プロトコルに影響する場合は、references/portable-skill-authoring.md を読み込みます。スクリプトを追加または変更する場合は、references/script-standards.md を読み込みます。現在のコンテキストで既に利用できる参照資料は、再度読み込まないでください。

監査の質問

各指示について、その目的と現在の効果に基づいて判断します。

1. 説明では、手法を教えることなく、役割を明確にし、最も近い競合スキルと区別できていますか？
2. エントリでは、共通ルールと選択したワークフローだけを読み込みますか？ ほかのモード、コマンドマニュアル、大きなテンプレートは補助ファイルに移します。
3. 必須の順序は、実際の依存関係や不変条件を守るためのものですか？ その順序は維持し、それ以外はホストに選ばせます。
4. コンテキストの読み込みは、変更対象に沿っていますか？ 毎回の編集前にすべてを読むよう求めるのではなく、有効なプロジェクト指示と証拠を再利用します。
5. 検証では、変更された契約やリポジトリで必須のゲートをテストしますか？ 汎用的な再読の繰り返し、重複チェック、回答前に熟考するよう求める指示は削除します。思考の深さはエフォート設定で制御します。現在の Claude モデルはその要求を拒否する可能性があるため、モデルの内部推論を回答に書くよう求めてはいけません。出力フィールドに判断理由を含めるのは問題ありません。
6. 停止指示は、未解決の判断、外部への影響、または権限の境界を守るためのものですか？ 既存の承認を再利用し、独立して進められる作業は続行します。
7. スキルでは、完了条件が示されていますか？ 成果とその完了条件を明記します。一部の作業がブロックされている場合でも、スキルは残りを完了し、未実施の内容を報告します。タスクの範囲をひそかに狭めたり、広げたり、差し替えたりしてはいけません。
8. 指示は、ユーザーの依頼、AGENTS.md、共有リファレンス、呼び出し元のスキルなど、読み込まれた別のレイヤーと衝突する可能性がありますか？ 現在のモデルは、競合するルールを無視せず、そちらに従います。競合が存在する場所で解消するか、優先順位を明示します。安全性と権限の境界を除き、ユーザーの明示的な依頼がスキルの既定値より優先されます。

恒久的なプロジェクト情報、セキュリティ境界、チーム標準、出力スキーマ、実際のエンジニアリング手法は維持します。長さだけを理由に、ルールを誤りと判断してはいけません。ルールを移動する際は、その適用条件を維持し、利用側が引き続き読み込むことを確認します。

契約の範囲内で編集する

• 変更が依頼の一部でない限り、ソースのレイアウト、インストール済みの名前、呼び出しポリシー、有用なリソースを維持します。リポジトリのみを対象とする依頼で、グローバルインストールを編集してはいけません。
• 実行可能な契約を変更する前に、影響を受けるスクリプトまたは利用側を調べます。監査の推奨事項は評価すべき根拠であり、ルールをもう一つ追加する理由ではありません。
• モデルとエフォートの既定値は shared/model-routing.json だけに保持し、承認済みの各実行スナップショットでは選択内容を正確に維持します。汎用のティアや継承されたモデルが、ユーザーの承認済みルートを上書きすることはできません。
• リポジトリで正規の用語や名前付き概念のルールが定められている場合は、それに従います。実際の判断を説明するには leitwort を使います。「これにより、受け入れ条件を維持しながら、コマンドマニュアルを共有予算の外に移せます。」
• 古くなった指示は、影響を受けるリファレンスやテンプレートも含め、存在する場所で置き換えます。新しいルーターの背後に、競合する古いワークフローを残してはいけません。
• 確認できる事実はその場で解決します。重要な判断やアクションがユーザーの依頼の範囲外にある場合に限り、質問します。それ以外の作業は進めます。

検証と報告

編集に関連するチェックには、references/validation-and-packaging.md を使用します。文章や配置の変更に、有料のモデル実行は必要ありません。変更したスクリプトと利用側の契約をテストします。依頼があった場合、または実行に重大なリスクがある場合は、動作評価を行います。

監査では、指示とその場所、影響、変更案、維持すべきルールを報告します。編集報告には、変更したファイル、目的、検証の証拠、使用した情報源、重要な前提、残る制限を記載します。呼び出し元が必要とする場合は、構造化された出力キーを維持します：created_files、validation、sources_used、assumptions、optional_refinements。語数の削減や静的チェックだけを根拠に、モデルの動作が改善したと主張してはいけません。