Addyosmaniスキル

WCAG 2.2ガイドラインに従ってウェブアクセシビリティを監査・改善します。「アクセシビリティの改善」「a11y監査」「WCAG準拠」「スクリーンリーダー対応」「キーボードナビゲーション」「アクセシブルにする」と依頼された場合に使用します。

安定したAPIとインターフェース設計をガイドします。APIやモジュール境界、公開インターフェースを設計する際に使用します。RESTやGraphQLのエンドポイントを作成するとき、モジュール間の型契約を定義するとき、またはフロントエンドとバックエンドの境界を確立するときに使用します。

モダンなウェブ開発のベストプラクティスをセキュリティ、互換性、コード品質に適用します。「ベストプラクティスを適用」「セキュリティ監査」「コードのモダナイズ」「コード品質レビュー」「脆弱性チェック」と依頼された場合に使用します。

Chrome DevTools MCPを通じて実際のブラウザでテストを実行します。ブラウザで動作するものを構築・デバッグする際に使用します。DOMの検査、コンソールエラーの取得、ネットワークリクエストの分析、パフォーマンスのプロファイリング、実際のランタイムデータによる視覚的出力の検証が必要な場合に使用します。chrome-devtools MCPサーバーの設定が必要です。

CI/CDパイプラインのセットアップを自動化します。ビルドおよびデプロイパイプラインの設定や変更時に使用します。品質ゲートの自動化、CIでのテストランナーの設定、デプロイ戦略の確立が必要な場合に使用します。

複数軸でのコードレビューを実施します。変更をマージする前に使用してください。自分自身、他のエージェント、または人間が書いたコードをレビューする際に使用します。コードがメインブランチに取り込まれる前に、複数の観点から品質を評価する必要がある場合に使用してください。

コードを明確にするために簡略化します。動作を変えずにコードをリファクタリングして明確にする場合に使用します。コードは動作するが、読みやすさ、保守性、拡張性が本来あるべきよりも低い場合に使用します。不要な複雑さが蓄積されたコードをレビューする場合に使用します。

エージェントのコンテキスト設定を最適化します。新しいセッションを開始するとき、エージェントの出力品質が低下したとき、タスクを切り替えるとき、またはプロジェクトのルールファイルやコンテキストを設定する必要があるときに使用します。

Core Web Vitals（LCP、INP、CLS）を最適化し、ページ体験と検索ランキングを向上させます。「Core Web Vitalsを改善」「LCPを修正」「CLSを削減」「INPを最適化」「ページ体験の最適化」「レイアウトシフトを修正」と依頼された場合に使用します。

系統的な根本原因デバッグをガイドします。テストが失敗したとき、ビルドが壊れたとき、動作が期待と一致しないとき、または予期しないエラーに遭遇したときに使用します。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要なときに使用します。

非推奨と移行を管理します。古いシステム、API、機能を削除する際に使用します。ユーザーをある実装から別の実装へ移行する際に使用します。既存のコードを維持するか廃止するかを判断する際に使用します。

決定とドキュメントを記録します。アーキテクチャ上の決定を行うとき、公開APIを変更するとき、機能をリリースするとき、または将来のエンジニアやエージェントがコードベースを理解するために必要なコンテキストを記録する必要があるときに使用します。

重要でない決定はすべて、新しいコンテキストでの敵対的レビューを経てから確定させる。正確性が速度よりも重要な場合、不慣れなコードを扱う場合、影響が大きい場合（本番環境、セキュリティに関わるロジック、取り消し不能な操作）、または自信のある出力を後でデバッグするよりも今検証する方が安上がりな場合に使用する。

プロダクション品質で、アクセシブルでレスポンシブなユーザー向けUIを構築します。インターフェースやページの構築・修正、コンポーネントの作成、レイアウトの実装、WCAGアクセシビリティ要件の達成、状態管理を行う場合、または出力がAI生成ではなくプロダクション品質に見える必要がある場合に使用します。

gitワークフローの実践を構造化します。コード変更を行う際に使用します。コミット、ブランチ作成、コンフリクト解決時、または複数の並行ストリームにわたって作業を整理する必要がある場合に使用します。リリース作成、セマンティックバージョンのバンプ選択、タグ付け、またはチェンジログ作成時に使用します。

生のアイデアを、構造化された発散的・収束的思考を通じて、鋭く実行可能なコンセプトに洗練します。アイデアがまだ漠然としているとき、計画を確定する前に前提をストレステストする必要があるとき、または一つの選択肢に収束する前に選択肢を広げたいときに使用します。「アイデアを出して」「このアイデアを洗練して」「計画をストレステストして」というトリガーで起動します。

変更を段階的に提供します。複数のファイルに影響する機能や変更を実装する際に使用します。一度に大量のコードを書こうとしている場合や、タスクが大きすぎて一度に完了できないと感じる場合に使用します。

ユーザーが「こうすべきだ」と思っていることではなく、実際に望んでいることを抽出する。1回に1つの質問でインタビューを進め、根底にある意図について約95%の確信が得られるまで行う。以下の場合に使用する：依頼が不十分にしか指定されていない場合（「誰のために」「なぜ今なのか」なしで「Xを作って」と言う場合）、ユーザーが明示的に呼びかけた場合（「インタビューして」「詰めて」「本当にそれでいい？」「考えをストレステストして」）、または計画、仕様、コードが存在する前に、あいまいな要件を自分で黙って補っていることに気づいた場合。

コードを計装し、本番環境の動作を可視化・診断可能にします。ログ、メトリクス、トレース、アラートを追加する際に使用します。本番稼働する機能を出荷し、その動作の証拠が必要な場合に使用します。本番環境の問題が報告されたが、利用可能なデータから何が起きたのか判断できない場合に使用します。

ウェブパフォーマンスを最適化し、読み込みを高速化してユーザー体験を向上させます。「サイトを高速化」「パフォーマンス最適化」「読み込み時間短縮」「遅い読み込みの修正」「ページ速度改善」「パフォーマンス監査」と依頼された場合に使用します。

フロントエンド、バックエンド、クエリ、データベースにわたってアプリケーションのパフォーマンスを最適化します。パフォーマンス要件がある場合、パフォーマンス低下が疑われる場合、Core Web Vitalsや読み込み時間の改善が必要な場合、N+1クエリパターンの修正が必要な場合、またはプロファイリングでボトルネックが明らかになった場合に使用します。

作業を順序付けられたタスクに分割します。仕様や明確な要件があり、実装可能なタスクに分割する必要がある場合に使用します。タスクが大きすぎて着手できないと感じる場合、範囲を見積もる必要がある場合、または並行作業が可能な場合に使用します。

コードを脆弱性から強化します。ユーザー入力、認証、データストレージ、外部統合を扱う際に使用します。信頼できないデータを受け入れる機能、ユーザーセッションを管理する機能、またはサードパーティサービスとやり取りする機能を構築する際に使用します。

検索エンジンの可視性とランキングを最適化します。「SEOを改善」「検索に最適化」「メタタグを修正」「構造化データを追加」「サイトマップ最適化」「検索エンジン最適化」と依頼された場合に使用します。

本番リリースの準備を行います。本番環境へのデプロイ準備時に使用します。リリース前チェックリストが必要な場合、モニタリングの設定時、段階的ロールアウトの計画時、またはロールバック戦略が必要な場合に使用します。

すべての実装判断を公式ドキュメントに基づかせます。権威あるソースに裏付けられた、時代遅れのパターンがないコードを求めるときに使用します。正確性が重要なフレームワークやライブラリで構築する際に使用します。

コーディング前に仕様を作成します。新しいプロジェクト、機能、または重要な変更を開始する際で、まだ仕様が存在しない場合に使用します。要件が不明確、曖昧、または漠然としたアイデアとしてしか存在しない場合に使用します。

テスト駆動で開発を推進します。ロジックの実装、バグ修正、動作変更の際に使用します。コードが正しく動作することを証明する必要がある場合、バグ報告が届いた場合、既存機能を変更しようとする場合に使用します。

エージェントスキルを発見し、呼び出します。セッション開始時や、現在のタスクにどのスキルが適用されるかを発見する必要がある場合に使用します。これは、他のすべてのスキルがどのように発見され、呼び出されるかを管理するメタスキルです。

パフォーマンス、アクセシビリティ、SEO、ベストプラクティスを網羅した包括的なウェブ品質監査。「サイトを監査して」「ウェブ品質をレビューして」「Lighthouse監査を実行して」「ページ品質をチェックして」「ウェブサイトを最適化して」と依頼された場合に使用します。