메뉴
プロジェクトに設定されたリンティング、フォーマット、型チェックの検出と実行。以下の場合に使用: - コード記述・編集後の品質基準の確認 - リントエラーやフォーマット問題の修正 - プロジェクトに設定された品質ツールの実行 - CI 品質チェックに失敗している場合 Trigger phrases: lint, format code, run linter, fix formatting, type check, code style
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
設定ファイルとソースコードからプロジェクトの技術スタックを自動検出。 Use when: 新規コードベースでの作業開始、言語/フレームワーク/ツールの特定。 Trigger phrases: detect stack, what framework, identify technology, project setup
REST、GraphQL、gRPC の API 設計パターン。 Use when: API の新規設計、OpenAPI 仕様作成、バージョニング/ページネーション設計。 Trigger phrases: API design, REST endpoint, GraphQL schema, OpenAPI, gRPC, pagination
エバリュエーター・オプティマイザーのフィードバックループによる反復改善。 Use when: 出力品質の反復改善、明確な評価基準がある複雑な出力の最適化。 Trigger phrases: iterate, refine, improve quality, feedback loop, evaluate and optimize
ルール遵守と創造的な問題解決のバランスを取るためのフレームワーク。 Anthropic のエージェント設計に関する研究に基づく。 使用場面: - 複数の有効なアプローチがある複雑な判断に直面した場合 - 状況に対して指示が過度に規範的に感じられる場合 - ガイドラインを特定のコンテキストに適応させる必要がある場合 - 精度要件と革新的なソリューションのバランスを取る場合 Trigger phrases: think creatively, use judgment, adapt approach, better solution, flexibility
曖昧なリクエストを明確にするための構造化された要件インタビューフレームワーク。使用場面: - ユーザー要件が不明確または不完全な場合 - 新機能を開始し要件を収集する必要がある場合 - ユーザーのニーズ、制約、優先順位を理解する必要がある場合 - ビジネスリクエストを技術仕様に変換する場合 - ユーザーが詳細なしに「～したい」「～を追加して」と言う場合 Trigger phrases: gather requirements, clarify request, what do you need, interview user, requirements gathering, unclear request
すべてのユーザー向けコンテンツに日本語出力を強制する。 使用場面: - エージェント出力を日本語にする必要がある場合 - レスポンス全体の言語の一貫性を検証する場合 - 仕様書やドキュメントを日本語で生成する場合 Trigger phrases: Japanese, 日本語, language mode, output language
| 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 |
プロジェクトに設定された品質ツールの検出と使用。このスキルは発見プロセスを定義するものであり、特定のツールコマンドを定義するものではない。
特定のツールを前提とせずに品質ツールの存在を確認する:
# 品質ツールを示す可能性のある設定ファイルを一覧
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
常にプロジェクト定義のコマンドを優先する:
# 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):'
優先順位:
プロジェクトスクリプト（最も信頼性が高い）
npm run lint、npm run format、make lint 等ツールの直接実行（スクリプトはないが設定がある場合）
リサーチ（ツールが不慣れな場合）
WebSearch: "[ツール名] run command [year]"
WebFetch: [公式ドキュメント] → "Extract CLI usage"
品質修正後:
# プロジェクトのビルドコマンドを実行（先に発見する）
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 キーワードを含むスクリプト | プロジェクト定義コマンド |
不慣れなツールの設定ファイルを見つけた場合:
| やらない | 理由 |
|---|---|
| 設定されていないツールをインストール | プロジェクトの依存関係が変わる |
| 特定のツール名を前提とする | ツールはプロジェクトごとに異なる |
| 設定なしでツールを実行 | 誤った設定が使われる可能性 |
| プロジェクト設定をオーバーライド | プロジェクト基準に違反 |
| ツールコマンドをハードコード | コマンドはバージョン間で変わる |
プロジェクトは通常以下で品質を強制する:
このスキルはそれらの仕組みを補完するものであり、同じ設定を使って同じツールをオンデマンドで実行する。
プロジェクト設定の尊重に不可欠。
効果的な品質チェックに重要。適切な理由がある場合はオーバーライド可。
包括的な品質保証のための推奨事項。