writing-specs-designs
効果的な仕様書や設計ドキュメントの作成を支援します。技術仕様書・機能仕様書・設計ドキュメントの作成時、またはプロダクト要件をエンジニアリングやデザインチームに伝える必要がある場面で活用してください。
description の原文を見る
Help users write effective specs and design documents. Use when someone is creating technical specs, feature specs, design docs, or trying to communicate product requirements to engineering and design teams.
SKILL.md 本文
仕様書とデザインドキュメントの作成
7人のプロダクトリーダーのフレームワークと知見を活用して、効果的な仕様書とデザインドキュメントの作成を支援します。
サポート方法
ユーザーが仕様書とデザインドキュメントのサポートを求めた場合:
- 忠実度レベルを決定する - チーム間のアライメント(ロー・フィデリティ)が必要か、詳細な実装ガイダンス(ハイ・フィデリティ)が必要かを確認する
- 完成度より試作を推奨する - 静的なドキュメントではなく、機能的なプロトタイプへの移行を促す
- 動く部品に焦点を当てる - 主要なアフォーダンス、接続関係、システム動作を特定するのをサポート
- 長期的な影響を検討する - 一時的な妥協案がしばしば永続的な設計決定となることを想起させる
コア原則
ロー・フィデリティスケッチはコラボレーションを促進する
Christina Wodtke: 「ホワイトボードに下手に絵を描くと、誰かが『ダメだ、そうじゃない。ペンをよこせ』と言ってくる。これで共通ビジョンに非常に早くたどり着ける」。下手に描くことで、参加と修正が促され、アライメントが加速します。
よく形作られた仕様は過度な指定を避けながら明確にする
Ryan Singer: 「シェーピングセッションの成果は、エンジニア、プロダクト、デザインがみんな『これを何を作ればいいか正確に分かった』と言う図や図表。」UI詳細を指定せずに、チームが「壁の中の電気の流れ」を見られるレベルの詳細さを目指してください。
プロトタイプでプロダクトを感じる
Tamar Yehoshua: 「これが機能するかどうかは言えません。感じなければならない。試してみなければならない。モックアップではどのように感じるかは分かりません」。実際のデータを使ったプロトタイプを、静的なスクリーンショットではなく作成するよう促してください。
静的なモックではなくコードプロトタイプを使う
Noah Weiss: 「我々は静的モックの設計探索に時間をかけるのをやめ、『どのくらい早く本物のソフトウェアでプロトタイピングをできるか。たとえそれが雑で使い捨てでも』と言った」。可能な限り早く実際のソフトウェアプロトタイプに移行してください。
プロダクトはピクセルの中に生きている
Nikita Bier: 「階層構造、ピクセル、フロー、すべてを設計すべきです。プロダクトはピクセルの中に生き死にします」。ゼロ・トゥ・ワンプロダクトの場合、粒度の細かい設計詳細に責任を持ってください。すべてのタップが重要です。
すべてのタップを最適化する
Nikita Bier: 「モバイルアプリのすべてのタップは奇跡です。ユーザーはすぐに次のアプリに切り替えてしまいます」。極めて効率的に設計してください。各インタラクションは即座に価値を提供する必要があります。
太いマーカースケッチを使う
Ryan Singer: 「ブレッドボーディングと太いマーカースケッチを使ってください。このボタンを押して、ここに行き、この計算が実行され、その答えを得ます」。太いマーカーは色や間隔などのUI詳細に取り込まれるのを防ぎます。
近道は永続的になる
Tom Conrad: 「一時的な設計上の近道は、複数の技術的書き直しを通じて存続する永続的なプロダクトレガシーになることが多い」。初期実装の詳細が長期的なユーザー期待を定義する可能性があることに注意してください。
PMはスケッチを学ぶべき
Ravi Mehta: 「スケッチを学び、Balsamiqを学んでください。UIとUXがどのように機能するかについて、概念的レベルで考える能力を持つことはPMにとって重要な部分です」。概念的なワイヤーフレーム作成の自給自足力を開発してください。
ユーザーを支援する質問
- 「チーム間のアライメント(ロー・フィデリティスケッチ)が必要ですか、それとも実装ガイダンス(ハイ・フィデリティ仕様)が必要ですか?」
- 「これをドキュメント化する代わりにプロトタイプできませんか?」
- 「このソリューションの動く部品は10個以下は何ですか?」
- 「このデザインをステークホルダーではなく、実際のユーザーでテストしましたか?」
- 「どのような一時的な近道が永続的な決定になる可能性がありますか?」
- 「このフロー内のすべてのタップはユーザーに明確な価値を提供していますか?」
よくある誤りフラグ
- 過度に指定されたワイヤーフレーム - ハイ・フィデリティモックアップはコラボレーションを遅くする可能性があります。太いマーカースケッチから始めてください
- 複雑なインタラクションの静的モック - スクリーンショットではなく、実際のプロトタイプで感覚をテストしてください
- ピクセルレベルの詳細を無視する - コンシューマープロダクトの場合、すべてのタップとトランジションが重要です
- 誰も読まない仕様書 - エンジニアがドキュメントを使用していない場合、それはフォーマットまたは忠実度が間違っています
- 存続する一時的な決定 - 初期の近道が数十年続く可能性があることを認識してください
深掘り
7人のゲストからのすべての10の知見については、references/guest-insights.mdを参照してください
関連スキル
- PRDの作成
- ユーザビリティテスト
- ステークホルダーアライメント
- プロダクト出荷
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- refoundai
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/refoundai/lenny-skills / ライセンス: MIT
関連スキル
nano-banana-2
inference.sh CLIを通じてGoogle Gemini 3.1 Flash Image Preview（Nano Banana 2）で画像を生成します。テキストから画像を生成する機能、画像編集、最大14枚の複数画像入力、Google Searchグラウンディング機能に対応しています。トリガーワード：「nano banana 2」「nanobanana 2」「gemini 3.1 flash image」「gemini 3 1 flash image preview」「google image generation」
octocode-slides
洗練されたマルチファイル形式のHTMLプレゼンテーションを生成します。6段階のフロー（概要 → リサーチ → アウトライン → デザイン → 実装 → レビュー）で構成されています。各スライドは独立したHTMLファイルとなり、iframeで読み込まれます。「スライドを作成してほしい」「プレゼンテーションを作ってほしい」「HTMLスライドを生成してほしい」「デックを構築してほしい」といった依頼や、ノート・ドキュメント・コードを洗練されたプレゼンテーションに変換する際に使用できます。
gpt-image2-ppt
OpenAIのgpt-image-2を使用して、視覚的に優れたPPTスライドを生成します。Spatial Glass、Tech Blue、Editorial Monoなど10種類のキュレーション済みスタイルに対応し、ユーザーが提供したPPTXファイルを模倣するテンプレートクローンモードも搭載しています。HTMLビューアと16:9形式のPPTXファイルを出力します。プレゼンテーション、スライド、ピッチデック、投資家向けPPT、雑誌風PPTの作成依頼などで活用してください。
nano-banana
Nano Banana PRO（Gemini 3 Pro Image）およびNano Banana（Gemini 2.5 Flash Image）を使用したAI画像生成機能です。以下の場合に活用できます：（1）テキストプロンプトからの画像生成、（2）既存画像の編集、（3）インフォグラフィックス、ロゴ、商品写真、ステッカーなどのプロフェッショナルなビジュアルアセット制作、（4）複数画像での人物キャラクターの一貫性保持、（5）正確なテキスト描画を含む画像生成、（6）AI生成ビジュアルが必要なあらゆるタスク。「画像を生成」「画像を作成」「写真を作る」「ロゴをデザイン」「インフォグラフィックスを作成」「AI画像」「nano banana」またはその他の画像生成リクエストをトリガーとして機能します。
oiloil-ui-ux-guide
モダンでクリーンなUI/UXガイダンス・レビュースキルです。新機能や既存システム（Webアプリ）に対して、実行可能なUI/UX改善提案、デザイン原則、デザインレビューチェックリストが必要な場合に活用できます。CRAP（コントラスト・反復・配置・近接）をベースに、タスクファーストなUX、情報設計、フィードバック・システムステータス、一貫性、affordances、エラー防止・復旧、認知負荷を重視します。モダンミニマルスタイル（クリーン・余白・タイポグラフィ主導）を強制し、不要なテキストを削減、アイコンとしての絵文字を禁止し、統一されたアイコンセットから直感的で洗練されたアイコンを推奨します。
axiom-hig-ref
Apple Human Interface Guidelines リファレンス — 色（セマンティックカラー、カスタムカラー、パターン）、背景（マテリアル階層、ダイナミック背景）、タイポグラフィ（標準スタイル、カスタムフォント、Dynamic Type）、SF Symbols（レンダリングモード、色、多言語対応）、ダークモード、アクセシビリティ、プラットフォーム固有の考慮事項を網羅したガイドラインです。