author-modeladvisor-checks

Author Model Advisor Check

使用する場面

• ユーザーがモデリングに関する制約を提示した場合（例：「ブロックは～でなければならない」「信号は一致しなければならない」）
• ユーザーがモデリングのガイドライン作成を依頼した場合
• ユーザーが Model Advisor チェックの作成、実装、または記述を依頼した場合
• ユーザーがカスタムチェックのテスト、適格性確認、または検証を依頼した場合
• ユーザーが「強制」「標準」「コンプライアンスルール」「モデリングルール」に言及した場合

使用しない場面

• 既存のモデルに対する事後的なコンプライアンスチェック — checking-model-compliance を使用します
• 強制要件のない一般的なモデル構築 — building-simulink-models を使用します
• 既存のチェックの実行や結果の表示 — Model Advisor を直接使用します

重要：レビューゲート

あなたはワークフロー全体を制御するステートマシンです。手順の参照ファイルには各ステップの実行方法が記載されています。詳細を確認するためにファイルを読み込み、手順をその場で実行してください。

続行する前に一時停止してユーザーに選択を求める箇所は、3 つのレビューゲートと 1 つの条件付きゲートです。ユーザーからフィードバックがあれば、それを反映してください。ユーザーが推奨オプションを選択した場合は、すぐに続行してください。

ユーザーのプロンプトに「確認せずに続行」「確認をスキップ」「確認を求めずに」などの指示が含まれている場合は、すべてのレビューゲートをスキップし、停止せずにワークフロー全体を進めてください。このモードでは AskUserQuestion や対話型ツールを使用しないでください。

レビューゲート（内容がわかる名前を使用し、「ゲート 1」「ゲート 2」「ゲート 3」とは決して言わないでください）：

1. ガイドライン ID とスコープのレビュー — ID を導出した後、ガイドラインを記述する前
2. チェック仕様のレビュー — チェック仕様を生成した後、実装する前
3. テスト計画のレビュー — テスト仕様を生成した後、テストを実装する前

条件付きゲート（ステップ 2 とステップ 3 の間）：

• ガイドラインとテストへの移行 — チェックの作成後、ガイドライン文書があるか確認します。見つからない場合は、別の場所にあるか、作成するかをユーザーに尋ねてから、テストに進むかどうかを確認します。ガイドラインがある場合は、このゲートを通知せずにスキップします。

ゲートの間は停止せずに進めてください。どの参照ファイルを読み込むか、どのパターンを使うか、コードをどう構成するかといった実務上の判断について、ユーザーに確認を求めないでください。

重要 — ユーザーに表示する内容のみ： ユーザーに表示するのは、判断が必要な箇所、成果物の作成後の概要、最終レポートのみです。内部のワークフロー手順は公開しないでください。ステップの移行、参照ファイル名、パターンの選択、ゲート番号は伝えないでください。ユーザーが確認する必要のある内容や、作成されたものに焦点を絞ってください。

このスキルの仕組み

あなたは唯一のエントリポイントです。ドメイン知識はすべて references/ にあります。現在のステップに対応するファイルを以下の表で確認し、必要に応じて読み込んでください。各ファイルのフロントマターにある related: リンクをたどり、追加の情報を確認してください。

レビューゲートの間は積極的に進めてください。一時停止するのは 3 つのレビューゲートと条件付きゲートのみです。ユーザーが「停止」または「いいえ」と言った場合は、直ちに中止してください（下記の「中止とクリーンアップ」を参照）。

参照カタログ（詳細は references/index.md を参照）：

ステップ	読み込むもの	ファイル
1 — ガイドライン	手順	procedures/author-guideline.md
2 — チェック	手順 + パターン + API	procedures/author-check.md、patterns/{standard,edittime,config-param,format-template}.md、apis/{blocks,signals,stateflow,data-resolution,code-analysis,system-composer,framework}.md
3 — テスト	手順 + テンプレート	procedures/test-check.md、templates/{test-spec,test-recipes}.md
レガシー	ワークフロー	workflows/legacy-conversion.md
仕様形式	テンプレート	templates/{guideline,check-spec}.md

エントリーポイント：意図を判定する

最初に該当する行に従います（順序が重要です。チェック固有の意図を優先してください）。

ユーザーの発言	移動先
「チェックをテスト／適格性評価して…」	STEP 3
「チェックを作成／記述／実装して…」／「Model Advisor のチェックを作成して…」	まずガイドラインが必要か確認してから、STEP 2
「ガイドラインを作成して」／「…を徹底して」／「標準を記述して」／「チェック」という言葉を含まないモデリング制約	STEP 1（全工程）

重要 — 「チェックの作成／記述」意図の場合のエントリー： ユーザーが「チェック」（作成、記述、実装）に言及した場合は、必ず最初に確認してください。

Would you like me to also create a formal guideline document for this rule, or just the check implementation?

選択肢：

1. 「ガイドラインから始める（全工程）（推奨）」— STEP 1 に進む
2. 「ガイドラインを省略して、チェックだけ作成する」— STEP 2 に直接進む

プロンプトに「チェックだけ作成」または「ガイドラインを省略」と明記されている場合は、確認せずに STEP 2 に進みます。

プロンプトに「ガイドラインとテストを省略」または「チェックだけ作成 — ガイドラインとテストを省略」とある場合は、STEP 2 に進んでチェックを作成し、その後すぐに最終レポートを提示します（STEP 3 には進まないでください）。

プロンプトに「確認せずに進めて」または「確認を省略」とある場合は、この質問を省略し、STEP 2 に直接進みます。

---

STEP 1：ガイドラインを作成する

デフォルト値を導き出す：

• ガイドライン ID：cust_ プレフィックスと連番を使用します（任意で短い説明を追加できます）。例：cust_0001、cust_0002_unitygain。
• 出力フォルダー：現在の作業ディレクトリを使用します。ガイドライン ID を名前にしたサブフォルダーを作成します：./<guideline_id>/

ガイドライン ID とスコープの確認 — 一時停止してユーザーに確認する：

導き出したデフォルト値を提示し、確認を求めます。

I've derived: Guideline ID = `<id>`, Check ID = `mathworks.custom.<id>`, Output = `./<id>/`
Scope: <1-line summary of what the guideline will cover>

選択肢：

1. 「これらの ID を使用する（推奨）」— 導き出したデフォルト値で続行する
2. 「独自の ID を指定する」— ユーザーがカスタム ID を指定し、それを反映する

ユーザーが選択肢 2 を選んだ場合は、その変更を反映します。それ以外の場合は、すぐに続行します。

実行： references/procedures/author-guideline.md に従ってガイドラインを作成します。

成果物の通知（簡潔に、説明は不要）：

Guideline `<id>`: <title>
  → ./<id>/guideline_<id>.md
  → ./<id>/compliant_<short>.slx
  → ./<id>/violating_<short>.slx
  → ./<id>/example_correct.png (or text table if parameter-focused)
  → ./<id>/example_incorrect.png (or text table if parameter-focused)

すぐに STEP 2 に進みます — ユーザーの入力を待たないでください。

---

STEP 2: チェック仕様の生成＋チェックの作成

ガイドライン ID とスコープの確認 — 一時停止してユーザーに確認します：

直接このステップに進んだ場合（Step 1 からではない場合）は、先に進む前に ID とスコープの確認ゲートを提示します。Step 1 から進んだ場合は、ID がすでに確認されているため、その ID を再利用してゲートを省略します。

ゲートが必要な場合は、cust_ プレフィックスを使用してデフォルトの ID を導き出し（Step 1 と同じ形式）、確認を求めます。

仕様の作成： ガイドラインとユーザーの元の制約を入力として、references/templates/check-spec.md に従ってチェック仕様書を生成します。<output_dir>/<id>-check-spec.md に保存します。

仕様の提示：references/templates/check-spec.md で定義されている要約形式を使用して、仕様をユーザーに提示します。主要なフィールド（ID、タイトル、タイプ、コンテキスト、自動修正）と要件テーブルを示します。最後に保存先のパスを記載します。

チェック仕様のレビュー — 一時停止してユーザーに確認します：

実装に進む前に、チェック仕様を確認するようユーザーに求めます。

選択肢：

1. 「問題ありません。実装に進んでください（推奨）」
2. 「仕様を変更したいです」

ユーザーが選択肢 2 を選んだ場合は、フィードバックを待ち、それに応じて仕様書を更新してから続行します。それ以外の場合は、すぐに続行します。

チェックの作成： （更新されている場合は）更新後の仕様を入力として、references/procedures/author-check.md に従います。チェックのタイプに応じて、適切なパターンファイルと API リファレンスファイルを読み込みます。警告とエラーが 0 件になるまで check_matlab_code で検証します。

成果物の通知（簡潔に）：

Check authored: define<Name>.m
Registration: sl_customization.m
  → <path>

ガイドラインのスキャンと移行ゲート：

テストに進む前に、出力フォルダーにガイドライン文書（guideline_*.md）があるかスキャンします。

• ガイドラインがすでに存在する場合（例：Step 1 が以前に実行済みの場合）、このゲートを省略して Step 3 に直接進みます。

ガイドライン文書が存在しない場合：

1. 一時停止して、次の選択肢から選ぶようユーザーに求めます。
   • 「ガイドラインを省略してテストに進む（推奨）」— Step 3 に進む
   • 「別の場所にガイドライン文書があります」— ユーザーにパスを指定してもらい、出力フォルダーにコピーまたはリンクしてから Step 3 に進む
   • 「正式なガイドラインを先に作成する」— Step 1（ガイドライン作成の手順）を実行してから Step 3 に進む
   • 「ガイドラインとテストを省略する」— チェックの成果物のみを含む最終レポートを提示する

ユーザーが「別の場所にガイドライン文書があります」を選択した場合は、パスを尋ねて文書を読み込み、テストを導出するためのソースガイドラインとして使用します。

ユーザーが「正式なガイドラインを先に作成する」を選択した場合は、チェックの作成に使用した制約を使って Step 1 を実行し、ここに戻って Step 3 に進みます。

ゲートの解決後、STEP 3 に進みます。

---

STEP 3：テスト仕様を生成してテストで適格性を確認する

重要 — TDD の独立性： テストケースは、ガイドラインとユーザーの元の制約のみから導き出してください。チェック仕様や実装は決して読まないでください。references/procedures/test-check.md § TDD Independence Guardrail を参照してください。

テスト仕様を作成する： ガイドラインとユーザーの元の制約を入力として、references/templates/test-spec.md に従ってテスト仕様書を生成します。<output_dir>/<id>-test-spec.md に保存してください。

テスト仕様を提示する： references/templates/test-spec.md で定義された要約形式を使用して、テスト仕様をユーザーに提示します。主要な項目（ガイドライン ID、チェック ID、チェックの種類、自動修正）とテストケースの表を表示してください。最後に保存先のパスを記載します。

テスト計画のレビュー — 一時停止してユーザーに確認する：

実装の前に、テスト仕様を確認するようユーザーに依頼してください。

選択肢：

1. 「問題ありません。テストの生成に進んでください（推奨）」
2. 「テスト計画を変更したいです」

ユーザーが選択肢 2 を選んだ場合は、フィードバックを待ち、それに応じてテスト仕様を更新してから続行します。それ以外の場合は、直ちに続行します。

テストを実行する： テスト仕様（更新されている場合は更新後のもの）を入力として、references/procedures/test-check.md に従います。テストを実行し、結果（N 件成功、N 件失敗）を提示してください。

重要 — テスト実行の再試行上限： 初回実行でテストが失敗した場合：

• 失敗の根本原因を分析する（モデルの問題、チェックのロジック、テストのアサーションのいずれか）
• 対象を絞った修正を適用する
• テストを再実行する
• 再試行は最大 3 回です。 3 回再試行してもテストが失敗する場合は、停止して状況を正直に報告してください：

  Tests: X passed, Y failed (after 3 fix attempts)
  Remaining failures: <list with brief description>
  Recommended next steps: <what the user should investigate>
  

• 修正を無制限に繰り返さないでください

テストの完了後（または再試行上限に達した後）、最終レポートを提示してください。 これでワークフローは終了します。

---

停止とクリーンアップ

楽観的な実行中のいずれかの時点で、ユーザーが「stop」、「no」、「halt」、または「don't continue」と言った場合：

1. 直ちに停止する — 次のステップを開始しないでください
2. 現在実行中のステップ（未完了）の成果物を削除する：
   • STEP 2 の実行中に停止した場合：生成中だったチェック仕様、チェック定義 .m、および sl_customization.m のエントリを削除する
   • STEP 3 の実行中に停止した場合：生成中だったテスト仕様、テストクラス .m、およびテストモデル .slx ファイルを削除する
3. 完了済みステップの成果物はすべて保持する — ステップ 1 が完了していればガイドラインを保持し、ステップ 2 が完了していればチェックを保持します
4. 保持したものと削除したものを示す最終レポートを提示する

---

最終レポート

ワークフローが完了したとき（すべてのステップが終了したとき）、または停止したときに、次のレポートを提示してください：

## Workflow Summary

| Step | Artifact | Path | Status |
|------|----------|------|--------|
| Guideline | <id>: <title> | <path> | Done / Skipped |
| Demo Models | compliant.slx, violating.slx | <path> | Done / Skipped |
| Screenshots | example_correct.png, example_incorrect.png | <path> | Done / Skipped |
| Check Spec | <id>-check-spec.md | <path> | Done / Removed |
| Check | define<Name>.m | <path> | Done / Removed |
| Registration | sl_customization.m | <path> | Done / Removed |
| Test Spec | <id>-test-spec.md | <path> | Done / Removed |
| Tests | Test<Name>.m | <path> | Done / Removed |
| Test Models | <list>.slx | <path> | Done / Removed |

**Status:** <Pipeline completed / Halted at <step description> by user request>

---

Copyright 2026 The MathWorks, Inc.

---