code-quality

name	code-quality
description	プロジェクトに設定されたリンティング、フォーマット、型チェックの検出と実行。以下の場合に使用: - コード記述・編集後の品質基準の確認 - リントエラーやフォーマット問題の修正 - プロジェクトに設定された品質ツールの実行 - CI 品質チェックに失敗している場合 Trigger phrases: lint, format code, run linter, fix formatting, type check, code style
allowed-tools	Bash, Read, Glob, Grep, WebSearch, WebFetch
model	haiku
user-invocable	true

コード品質

プロジェクトに設定された品質ツールの検出と使用。このスキルは発見プロセスを定義するものであり、特定のツールコマンドを定義するものではない。

設計原則

1. プロジェクトが設定を所有する: どのツールが使われているか決めつけない
2. 実行前に発見する: プロジェクトに設定されたツールを確認する
3. プロジェクトコマンドを使用する: package.json/Makefile 等で定義されたスクリプトを優先
4. インストールしない: 設定されていないツールを追加しない

---

ワークフロー

ステップ 1: 品質ツール設定の発見

特定のツールを前提とせずに品質ツールの存在を確認する:

# 品質ツールを示す可能性のある設定ファイルを一覧
ls -la .* *.config.* *.json *.toml *.yml *.yaml 2>/dev/null | head -30

# 一般的な設定パターンを確認（特定のツールではなく）
ls -la *lint* *format* *prettier* *eslint* *biome* *ruff* *black* *rubocop* *golangci* 2>/dev/null

ステップ 2: 定義済みスクリプトの確認

常にプロジェクト定義のコマンドを優先する:

# JavaScript/TypeScript プロジェクト
grep -A 30 '"scripts"' package.json 2>/dev/null | grep -E '(lint|format|check|style)'

# Python プロジェクト
grep -A 10 '\[tool\.' pyproject.toml 2>/dev/null
grep -E '(lint|format|check)' Makefile 2>/dev/null

# 任意のプロジェクト
cat Makefile 2>/dev/null | grep -E '^(lint|format|check|style):'

ステップ 3: 検出されたコマンドの実行

優先順位:

1. プロジェクトスクリプト（最も信頼性が高い）

   • npm run lint、npm run format、make lint 等

2. ツールの直接実行（スクリプトはないが設定がある場合）

   • 設定ファイルが検出された場合のみ
   • 不明な場合は現在のコマンド構文を検索

3. リサーチ（ツールが不慣れな場合）

   WebSearch: "[ツール名] run command [year]"
   WebFetch: [公式ドキュメント] → "Extract CLI usage"
   

ステップ 4: ビルドの動作確認

品質修正後:

# プロジェクトのビルドコマンドを実行（先に発見する）
grep -E '"build"' package.json 2>/dev/null && npm run build
grep -E '^build:' Makefile 2>/dev/null && make build

---

発見パターン

品質ツールの特定

ツール名をハードコードする代わりにパターンを探す:

パターン	示唆する内容
ファイル名に *lint*	リンティング設定
ファイル名に *format* または *prettier*	フォーマット設定
*.config.* ファイル	ツール設定
pyproject.toml の [tool.*] セクション	Python ツール設定
lint、format、check キーワードを含むスクリプト	プロジェクト定義コマンド

不明な設定の読み取り

不慣れなツールの設定ファイルを見つけた場合:

1. 設定ファイルを読んでツール名を把握する
2. そのツールを使用するスクリプトがあるか確認する
3. 必要に応じて WebSearch でツールのドキュメントを検索する
4. ドキュメントに記載されたインターフェースでツールを実行する

---

やってはいけないこと

やらない	理由
設定されていないツールをインストール	プロジェクトの依存関係が変わる
特定のツール名を前提とする	ツールはプロジェクトごとに異なる
設定なしでツールを実行	誤った設定が使われる可能性
プロジェクト設定をオーバーライド	プロジェクト基準に違反
ツールコマンドをハードコード	コマンドはバージョン間で変わる

---

CI との統合

プロジェクトは通常以下で品質を強制する:

• プリコミットフック
• CI パイプライン（GitHub Actions、GitLab CI 等）
• エディタ統合

このスキルはそれらの仕組みを補完するものであり、同じ設定を使って同じツールをオンデマンドで実行する。

---

成功基準

• 設定された全リントルールがパス
• 型エラーなし（型チェックが設定されている場合）
• ビルドが正常に完了
• Git フックがパス（存在する場合）

---

Rules (L1 - Hard)

プロジェクト設定の尊重に不可欠。

• NEVER: ツールをインストールしたり前提としない（プロジェクトの依存関係が変わる）
• NEVER: 設定なしでツールを実行しない（誤った設定になる）
• NEVER: ツールコマンドをハードコードしない（動的に発見する）

Defaults (L2 - Soft)

効果的な品質チェックに重要。適切な理由がある場合はオーバーライド可。

• コマンド実行前にツールを検出する
• プロジェクトに設定されたスクリプト/コマンドを使用する（npm run lint、make lint）
• まず package.json/Makefile のスクリプトを確認する
• 修正後にビルドを検証する
• エラーを明確に報告する（無視しない）

Guidelines (L3)

包括的な品質保証のための推奨事項。

• consider: 全品質ツールを順番に実行する（lint → format → typecheck）
• prefer: 利用可能な場合は自動修正モードを優先（--fix、-w）