product-designer

プロダクトデザイナーのスキル

このスキルでできること

機能の構築をエンドツーエンドで行い、課金ロジック、UI/UX デザイン、pgboss を使った定期課金ロジックにも対応します。

ASCII で UI のデザインを描きます。 Linear/Stripe に匹敵する最高水準の UI/UX を実現します。既存のコンポーネントやデザインレイアウトを再利用し、該当する箇所では既存の deploy claw agent モーダルと deploy production hosting モーダルをそのまま踏襲します。体験全体をスムーズにします。フロー全体におけるユーザーのニーズとユーザーストーリーをすべて考慮します。まずユーザーニーズと、それを満たすすべての画面やフローを列挙してから、ASCII でデザインします。既存のフレームワークやナビゲーションロジックに合った、ブランドに沿う Linear/Stripe/Vercel スタイルの最高水準の UI/UX になるまで反復します。その後、ユーザーに提示します。

まずコードベースを調べ、関連するファイルと既存のロジックフローをすべて把握します。フロントエンド、バックエンド、インフラを含むすべてを対象とします。 次に、askUserQuestions ツールを使って、重要な質問をユーザーに確認します。

最後に、機能名（kebab case）に基づき、既存または新規の .todo/[feat-name]/PRD.md ファイルに書き込みます。

---

ワークフロー

フェーズ 1：コードベースの調査

並列サブエージェントを使って、フロントエンド、バックエンド、インフラを同時に調査します。

• 機能に最も近い既存のモーダル、フロー、コンポーネントを探します
• 既存の課金処理、pgboss のジョブパターン、API 構造を特定します
• ナビゲーションパターン、レイアウトコンポーネント、使用中のデザインシステムのトークンを確認します
• 再利用できる関連ロジックを探します

確認する主な場所：

• src/components/ — 既存のモーダル、ダイアログ、UI プリミティブ
• src/app/api/ — 既存の API ルートとパターン
• src/lib/ — 課金、ジョブ、ビジネスロジックのユーティリティ
• blink-apis/ — バックエンドサービスのパターン
• .todo/ — 既存の PRD や TODO のコンテキスト

フェーズ 2：ユーザーニーズとストーリーの列挙

デザインに入る前に、以下を列挙します。

USER NEEDS:
1. [Primary need — the "why" behind this feature]
2. [Secondary need — what else supports their goal]
3. ...

USER STORIES:
- As a [persona], I want to [action] so that [outcome]
- As a [persona], I want to [action] so that [outcome]
- ...

SCREENS & FLOWS:
1. [Screen name] — [what it does, which user story it serves]
2. [Screen name] — [what it does, which user story it serves]
3. ...

フェーズ 3：認識合わせの質問

デザインの前に askUserQuestions ツールを使い、重要な設計上の判断を明確にします。以下に重点を置きます。

• スコープ（v1 に含めるもの／含めないもの）
• 課金モデルの詳細（該当する場合）
• 対象となるペルソナやエッジケース
• 厳密に踏襲、または避けるべき既存の UX パターン
• 時間に制約がある場合の画面の優先順位

フェーズ 4：ASCII プロトタイプ

すべての画面と状態を ASCII でデザインします。最高水準の品質になるまで反復します。

デザイン基準：

• Linear/Stripe/Vercel の美学に合わせます。すっきりとしたミニマルなデザインで、情報密度を高めます
• 既存のモーダルシェル、ボタンスタイル、レイアウトプリミティブをそのまま再利用します
• 空、読み込み中、エラー、成功、エッジケースなど、すべての状態を示します
• 意味がある箇所では、ホバー、フォーカス、アクティブ状態を示します

ASCII の形式規則：

┌─────────────────────────────────────────┐
│ Modal Title                         [X] │
├─────────────────────────────────────────┤
│                                         │
│  Section header                         │
│  ┌───────────────────────────────────┐  │
│  │ Input field               [icon]  │  │
│  └───────────────────────────────────┘  │
│                                         │
│  [Secondary action]     [Primary CTA →] │
└─────────────────────────────────────────┘

画面をつないで、フロー全体をデザインします。

[Screen A] ──→ [Screen B] ──→ [Screen C: Success]
                    │
                    └──→ [Screen B2: Error state]

フェーズ 5：PRD の作成

最終的なデザインを .todo/[feat-name]/PRD.md に記述します。

# [Feature Name] PRD

## Overview
[1-2 sentence summary]

## User Needs
[List from Phase 2]

## User Stories
[List from Phase 2]

## Screens & Flows
[List with descriptions]

## ASCII Designs
[All ASCII prototypes from Phase 4]

## Component Reuse
[Which existing components/modals/patterns to reuse]

## API & Backend
[Required endpoints, pgboss jobs, billing logic]

## Open Questions
[Unresolved decisions or edge cases]

---

品質基準

提示する前に、以下を自己チェックします。

• すべてのユーザーストーリーに対応する画面／フローがある
• 空、読み込み中、エラーの各状態がデザインされている
• 既存のコンポーネントを再設計するのではなく、明示的に再利用している
• 該当する場合、課金／定期処理のロジックがすべて整理されている
• ASCII デザインが等幅フォントで表示したときに見やすい
• PRD が .todo/[feat-name]/PRD.md に作成・保存されている