Communitygithub.com

Pure-Water-Automations/agent-skills

ユーザーが競合製品から学んでアプリの機能を改善・再設計したい場合に使用します。「Loom/Notion/Linear のやり方を見て」「エージェントを起動して自社と競合のスクリーンショットを撮って」「X について他のアプリから学べることは?」「自社のX をY とベンチマークして」「X の構成をどう改善できるか」といったリクエストに対応。特に、改善案のビフォー/アフター(現行 UI と再設計案を並べて差分をハイライト)を実際に「見られる」状態で提案します。

agent-skills とは?

このスキル(Pure-Water-Automations/agent-skills)は、AI エージェント(Claude Code 等)向けに設計された競合再設計ワークフローです。ユーザーが自社アプリの特定機能について「競合製品(Loom, Notion, Linear など)はどうやっているか」と尋ねたとき、フェーズ1 で最大 3 つの並列サブエージェントを起動し、Playwright MCP を使って自社機能と競合 2~3 製品のスクリーンショットを取得します。同時にメインスレッドでコードベースを読み込み、現状のスキーマ・アクション層・ページを把握します。フェーズ2 では収集結果をギャップ分析としてユーザーに提示し、複数選択式の意思決定をまとめて求めます。決定後は Claude Design キャンバスを利用して、現行 UI のスクリーンショットと再設計アートボードを並べた比較デザインを生成。すべての変更箇所にはアクセントカラーの破線枠と「NEW」バッジが付与されます。ユーザーが希望すれば、実装計画(superpowers:writing-plans サブスキル利用)も作成可能です。製品コードそのものは一切書き換えず、意思決定+デザイン+(オプションで)計画のみを成果物とします。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Pure-Water-Automations/agent-skills/tree/HEAD/competitive-redesign

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

競合再設計 (Competitive Redesign)

この SKILL.md と同じ場所に LOCAL.md が存在する場合は、先にそれを読んでください。このワークスペース固有のパス、ツール、サンプルが記載されており、以下の汎用デフォルト設定よりも優先されます。

調査 → 決定 → デザイン。並列サブエージェントが自社機能と 2~3 の競合製品のスクリーンショットを取得し、その結果をギャップ分析としてユーザーに一括決定を求めます。選ばれた方向性に基づき、現行 UI のスクリーンショットと、すべての差分がマークされた再設計アートボードを並べたデザインキャンバスを出力します。成果物は「決定 + デザイン」(+ オプションの実装計画)であり、このスキル自体は製品コードを一切書き換えません。

後述の「参考実行」は、このスキルの初回実実行(録画ライブラリの再設計)を指します。LOCAL.md がある場合はそれを参照します。あくまでも動作例であり、形状と深さの調整を確認するためのものです。新しい機能の内容を調査する際には参照しないでください。

フェーズ 1 — 並列調査(安価なモデルのサブエージェント、最大 3 並列)

一度のメッセージで最大 3 つのサブエージェントを起動します(Agent ツール、general-purpose、model: "sonnet"。単純な調査には安価なモデルで十分です。同時実行は 3 つまで — レート制限により大量起動は失敗します)。

  1. 自社 — 自社アプリの該当機能をスクリーンショット撮影。
  2. + 3. 競合 — ユーザーが名前を挙げた製品をこのスロットに割り当て、各エージェントが担当します。残りのスロット(ユーザーが 0 または 1 つしか名前を挙げなかった場合)は「サーベイ」エージェントが担当し、該当機能領域の公開ドキュメントが最も充実している競合 2~3 製品を選びます。ユーザーが 3 つ以上名前を挙げた場合は、1 つのエージェントにプライマリ製品を、別のエージェントに残りをまとめて割り当てます。

サブエージェントの実行中、メインスレッドでコードベース(該当機能のスキーマ、読み取り/アクション層、ページ)を読み込み、理解を深めてください。推奨事項は実際のフィールド(例:「project タグは存在するが UI では公開されていない」)にマッピング可能でなければなりません。コードベースを踏まえずに競合調査だけを行うと、誰も実装できない願望リストになってしまいます。

サブエージェントへの指示 — 省略すると失敗するポイント:

  • Playwright MCP のみ使用し、ブラウザペインは使わない — ブラウザペインのスクリーンショットはディスクに保存できず、オーケストレーターからも見えません。エージェントに明示的に指示:mcp__playwright__playwright_screenshot を使用し、savePng: true、downloadsDir はエージェントごとのスクラッチパッドサブディレクトリ(ours/、loom/、competitors/)に設定、事前に mkdir -p を実行し、ls で確認した絶対パスを報告させること。
  • 並列エージェントは Playwright ブラウザを共有するため、セッションがクロスコンタミネーションする(あるエージェントが別のエージェントのページをスクリーンショットする — 参考実行で実際に発生)。すべてのエージェントに指示:各スクリーンショットが、自分が移動した URL と視覚的に一致することを確認してから保存すること。古い/他エージェントの画像をキャプチャしてしまった場合は、Playwright ブラウザを閉じて開き直し、再取得すること。
  • Playwright chromium が見つからない場合がある(「Executable doesn't exist …」)。MCP の npx キャッシュディレクトリから npx playwright install chromium を実行してから続行します(既知の恒常的な問題で、バージョンアップ後も発生します)。
  • 自社アプリのログイン:エージェントに正確なレシピを伝えてください。例:開発専用ログインフォーム(/login でメールアドレス+パスワード)を使用し、メールアドレスは開発データベースにアクティブユーザーとして存在するもの、パスワードは開発サーバーの環境変数から取得したものを使用します。エージェントを起動する前に、ご自身で開発サーバーの環境変数値を読み、開発 DB にアクティブユーザーがいることを確認してください。参考実行では、開発 DB に存在しないメールアドレスを使ったために CredentialsSignin エラーでエージェントが丸々一個無駄になりました。該当アプリの開発用認証パスは AGENTS.md / README で確認してください。エージェントを本番環境に向けてはいけません。
  • 競合製品のライブラリはログインの背後にある場合が多い — エージェントには、ヘルプセンター記事、マーケティング/機能ページ、ドキュメント(support.loom.com など)を使用するよう指示し、サインアップを試みないでください。構造化された機能一覧(整理/編成、発見/検索、共有、ワークフロー、AI、管理)と、どの機能がコア/人気か vs エンタープライズ限定か、そして「盗む価値のある独自のアイデア」リストを求めます。

フェーズ 2 — 統合 + 一括決定

ユーザーに以下の 1 つのメッセージをまとめて送信します。

  1. 現状 — 自社機能に何があり、何が欠けているかを、スクリーンショットとコード(ファイル名を明記)の両方で確認。
  2. 競合の状況 — 製品ごとに数行、転用可能なポイントのみ。
  3. フェーズごとの推奨事項 — 最もコスト効果の高いものから順に:(a) コードがすでにサポートしている機能を UI で公開、(b) 小規模な移行で実現できる整理機能、(c) ワークフロー機能。ユーザー自身のプロンプトからのアイデアも含めてください。意図的にスキップしたもの(エンタープライズ向け、YAGNI)も明記します。
  4. 一括の多肢選択式決定:成果物に影響を与える 2~4 の分岐点について、選択肢(アルファベット付き)とそれぞれに対する推奨を提示します。質問を小出しにしないでください。

そこで一旦停止し、ユーザーの決定を待ちます。範囲が決まらないままデザインを開始してはいけません。

フェーズ 3 — 選ばれた方向性のデザインキャンバス

必須サブスキル: design スキル(Claude Design キャンバス → アーティファクト)。キャンバスの仕組み自体はこのスキルが担当し、本フェーズでは比較のためのルールを追加します。

  • 現行 UI のスクリーンショットを独立したアートボード(「現状 — X」)として、再設計アートボード(「再設計 — X」)と並べます。スクリーンショットは埋め込む前に約 70~100 KB の JPEG にダウンサンプリングします(sips -Z 900 -s format jpeg -s formatOptions 60 …)。
  • 再設計アートボードはアプリの実際のデザインシステムに合わせる — トークンファイルとコンポーネントを先に読み、正確な値(フォント、カラートークン、カードの角丸、ボタンの形状)をコピーします。
  • すべての差分をマーク:アプリのアクセントカラーの破線のアウトラインと、現状存在しない要素には小さな「NEW」バッジ(変更された要素には「CHANGED」ラベル)を付けます。変更がない領域には装飾を一切付けません — 装飾がないことで、マーカーが読みやすくなります。
  • キャンバスの付箋で、アートボードごとの差分を要約し、概要を 1 つ説明します。モックアップ内のサンプルデータは問題ありませんが、引き継ぎ時にその旨を明記してください。
  • デフォルトの成果物は静的モックアップです。クリック可能なプロトタイプは、ユーザーから明示的に要求された場合のみ作成します。

フェーズ 4(ユーザーから要求があった場合のみ) — 実装計画

必須サブスキル: superpowers:writing-plans。すべてのタスクをフェーズ 1 のコード読み取り結果に基づいて記述し、フェーズごとの範囲と決定事項をそのまま引き継ぎ、最後に実行モードの選択肢(並列ファンアウト / サブエージェント / インライン)を提示します。許可なく実装を開始しないでください。

既知の問題点(すべて参考実行で実際に発生)

症状対策
エージェントがスクリーンショットを報告したが、オーケストレーターから見えないブラウザペインが使用された — 再指示:Playwright MCP の savePng + downloadsDir を使用
スクリーンショットに、エージェントが移動したはずのサイトとは異なるサイトが写っているPlaywright セッションのクロスコンタミネーション — ブラウザを閉じて開き直し、再取得、視覚的に確認
開発ログインで CredentialsSignin エラーメールアドレスが開発 DB のアクティブユーザーではない — 開発 DB を確認し、アクティブユーザーのものを使用
「Executable doesn't exist … chromium」npx playwright install chromium を実行(キャッシュディレクトリごとに、Playwright バージョンアップ後も再実行)
ファンアウトが空の結果を返す、またはレート制限にかかる同時実行エージェントが 3 を超えている — 3 以下の波に分割、失敗したものはリトライ、部分的にでも結果を報告
推奨事項がコードと一致しないフェーズ 1 のメインスレッドによるコードベース把握がスキップされている — 統合前に必ず実施

このスキルの日本語版は、元の英語版 SKILL.md を翻訳したものです。元の内容が優先されるべきですが、この翻訳は実用的な参照として提供されています。

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Pure-Water-Automations/agent-skills

Score any app (the user's own or a competitor's) on a research-backed rubric and produce a reusable, comparable scorecard — 0–5 per dimension with an evidence grade, noncompensatory gates checked first, and one "smallest fix" per weak dimension. Adapts to product stage: a pre-PMF app under ~100 users is scored on 9 dimensions, a growth-stage app on the full 23. Use whenever the user says "score this app", "grade the app", "rate the UI/UX", "how good is [app]", "app scorecard", "run the scorecard on [app]", "how does [app] stack up", "is this ready to launch / promote to prod", or wants a before/after number after a build sprint or a beta round. Reads the codebase + deploy + docs, optionally beta feedback / analytics, and refuses to invent retention, revenue, or PMF from code alone. Outputs a chat table plus a published HTML scorecard artifact. Pairs with ui-usability-audit (UI depth), qa-sweep (functional pass), dev-to-prod-promotion-review (release gate).

Pure-Water-Automations/agent-skills

Use when the user wants a multi-perspective brainstorm on a feature, app, or product area — "spin up agents with different personalities/job titles", "look at it from different angles", "panel of experts", "come up with 30 ideas and a top 5", "how can we make X more useful", "brainstorm what to do next with X" — especially when they also want to DECIDE on the ideas (implement / hold / reject) rather than just read a list. Also use when they ask to re-run or extend a previous panel, or to "make the ideas decidable like dev-to-prod-promotion-review".

関連スキル