code-style-validator

インストール

別途ダウンロードする必要はありません。このスキルは、リポジトリ内のツール .claude/tools/cli/security-lint.cjs を実行します。

• Node.js（v18 以降）がインストールされていることを確認します。nodejs.org、または Windows では winget install OpenJS.NodeJS.LTS、macOS では brew install node から入手できます。
• プロジェクトのルートからスクリプトが自動的に呼び出されます。追加のインストール手順はありません。

チートシートとベストプラクティス

AST ベースの検証： ESLint（または同等のツール）をセレクター／パターンとともに使用します。ルールは特定のノード型を対象とします。カスタムルールを作成する前に、既存のコミュニティルールを優先してください。カスタムルールには meta（type、fixable、schema）と create が必要です。

プロセス： 命名規則（camelCase／PascalCase／snake_case）、インデント、インポート順序、関数／クラスの構造、コメントのスタイルを確認します。コミット前と CI で実行し、可能な場合は自動修正を提供します。

ヒント： 自動修正可能なルールには --fix を使用し、ポリシー適用には security-lint と組み合わせます。ドキュメントやツールで使えるように、ルールのメタデータを明確に定義します。AST セレクターを使って、パターン（ノード型、属性、子／兄弟ノード）を正確に照合します。

認定資格とトレーニング

ESLint： プロジェクトでの使用、カスタムルール、セレクター。認定資格はありません。スキルデータ：AST ベースの検証、コミット前／CI、自動修正、命名規則／インデント／インポート。

フックとワークフロー

推奨フック： コミット前に security-lint（スキルスクリプト）または ESLint を実行し、失敗した場合はコミットをブロックします。developer（副次）、code-reviewer（副次）、qa（CI）と併用します。

ワークフロー： code-reviewer（副次）、developer（副次）と併用します。流れ：コミット前または CI で → バリデーターを実行 → 修正するかブロックします。code-review-workflow.md、validation フックを参照してください。

コードスタイルバリデーター - AST（抽象構文木）解析を使用して、コードスタイルをプログラムで検証します。コードスタイルルールを補完し、自動チェックを提供します。 - コードのコミット前 - コミット前フック内 - コードレビュー中 - CI/CD パイプライン内 - 一貫したコードスタイルの適用

ステップ 1：コードスタイルのパターンを特定する

コードベースを分析して、スタイルのパターンを特定します。

• 命名規則（camelCase、PascalCase、snake_case）
• インデントのスタイル（スペースまたはタブ、幅）
• インポートの整理方法
• 関数／クラスの構造
• コメントのスタイル

ステップ 2：AST ベースの検証

言語固有の AST パーサーを使用します。

TypeScript/JavaScript： </execution_process>

**TypeScript/JavaScript の AST 検証**：

const ts = require('typescript');
const fs = require('fs');

function validateTypeScriptFile(filePath) {
  const sourceCode = fs.readFileSync(filePath, 'utf8');
  const sourceFile = ts.createSourceFile(filePath, sourceCode, ts.ScriptTarget.Latest, true);

  const issues = [];

  // Validate naming conventions
  ts.forEachChild(sourceFile, node => {
    if (ts.isFunctionDeclaration(node) && node.name) {
      if (!/^[a-z][a-zA-Z0-9]*$/.test(node.name.text)) {
        issues.push({
          line: sourceFile.getLineAndCharacterOfPosition(node.name.getStart()).line + 1,
          message: `Function name "${node.name.text}" should be camelCase`,
        });
      }
    }
  });

  return issues;
}

</code_example>

<code_example> Python の AST 検証：

import ast
import re

def validate_python_file(file_path):
    with open(file_path, 'r') as f:
        source_code = f.read()

    tree = ast.parse(source_code)
    issues = []

    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            if not re.match(r'^[a-z][a-z0-9_]*$', node.name):
                issues.append({
                    'line': node.lineno,
                    'message': f'Function name "{node.name}" should be snake_case'
                })

    return issues

</code_example>

<code_example> スタイルチェック：

命名規則：

• 変数：camelCase（JS/TS）または snake_case（Python）
• 関数：camelCase（JS/TS）または snake_case（Python）
• クラス：PascalCase
• 定数：UPPER_CASE
• プライベート：アンダースコアをプレフィックスとして付けます

フォーマット：

• インデント：2 スペース（JS/TS）または 4 スペース（Python）
• 行の長さ：88～100 文字
• 末尾のカンマ：あり（JS/TS）
• セミコロン：一貫して使用します

構成：

• インポート順：外部、内部、相対
• 関数の長さ：< 50 行
• ファイル構成：エクスポート、ヘルパー、型 </code_example>

<code_example> 使用例（テンプレート - 先にバリデーターを実装してください）：

単一ファイルを検証：

# After implementing your validator:
node validate-code-style.js src/components/Button.tsx

ディレクトリを検証：

# After implementing your validator:
node validate-code-style.js src/components/

出力形式：

{
  "file": "src/components/Button.tsx",
  "valid": false,
  "issues": [
    {
      "line": 15,
      "column": 10,
      "rule": "naming-convention",
      "message": "Variable 'UserData' should be camelCase: 'userData'",
      "severity": "error"
    },
    {
      "line": 23,
      "column": 5,
      "rule": "indentation",
      "message": "Expected 2 spaces, found 4",
      "severity": "warning"
    }
  ],
  "summary": {
    "total": 2,
    "errors": 1,
    "warnings": 1
  }
}

</code_example>

<code_example> Pre-commit フック（テンプレート - 先にバリデーターを実装してください）：

#!/bin/bash
# .git/hooks/pre-commit
changed_files=$(git diff --cached --name-only --diff-filter=ACM | grep -E '\.(ts|tsx|js|jsx|py)$')

for file in $changed_files; do
  # Replace with your actual validator path
  if ! node validate-code-style.js "$file"; then
    echo "Code style validation failed for $file"
    exit 1
  fi
done

</code_example>

<code_example> CI/CD 統合（テンプレート - 先にバリデーターを実装してください）：

# .github/workflows/code-style.yml
- name: Validate code style
  run: |
    # Replace with your actual validator path
    node validate-code-style.js src/
    if [ $? -ne 0 ]; then
      echo "Code style validation failed"
      exit 1
    fi

</code_example>

1. **補完であり、置き換えではない**：このツールはコードスタイル規則を補完するものであり、置き換えるものではありません 2. **ルールを設定可能にする**：チームが検証ルールをカスタマイズできるようにします 3. **可能な場合は自動修正する**：よくある問題に対して自動修正の提案を行います 4. **迅速なフィードバック**：開発中にすぐフィードバックを提供します 5. **明確なメッセージ**：行番号や提案を含む、分かりやすいエラーメッセージを表示します

鉄則

1. 正規表現ではなく、必ず AST ベースの検証を使用してください — 正規表現ベースのスタイルチェックは、複数行の構文、コメント、文字列で正しく動作しません。AST ベースのツール（ESLint、Prettier）は、フォーマットに依存せず、意味的にも正確です。
2. 独自ルールを書く前に、必ず既存の ESLint/Prettier ルールを確認してください — 独自ルールは保守コストが高く、スタイル要件の 95% は設定によって既存ルールで対応できます。
3. スタイルに関する警告ではコミットをブロックせず、エラーの場合に限ってください — 警告は参考情報です。警告を理由に CI をブロックすると、煩わしさからチームがスタイルチェックを全面的に無効化することにつながります。
4. 検出事項とともに、必ず自動修正の提案を提示してください — 自動修正がないレポートでは、問題ごとに手作業での対応が必要になります。自動修正可能な違反は、手動対応の 30% に対して、ほぼ 100% 解消されます。
5. スタイル検証は、必ず pre-commit フックと CI の両方で実行してください — pre-commit は問題がリポジトリに到達する前にローカルで検出し、CI はフックが回避された場合やインストールされていない場合の問題を検出します。

アンチパターン

アンチパターン	失敗する理由	適切な方法
正規表現ベースのスタイルチェック	複数行、文字列、コメントで正しく動作しません	AST ベースのツール（ESLint、Prettier）を使用します
対応済みの規約に対する独自ルール	保守コストが高く、コミュニティの規約と一貫性がありません	まず既存の ESLint/Prettier ルールを設定します
警告を理由に CI をブロックする	過度な煩わしさから、チームがスタイルチェックを無効化します	エラーの場合のみブロックし、警告はログに記録します
自動修正のないスタイル検証	手動修正の解消率が低くなります	検出事項とともに、必ず自動修正コマンドを提示します
ローカルのみで実行し、CI では実行しない	開発者は pre-commit フックを定期的に回避します	pre-commit と CI パイプラインの両方で実行します

メモリプロトコル（必須）

開始前： .claude/context/memory/learnings.md を読みます

完了後：

• 新しいパターン -> .claude/context/memory/learnings.md
• 問題の発見 -> .claude/context/memory/issues.md
• 決定事項 -> .claude/context/memory/decisions.md

中断を想定してください：メモリに記録されていなければ、起きていないのと同じです。