いつ実行するか（判定ルール）
状況に応じて適切に実行し、反射的に実行しないでください。状況に応じたレベルを選択します：
| 状況 | 実行内容 |
|---|---|
| ドキュメント、メモ、コメント、計画、仕様のみの変更 | 何もしない。 不要だったと伝える。 |
| 作業中：編集の合間、修正ラウンド、「型を壊したかも？」 | クイック： node .claude/skills/verify-saas/driver.mjs --quick（または、変更された型が1つだけの場合は型チェックコマンドのみ） |
| 各タスクまたは論理的なまとまりの終了時、コミット前 | 完全モード、1回 |
git push、デプロイ、メインブランチへのマージ前 | 完全モード、必須。 最後の完全モードの実行が対象のコミットを正確にカバーしている場合は繰り返さない。 |
新しいマイグレーション、package.jsonの変更、ビルド設定、アクセス/認証ルールの変更 | 完全モード（構造変更のリスクがあるため） |
git pull 後、または他の人の作業をマージした後 | 完全モード（ベースラインを再設定） |
絶対に行わないこと：
- 変更がないのに続けて2回実行すること；
- 最初の実行結果を読む前に2回目の実行を開始すること；
- 同じディレクトリで他のビルドやテストと並行して実行すること；
- ライブ調整の途中で完全モードを実行すること（コミットの指示を待つこと）。
常に行うこと：
- テストが本番環境ではなくテスト用のデータベース/環境を指していることを確認する（READMEの注意を参照）；
- 実行する前に自分の diff を読み直す：不要なインポートやプロパティ名の間違いは、実行して検出するのではなく、読んで見つける；
- 終了コードだけでなく、レポート全体を読む。
実行方法
プロジェクトルートで：
node .claude/skills/verify-saas/driver.mjs # 完全モード
node .claude/skills/verify-saas/driver.mjs --quick # クイックモード、ベースラインは更新しない
node .claude/skills/verify-saas/driver.mjs --baseline # 現在の状態を「正常」として再取得
プロジェクト固有の設定（コマンド、ディレクトリ、警告キーワード、有効/無効のステップ）はすべてプロジェクトルートの verify-saas.config.json に記述します。このファイルがない場合、Next.js + TypeScript + npm のデフォルト設定が使用されます。
終了コード：0 = 悪化なし；1 = 何かが悪化した、またはすでに壊れていたものがある（型、ビルド、テスト）。
初回使用：プロジェクトへの適応（このドキュメントを読んでいるエージェント向け）
ユーザーがスキルをインストールしたばかりで、自分のSaaSに適応するよう依頼した場合、以下の順序で実行してください：
- プロジェクトを読む（
package.jsonまたは同等のファイル、マイグレーションディレクトリ、テストの実行方法）そしてverify-saas.config.jsonを調整する：型、リンター、ビルド、テストのコマンド、structure.migrationsDir、alertKeywords。プロジェクトにない機能は"enabled": falseで無効にする。 - ユーザーに、ビジネス上壊してはいけないことを尋ねる（重複した予約がないスケジュール、在庫がマイナスにならない、残高の一致、企業Aが企業Bのデータを見られない、支払いが二重に受領されて1回だけ計上されないなど）。ルールを自分で考えず、ユーザーと確認し、
docs/exemplos-por-nicho.mdをモデルとしてテストを書く。 - テスト環境を確認する。 本番環境に対してテストを実行してはならない。テスト用のデータベースや環境がない場合は、停止してユーザーに警告する。
- その後
node .claude/skills/verify-saas/driver.mjs --baselineを実行し、レポートを表示し、すでに壊れているもの（負債）と合格したものを指摘する。 - 調整内容と、書かれたテストをユーザーが確認する必要があることを伝える。
レポートの読み方
順番に：
- 型：合格/不合格、ベースラインとのエラー数の比較。
- リンター：単なる件数ではなく、指紋（ファイル:行:列:ルール）で比較。「以前5エラー、以後5エラー」でも、5つの異なるエラーが隠れている可能性がある。以前からの負債は決してあなたの責任ではない；新しいものだけがカウントされる。
- ビルド：合格/不合格、ルート一覧（設定されている場合）。
- テスト：ベースラインとの比較で合格/不合格。
- 構造：新しい依存関係、削除された依存関係、バージョン変更；新しいマイグレーション、警告キーワード（セキュリティ/権限）を含む場合は警告付きで表示。
記号：✗ 退行（修正が必要）、✓ 改善、= 変更なし、ℹ 情報、⚠ 意図的なものか確認が必要。
出力後、完全モードは現在の状態でベースラインを上書きします。そのため、再実行する前に退行を修正してください。そうしないと、2回目の実行ではそのエラーが「以前からの負債」として扱われます。
ベストプラクティス
- ベースライン（
verify-saas.baseline.json）はプロジェクトにコミットすること。これにより、セッション間やマシン間で「前回からの比較」が機能します。 - プロジェクトで初めて使用する場合：正常な状態で
--baselineを実行します。 - マイグレーションはファイル名のみで比較されます。スキルはSQLを適用したり検証したりしません；新しいマイグレーションが現れたこと、およびセキュリティに関連する変更があるかどうかを通知するだけです。
- スキルは依存関係のインストールを行いません（
npm installは検証だけで実行すべきアクションよりも大きな操作です）。 - レポートに「新しい」問題が表示され、自分が原因でない場合、前回の実行以降にリポジトリが変更されたかどうかを確認してください（
git log -3 --oneline）。 - 本当の保護は自分で書くテストから得られます（
docs/exemplos-por-nicho.mdを参照）。スキルはそれらが実行されること、および何かが変更されたときに通知することを保証するだけです。