strengthen

spec ファイルをスキャンして guidance() ルールを見つけ、実際のリンタールールに基づいた enforce() への置き換えを提案します。

原則：手軽にできるものは自動で適用し、コストがかかるものは提案する

判断基準は厳格さではなくコストです。リンタールールがすでに存在し、有効になっている場合の guidance() → enforce() の置き換えは、手間がかからず、元に戻せて、誤検出のリスクもないため、適用します（以下の Tier 1）。コストがかかる変更（リンター設定の編集、プラグインのインストール、クリーンな CI で失敗する可能性のある変更）は、ユーザーが判断します。トレードオフを明示して提案し、選択を委ねてください（Tier 2～4）。設定を黙って編集したり、依存関係をインストールしたり、リポジトリのゲーティングを厳格化したりしないでください。これは init の適用モデル（構造上のルールはデフォルトで有効、ワークフローや厳格なルールはオプトイン）を編集時に適用したものです。

手順

ステップ 0：モードを選択する

ユーザーに尋ねます。

自動と対話、どちらにしますか？

• 自動 — 安全な変更（ルールがすでに有効な場合の直接置き換え）をすべて適用し、コミットして、差分をお見せします。リスクのある変更（設定の編集やプラグインのインストールが必要なもの）は、確認用の概要にまとめます。
• 対話 — 提案を一つずつ提示し、適用するものを選んでいただきます。

ユーザーから指定がない場合は、対話モードをデフォルトにします。

ステップ 1：インストール済みのものを確認する

npx vigiles generate types を実行し、プロジェクトで有効なリンタールールの一覧を取得します。.vigiles/generated.d.ts` を読み、検出されたすべてのリンターで利用可能なルールを確認します。

生成された型に含まれるリンターのプレフィックス（例：EslintRule、RuffRule）を記録します。参照ドキュメントが必要なのは、検出されたリンターだけです。

ステップ 2：すべての guidance ルールを見つける

プロジェクト内のすべての .spec.ts ファイル（**/*.md.spec.ts）を検索します。各ファイルで guidance() ルールをすべて特定します。

ステップ 3：生成された型と照合する（高速パス）

各 guidance ルールについて、.vigiles/generated.d.ts に有効なルールが直接一致するものがあるか確認します。これは高速で確実な方法です。ドキュメントを読む必要はありません。

次の項目を確認します。

• テキスト内のルール名との完全一致 — guidance に「no-console」とあり、EslintRule に no-console がある
• 意味上の一致 — guidance に「console.log を使わない」とあり、no-console が利用可能である
• ルールの説明との一致 — guidance に「未使用の変数」とあり、no-unused-vars または @typescript-eslint/no-unused-vars が利用可能である

一致するルールが見つかり、生成された型に含まれている（つまり、すでに有効になっている）場合は、設定変更不要の直接置き換えです。

ステップ 4：リンターのドキュメントを読む（低速パス）

ステップ 3 で一致しなかった guidance ルールについて、プロジェクトで検出されたリンターのリファレンスドキュメントを読みます。

• ESLint → ../linter-docs/eslint.md
• Stylelint → ../linter-docs/stylelint.md
• Ruff → ../linter-docs/ruff.md
• Pylint → ../linter-docs/pylint.md
• RuboCop → ../linter-docs/rubocop.md
• Clippy → ../linter-docs/clippy.md

プロジェクトで実際に使用されているリンターのドキュメントだけを読みます。 生成された型にルールがないリンターのドキュメントは読み飛ばします。

プラグインの表と判断マトリックスを確認します。guidance の内容は、次のパターンに該当する可能性があります。

• インストール済みだが有効になっていないプラグインルール
• まだインストールされていないプラグイン
• no-restricted-* 設定パターン（ステップ 4b を参照）

ステップ 4b：no-restricted-* パターン

多くの guidance ルールは、カスタムルールを使わず、組み込みのリンター設定で強制できます。これは、ルールを強化する最も一般的なパターンです。「X をしない」は制限設定に対応します。

ESLint:

// "Don't import from internal modules"
"no-restricted-imports": ["error", {
  patterns: [{ group: ["src/internal/*"], message: "Use the public API." }]
}],

// "Don't call console.log"
"no-restricted-syntax": ["error", {
  selector: 'CallExpression[callee.object.name="console"]',
  message: "Use the project logger."
}],

// "Don't use moment.js"
"no-restricted-imports": ["error", {
  paths: [{ name: "moment", message: "Use dayjs instead." }]
}],

Ruff:

# "Don't use os.system"
[tool.ruff.lint.flake8-tidy-imports.banned-api]
"os.system".msg = "Use subprocess.run instead."

RuboCop:

# "Don't use puts in production" — if Rails/Output doesn't fit
Custom/NoPuts:
  Enabled: true

no-restricted-* の変更を提案する場合は、次の内容を示します。

1. 必要な設定変更を正確に示します（ファイルとセクション）
2. その設定を参照する enforce() ルールを示します
3. これは仕様だけでなく、リンター設定も変更することを明記します

ステップ 5：提案を提示する

出力を次の段階に分けます。

Tier 1：直接置き換え（ルールはすでに有効化済み — リスクなし）

// Before
"no-console": guidance("Use structured logger instead of console.log"),
// After
"no-console": enforce("eslint/no-console", "Use structured logger instead of console.log"),

Tier 2：設定に基づくもの（ルールは存在するものの、設定オプションが必要）

// Spec change:
"no-moment": enforce("eslint/no-restricted-imports", "Use dayjs instead of moment."),

// Config change needed (eslint.config.mjs):
"no-restricted-imports": ["error", {
  paths: [{ name: "moment", message: "Use dayjs instead." }]
}],

Tier 3：プラグインのインストールが必要

"cognitive-complexity": guidance("Keep functions simple")
→ Install eslint-plugin-sonarjs, enable sonarjs/cognitive-complexity
→ enforce("eslint/sonarjs/cognitive-complexity", "Keep functions simple")

Tier 4：該当なし（ガイダンスとして維持 — 将来的なルール合成スキルの候補）

"research-first": guidance("Google unfamiliar APIs first.")
→ No linter rule can enforce this. Stays as guidance for now.
→ (Custom-rule synthesis is planned but not yet shipped.)

ステップ 6：変更を適用する

自動モードの場合：

1. Tier 1 の変更をすべて適用します（spec ファイルを編集し、guidance() を enforce() に置き換えます）
2. npm run build && npx vigiles compile を実行して、変更がコンパイルされることを確認します
3. コンパイルに失敗した場合は、該当する変更を元に戻し、エラーを報告します
4. 成功した変更をすべてコミットします
5. Tier 2～4 を要約して提示し、ユーザーに確認してもらいます

対話モードの場合：

1. すべての Tier を提示します
2. どの提案を適用するか、ユーザーに確認します
3. 承認された Tier 2 の変更については、リンターの設定を編集してから spec を編集します
4. npm run build && npx vigiles compile を実行して、コンパイルされることを確認します
5. コンパイルに失敗した場合は、エラーを報告して変更を元に戻します

**Tier 4（該当なし）の場合：**これらのルールはガイダンスとして維持されることをユーザーに伝えます。カスタムルールの合成は、今後提供予定のスキルであり、現時点では利用できません。