Skill.md検索

プロジェクトのコード規約（CLAUDE.md）とアーキテクチャパターン（docs/development-patterns.md）に基づき、変更内容を客観的にレビューできる 仕様準拠、コード品質、アーキテクチャ準拠、パフォーマンス、セキュリティ、ダークモード対応、テスト、後方互換性、ドキュメント同期の 9 観点で、具体的で対応可能な指摘を返す 必須修正（MUST）、推奨修正（SHOULD）、検討事項（CONSIDER）の 3 段階で重要度を明示し、優先順位をつけやすくできる ドキュメント未更新を含め、コード変更に伴う更新漏れを検出し、プロジェクト全体の一貫性を保つ コード変更を提出する前に品質チェックを受けたい開発者 プロジェクト規約への準拠状況を確認したい人 仕様書（タスクファイル）の要件を満たしているか検証したい人 チームのアーキテクチャ・パフォーマンス・セキュリティ水準を維持したい者 ソースコードは一切変更せず（読み取り専用）、指摘は具体的かつ対応可能なものに限定。重要度を MUST/SHOULD/CONSIDER で明示。仕様書の要件準拠を最優先で確認。ワークフローは、変更ファイル一覧から影響範囲を把握 → タスクファイルの受け入れ基準と実装を照合 → 9 観点でチェック → 構造化フォーマットでフィードバック返却。レビュー観点：(1)仕様準拠（受け入れ基準・機能・データモデル）、(2)コード品質・可読性（命名・単一責務・型定義）、(3)アーキテクチャ準拠（Feature-Sliced Design・Zustand・Zod・エイリアス・依存方向）、(4)パフォーマンス（メモ化・セレクタ内処理・AG Grid メモ化・再レンダリング）、(5)セキュリティ（XSS・サニタイゼーション・機密情報）、(6)ダークモード対応（色指定）、(7)テスト（重要ロジック・振る舞い検証・日本語説明）、(8)後方互換性（マイグレーション・スキーマ・public インターフェース）、(9)ドキュメント同期（docs/ 更新）。ドキュメント未更新は MUST として報告。

実装前の設計を構造化 — 要件整理・影響調査・タスク分解・並行化分析・テスト戦略を体系的に文書化。実装開始前に計画を可視化できます。 影響範囲を正確に把握 — スキーマ・ストア・コンポーネント・ページ・ユーティリティ・テスト・ドキュメント・設定など8カテゴリから影響箇所をテーブル形式で整理できます。 タスク依存関係を明確化 — Phase 単位の並行化分析で、並行実行可能なタスクと逐次実行が必要なタスクを ASCII グラフで可視化。実装の効率化を支援します。 ソースコードを変更しない — 読み取り専用で設計に専念。実装計画のレビュー・承認を得た後に初めて実装に進むことで品質を確保できます。 大型機能を複数タスクに分割する開発者 — タスク依存関係と並行化可能性を整理。チーム全体での実装スケジュール最適化に役立ちます。 実装の影響範囲が不明確な場合 — ファイル参照・スキーマ参照・テストカバレッジなどを事前に調査。思わぬ修正漏れを防げます。 レビューや承認プロセスを重視するチーム — 設計ドキュメントを会話内または output/tasks/ に出力。承認を経てから実装に進めます。 プロジェクト全体の設計方針を蓄積したい人 — 新規パターン・ピットフォールが検出される度に project-config.md §11 を更新。組織知として蓄積できます。 機能実装の事前設計を行い、ソースコード変更は一切しません。前提として docs/project.md（ルーティング・ストア一覧）と docs/architecture.md（ディレクトリ構成）を参照。スタブの場合は project-config.md §1〜§4 をフォールバック参照。ワークフローは：①要件整理で受け入れ基準を明文化、②影響調査で関連ファイル・ストア・スキーマ・テストを特定（テーブル形式：カテゴリ∈{スキーマ, ストア, コンポーネント, ページ, ユーティリティ, テスト, ドキュメント, 設定}）、③タスク分解で Phase 単位に分割（フォーマット：タスクID — 説明（変更ファイル: パス | 依存: タスクID））、④依存関係グラフを ASCII で可視化、⑤テスト戦略を定義、⑥ドキュメント更新計画を明記、⑦リスク・懸念事項を記載（技術的リスク時のみ）。出力先はデフォルト会話内、output/ ディレクトリ存在時は output/tasks/PLAN_.md。

仕様に合致しているか確認 — タスク定義書と実装を照らし合わせ、要件をすべて満たしているか、余分な機能がないかを自動チェックできます。 可読性・設計の問題を指摘 — 変数名の不適切さ、関数の責務が曖昧な部分、不要なコメント、型定義の問題などを具体的に指摘できます。 セキュリティ・パフォーマンスの危険を検出 — XSS脆弱性、入力値の未検証、無駄な再レンダリング（リエンドリング）などの問題を早期に発見できます。 プロジェクト規約への準拠を自動判定 — アーキテクチャパターン、色設定、状態管理の使い方などが、プロジェクト標準に沿っているかを検査できます。 開発チームのコードレビュアー — 人手による詳細なレビュー前に、機械的にチェックできる部分を自動化したい方 個人開発者 — 自分のコードが標準に沿っているか、潜在的なバグがないか客観的にチェックしたい方 品質管理担当者 — プロジェクト全体のコード品質を定量的に把握し、改善トレンドを追跡したい方

複数ページをまたぐシナリオを自動実行 — ログイン→データ入力→結果確認→リロード確認など、複雑なユーザー操作フローをプログラムで自動化し、毎回確実に検証できます。 リグレッション（機能劣化）を早期発見 — 新機能追加後に過去の機能が壊れていないか、全自動でテストして検出できます。 Page Objectパターンでテスト保守を簡素化 — 画面操作の詳細をカプセル化することで、UI変更時にテストコード全体を修正する手間を削減できます。 テストレポート・スクリーンショット・ビデオ証跡を自動出力 — テスト失敗時に、どの操作で何が起きたかをビジュアルに確認できます。 QA・テスト担当者 — 手動テストの定型化できる部分を自動化し、テスト実行時間を短縮したい方 開発効率を重視するチーム — 機能追加時に「前の機能壊れてないか」を常に確認するための仕組みが必要な方 本番リリース前品質確認 — 本当に必要なユーザー操作が全部成功するか、リリース前に機械的に確認したい方

テストを先に書いて実装品質を確保 — テストファイルを先に作成し、それに合致するコードを実装することで、バグの少ない実装を実現できます。 仕様書から実装コード・テストまで一括生成 — タスク定義書を読み込み、必要なコンポーネント・状態管理・ユーティリティ・テストを自動作成できます。 プロジェクト規約を自動で守った実装 — ディレクトリ構成、命名規則、型定義、アーキテクチャ層の依存関係を自動適用し、規約外の実装を防げます。 ドキュメントの自動同期 — 実装内容に応じて、開発ガイドやプロジェクト設定ドキュメントを自動更新し、ドキュメントとコードのズレを防げます。 新規プロジェクトの初期構築に携わる開発者 — プロジェクト標準を最初から正しく組み込み、後の保守コストを削減したい方 複数人開発チーム — チームメンバーがバラバラの実装をしないよう、ルールに従った自動生成コードを基盤としたい方 品質と生産性の両立が必要な組織 — テスト・ドキュメント・コード品質を一度のステップで確保し、スピーディにリリースしたい方

OSSライセンスの適合性を確認 — 使用している外部ライセンスがプロジェクトと互換性があるか、帰属表示が必要かなどを自動判定できます。 個人情報の適切な取り扱いをチェック — コードやドキュメントに含まれる個人データ（個人情報保護法、GDPR等）の保護対応状況を確認できます。 知的財産権の問題を事前に検出 — 他者の著作物（コード、画像、フォント等）の使用許諾漏れなどの法務リスクを明示できます。 著作権・契約条項の遵守状況を可視化 — 法的根拠に基づいた具体的な指摘レポートを出力できます。 法務・コンプライアンス担当者 — 開発プロジェクトの法的リスク評価に活用できます。 プロジェクトマネージャー — 本番リリース前の法務チェックリストの確認を自動化できます。 開発チームリード — チームが意識していない法的問題を事前に発見できます。 スタートアップ・ベンチャー企業の開発者 — 法務専門家の確保が難しい段階で、基本的な法務リスク評価ができます。

パフォーマンスのボトルネックをデータで特定 — 推測ではなく、実際の計測ツール（プロファイラー等）を使ってどこが遅いかを正確に把握できます。 バンドルサイズを削減 — 不要なコードや重い依存パッケージを特定し、最適化の優先順位をつけられます。 ムダな再レンダリングを排除 — メモ化などの最適化を「必要な箇所だけ」に適用でき、可読性を損なわないコードを実現できます。 メモリ・ストレージの使い方を改善 — 大規模データの管理方法を見直し、快適な動作を保ちながら安定性を高められます。 最適化の効果を数値で証明 — Before/After の比較レポートで改善効果を可視化できます。 Webエンジニア・フロントエンド開発者 — ページ速度改善に科学的なアプローチを適用できます。 プロダクト責任者 — ユーザー体験を損なわない範囲での最適化を進められます。 スタートアップのテックリード — 限られたリソースで体感できる改善に集中できます。 パフォーマンス改善タスクの担当者 — 「何をすべきか」を計測データから判断できます。

日本語の要件メモを構造化されたPRDに変換 — 箇条書きやラフなメモを、エンジニアが実装しやすい形式の仕様書に整理できます。 要件の漏れや曖昧さを明示 — 「これはどういう意味？」という不明点を「【要確認】」として明記し、確認漏れを防げます。 既存の技術ドキュメントと整合性を保つ — プロジェクトのアーキテクチャやコード規約と照らし合わせた実装可能な仕様を生成できます。 機能要件・非機能要件を整理 — 画面操作フロー、受け入れ基準、データ仕様などを体系的にまとめられます。 プロダクト企画・マーケティング担当者 — 企画書やメモからエンジニアが実装できる仕様書を作成できます。 プロジェクトマネージャー・スクラムマスター — 要件定義工程を効率化し、齟齬を減らせます。 起業家・事業責任者 — 開発チームへの説明資料として使える仕様書を素早く作成できます。 開発チーム全体 — 要件の理解を統一でき、実装前の確認がスムーズになります。

コンポーネントを安全に分割・整理 — 機能別の責務分離を行いながら、既存の動作を保証できます。 依存関係のルール違反を修正 — アーキテクチャ上の依存方向を正しくし、メンテナンスしやすい構造に改善できます。 ストア・状態管理を段階的に統合・分割 — データフローを明確にしながら、テストが全てパスした状態で進められます。 段階ごとにテストを実行し巻き戻し可能に — 各ステップで検証しながら進められるため、問題が起きても簡単に戻せます。 コード規約に合わせた一貫性のある改善 — プロジェクト固有のパターンを守りながら改善できます。 バックエンド・フロントエンド開発者 — 既存機能を壊さずにコード品質を高めたい時に活用できます。 技術責任者・アーキテクト — 大規模な構造改善を安全に段階的に実施できます。 開発チーム全体 — 技術的負債を計画的に返済しながら、新機能開発を継続できます。 レガシーコード改善プロジェクト — 大規模な既存コードベースの品質向上を無理なく進められます。

依存パッケージの既知脆弱性（CVE）を自動検出 — npm audit等のツールを使い、危険なライブラリを特定し、パッチの当て方を提示できます。 ソースコード内のセキュリティ問題を静的に検査 — クロスサイトスクリプティング（XSS）、インジェクション、ハードコードされた認証情報など、OWASP Top 10の脆弱性を発見できます。 シークレット（秘密鍵・トークン）の露出を検出 — うっかりコミットされたAPI鍵やパスワード等の機密情報を自動で見つけられます。 脆弱性の優先度を明確に提示 — CRITICAL / HIGH / MEDIUM / LOW で重要度を分類し、修正の優先順位がつけやすくなります。 偽陽性を区別 — ツールの誤検知を明記し、実装者が不要な修正作業を避けられます。 セキュリティ担当者・インフラエンジニア — 定期的なセキュリティチェックを自動化できます。 DevOps/CI-CD責任者 — パイプラインに組み込み、本番リリース前の自動チェックができます。 プロダクト開発チーム — リリース前の基本的なセキュリティ確認を短時間で実施できます。 スタートアップ・組織 — 専門のセキュリティチームがない段階でも、基本的な脆弱性を把握できます。

プロジェクトのデザイン規約に基づいて、UIコンポーネントの実装・修正を自動で行います。 デザインレビュアーとして、既存のUIがデザインシステムに準拠しているかチェックし、改善点をレポート化できます。 ライト/ダークモード両方の表示確認や、スマートフォン・タブレット・PCなど様々な画面サイズ（レスポンシブデザイン）での表示検証を実施します。 カラーパレット・フォント・間隔などの視覚的な一貫性を保ちながら、アクセシビリティ（視覚障害者向けの対応）を確保します。 デザイン修正が必要な箇所を視覚的にわかりやすく指摘し、修正案を提案できます。 UI/UXデザイナーが、実装時の細部チェックや品質管理を効率化したい場合 フロントエンド開発者が、デザイン規約に沿った実装をサポートしてほしい場合 プロダクトマネージャーが、デザインの統一性をチーム全体で保ちたい場合 スタートアップやスモールチームで、デザインレビューの手間を削減したい場合

新しい機能を追加する際に、変更が必要なファイル・データベーススキーマ・テストを事前に洗い出し、見落としを防げます 機能実装を小分けにしたタスクに分割し、どの作業を並行実行でき、どの部分は順番に実行する必要があるかを明示できます 変更の影響範囲を図解することで、実装前に潜在的なリスク（他機能への悪影響など）を検出できます テスト方針を事前に定義し、何をテストすべきかをチームで共有でき、実装後の手戻りを減らせます 実装内容をドキュメント化することで、チームレビューの質を高め、本実装への承認を効率的に得られます プロジェクトリーダーで、機能追加のスケジュール立案と影響調査を自動化したい人 複数エンジニアで開発を進めるチームで、並行作業の可能性を事前に把握したい管理者 バグの混入を最小限にしたい開発チームで、実装前の設計レビューを徹底したい組織 レガシーコード（古いシステム）の改修で、変更の波及範囲を正確に把握しながら進めたい開発者