compound-engineering

agent-browserを使用して現在のPRまたはブランチで影響を受けるページでブラウザテストを実行する

最近のmainブランチへのマージに対する魅力的な変更ログを作成する

各セクションに対して並列リサーチエージェントを使用し、深度、ベストプラクティス、実装詳細を追加してプランを強化する

スキルに間違った指示や古いAPI参照がある場合に、不正なSKILL.mdファイルを修正する

複数の専門エージェントにプランを並列でレビューさせる

UIの実装がFigmaのデザイン仕様に一致しているか確認する必要がある場合にこのエージェントを使用します。このエージェントはデザインを実装するコードが書かれた後、特にHTML/CSS/Reactコンポーネントが作成または変更された後に呼び出すべきです。エージェントはライブ実装とFigmaデザインを視覚的に比較し、不一致について詳細なフィードバックを提供します。 例: - <example> コンテキスト: ユーザーがFigmaデザインに基づいて新しいコンポーネントを実装したところ。 ユーザー: "Figmaデザインに基づいてヒーローセクションの実装を完了しました" アシスタント: "実装がFigmaデザインにどれだけ一致しているかレビューします。" <commentary> UI実装が完了したので、design-implementation-reviewerエージェントを使用してライブバージョンとFigmaを比較します。 </commentary> </example> - <example> コンテキスト: 汎用コードエージェントがデザイン変更を実装した後。 ユーザー: "新しいデザインシステムに合わせてボタンスタイルを更新して" アシスタント: "ボタンスタイルを更新しました。実装がFigma仕様に一致しているか確認しましょう。" <commentary> デザイン変更を実装した後、proactiveにdesign-implementation-reviewerを使用して正確性を確保します。 </commentary> </example>

デザイン作業が最初の試みでうまくいかない場合にPROACTIVEにこのエージェントを使用します。1-2回のデザイン変更を行っても結果がまだ違和感がある場合、より深い改良のために5倍または10倍のイテレーションでこのエージェントを使用することを提案してください。このエージェントはスクリーンショットを撮り、何がうまくいっていないか分析し、改善を実装し、N回繰り返してデザインの問題を体系的に修正します。色が間違っている、レイアウトがバランスを欠いている、または単一の変更では達成できない全体的な美的感覚が必要な場合に最適です。<example>コンテキスト: ユーザーがボタンの色を変更するよう依頼したが、結果がまだ違和感がある。ユーザー: "ボタンを青に変更して" アシスタント: [変更を行い、スクリーンショットを撮る] "ボタンが青になりましたが、全体的なカラーバランスがまだ違和感があります。design-iteratorエージェントを5回のイテレーションで使用して、カラーハーモニーとビジュアルバランスを体系的に改善しますか？" <commentary>PROACTIVE使用: 単純な変更でデザインの問題が完全に解決しない場合、より深い作業のためにdesign-iteratorを提案します。</commentary></example> <example>コンテキスト: ユーザーのデザインリクエストが見た目が良くないものになった。ユーザー: "ヒーローセクションをもっとモダンにして" アシスタント: [初期変更を行う] "モダンな要素を追加しましたが、結果がまとまっていません。これは反復的な改良が必要そうです。design-iteratorエージェントを10回のイテレーションで使用して、タイポグラフィ、間隔、色、ビジュアル階層を磨き上げるまで体系的に改善させてください。" <commentary>PROACTIVE使用: 初期のデザイン作業が平凡な結果を生んだ場合、包括的な改善のためにdesign-iteratorを自動的に提案または使用します。</commentary></example> <example>コンテキスト: ユーザーが明示的に反復的な改良を望んでいる。ユーザー: "機能セクションがつまらない、10回イテレートして" アシスタント: "design-iteratorエージェントを使用して、機能セクションを10回のビジュアル改善のイテレーションで体系的に改良します" <commentary>ユーザーが明示的にイテレーションを要求したので、design-iteratorを直接使用します。</commentary></example> <example>コンテキスト: デザインタスクにリサーチと複数回のパスが必要。ユーザー: "Stripeの料金ページを見て、私のをより良くして" アシスタント: "design-iteratorエージェントを8回のイテレーションで起動して、Stripeのデザインパターンをリサーチし、その洞察を料金ページに段階的に適用します" <commentary>競合リサーチと反復的な改良の組み合わせは、体系的なアプローチの恩恵を受けます。</commentary></example>

Web実装をFigmaデザインと自動的に視覚的な差異を検出・修正して同期させる必要がある場合にこのエージェントを使用します。このエージェントは実装がデザインと一致するまで反復的に使用すべきです。 <example> コンテキスト: ユーザーが新しいコンポーネントを実装し、Figmaデザインと一致しているか確認したい。 ユーザー: "ヒーローセクションコンポーネントの実装が完了しました。Figmaデザインと一致しているか確認できますか？ https://figma.com/file/abc123/design?node-id=45:678" アシスタント: "figma-design-syncエージェントを使用して、実装とFigmaデザインを比較し、差異を修正します。" <figma-design-syncエージェントをFigma URLとローカルURLで起動するためにTaskツールを使用> </example> <example> コンテキスト: ユーザーがレスポンシブデザインに取り組んでおり、モバイルブレークポイントがデザインと一致しているか確認したい。 ユーザー: "モバイルビューが正しく見えません。Figmaはこちら：https://figma.com/file/xyz789/mobile?node-id=12:34" アシスタント: "figma-design-syncエージェントを使用して差異を特定し修正します。" <figma-design-syncエージェントを起動するためにTaskツールを使用> </example> <example> コンテキスト: 初期修正後、ユーザーが実装が一致しているか確認したい。 ユーザー: "ボタンコンポーネントが今デザインと一致しているか確認できますか？" アシスタント: "figma-design-syncエージェントを再度実行して、実装がFigmaデザインと一致していることを確認します。" <確認のためにfigma-design-syncエージェントを起動するためにTaskツールを使用> </example> <example> コンテキスト: ユーザーが開発中にproactiveにデザインの不一致を言及。 ユーザー: "ナビゲーションバーに取り組んでいますが、スペーシングが正しいかわかりません。" アシスタント: "figma-design-syncエージェントを使用して、実装とFigmaデザインを比較し、スペーシングやその他の視覚的な差異を特定します。" <figma-design-syncエージェントを起動するためにTaskツールを使用> </example>

任意のテクノロジー、フレームワーク、開発プラクティスに関する外部のベストプラクティス、ドキュメント、例をリサーチして収集する必要がある場合にこのエージェントを使用します。これには公式ドキュメント、コミュニティ標準、オープンソースプロジェクトからの評判の良い例、ドメイン固有の規約を見つけることが含まれます。このエージェントは、業界標準に従って機能を実装したり問題を解決する方法について包括的なガイダンスを提供するために、複数のソースからの情報を統合することに優れています。<example>コンテキスト: ユーザーがRailsプロジェクトのGitHub issueの構造化のベストな方法を知りたい。ユーザー: "プロジェクト用にGitHub issueを作成する必要があります。良いissueを書くためのベストプラクティスをリサーチしてもらえますか？" アシスタント: "best-practices-researcherエージェントを使用して、成功したプロジェクトからの例やRails固有の規約を含む、GitHub issueのベストプラクティスに関する包括的な情報を収集します。" <commentary>ユーザーがベストプラクティスに関するリサーチを求めているので、best-practices-researcherエージェントを使用して外部のドキュメントと例を収集します。</commentary></example> <example>コンテキスト: ユーザーが新しい認証システムを実装しており、セキュリティのベストプラクティスに従いたい。ユーザー: "Rails APIにJWT認証を追加しています。現在のベストプラクティスは何ですか？" アシスタント: "best-practices-researcherエージェントを使用して、現在のJWT認証のベストプラクティス、セキュリティの考慮事項、Rails固有の実装パターンをリサーチします。" <commentary>ユーザーは特定のテクノロジー実装のベストプラクティスに関するリサーチを必要としているので、best-practices-researcherエージェントが適切です。</commentary></example>

プロジェクト内のフレームワーク、ライブラリ、または依存関係に関する包括的なドキュメントとベストプラクティスを収集する必要がある場合にこのエージェントを使用します。これには公式ドキュメントの取得、ソースコードの探索、バージョン固有の制約の特定、実装パターンの理解が含まれます。<example>コンテキスト: ユーザーが特定のライブラリを使用して新機能を適切に実装する方法を理解する必要がある。ユーザー: "Active Storageを使用してファイルアップロードを実装する必要があります" アシスタント: "framework-docs-researcherエージェントを使用してActive Storageに関する包括的なドキュメントを収集します" <commentary>ユーザーがフレームワーク/ライブラリ機能を理解する必要があるので、framework-docs-researcherエージェントを使用してすべての関連ドキュメントとベストプラクティスを収集します。</commentary></example> <example>コンテキスト: ユーザーがgemの問題をトラブルシューティング中。ユーザー: "turbo-rails gemが期待通りに動作しないのはなぜですか？" アシスタント: "framework-docs-researcherエージェントを使用してturbo-railsのドキュメントとソースコードを調査します" <commentary>ユーザーがライブラリの動作を理解する必要があるので、framework-docs-researcherエージェントを使用してドキュメントを収集し、gemのソースを探索すべきです。</commentary></example>

Automates browser interactions for web testing, form filling, screenshots, and data extraction. Use when the user needs to navigate websites, interact with web pages, fill forms, take screenshots, test web applications, or extract information from web pages.

このスキルは、機能がコードではなくプロンプトで定義されるプロンプトネイティブアーキテクチャを使用してAIエージェントを構築する際に使用されるべきです。自律エージェントの作成、MCPサーバーの設計、自己修正システムの実装、または「エージェントの知性を信頼する」哲学を採用する際に使用してください。

Capture solved problems as categorized documentation with YAML frontmatter for fast lookup

Claude Code スキルの作成、執筆、洗練に関するエキスパートガイダンス。SKILL.mdファイルでの作業、新しいスキルの作成、既存スキルの改善、またはスキル構造とベストプラクティスの理解に使用します。

このスキルは、DHHの独特な37signalsスタイルでRubyおよびRailsコードを書く際に使用されるべきです。Rubyコード、Railsアプリケーションの作成、モデル、コントローラー、または任意のRubyファイルの作成時に適用されます。Ruby/Railsコード生成、リファクタリングリクエスト、コードレビュー、またはユーザーがDHH、37signals、Basecamp、HEY、Campfireスタイルに言及した場合にトリガーされます。RESTの純粋性、ファットモデル、薄いコントローラー、Current属性、Hotwireパターン、そして「賢さより明確さ」の哲学を体現します。