melech-idea-to-canvas

@ を、チームがこれをどう構築するかをすばやく理解し、認識をそろえられる、独立した Cursor Canvas に変換してください。

どのような出発点でも受け付けます。大まかなアイデア、ふと思いついたこと、Slack スレッドの抜粋、会議メモ、決定事項の記録、プロダクト概要、PRD の一部、設計ドキュメント、RFC、技術仕様などです。入力の構成が整っていないほど、スキル側で構成を整える必要があります。

これは主に知識を共有するための成果物です。承認ワークフローでも、議論の場でも、入力を読みやすく書き直したものでもありません。

主な目的： 作成者が知っていることを、重要な意味、決定事項、制約、実装の方向性を損なうことなく、チームができる限り簡単に理解できるようにしてください。

Canvas を作成する前に、次の点を特定してください。

• 問題と、それが重要である理由
• 目指す成果
• 中核となるメンタルモデル
• 提案するシステムと、各部分の連携方法
• 主要なフロー、状態、境界、責任範囲
• 重要な決定事項と、その理由
• 制約、リスク、前提条件、明示的な対象外事項
• 実装の順序と、各チームまたはコンポーネントの担当範囲
• 認識合わせに必要な詳細と、段階的に開示できる詳細

入力が粗い、または構成が整っていない場合は、不足を補うために妥当な推論を行い、推論または仮定であることを明確に示してください。また、Canvas によって明らかになった、作成者が考慮していない可能性のある点も提示してください。

プレゼンテーションの原則：

• シンプルさを重視してください。入力をセクションごとに再現しないでください。
• 説明するより、見せることを優先してください。成果物は、図の入ったドキュメントではなく、インフォグラフィックの集まりとして読めるものにしてください。
• ビジュアルだけでは意味を伝えられない場合に限り、短く直接的なテキストを使ってください。
• 情報を、それぞれ単独でも理解できるビューに分けてください。
• 強い階層構造を設けてください。まず不可欠な理解を示し、その後に実装の詳細を示します。
• 5～10 分で理解できるようにしつつ、必要に応じてさらに詳しく確認できるようにしてください。
• 重要な決定事項が常に見えるようにしてください。
• 細かな仕組みや網羅的な詳細は、折りたたみ可能なセクションか、簡潔な技術付録にまとめてください。
• 不確実性、重要なトレードオフ、依存関係、未解決のリスクを隠さないでください。
• すべての詳細を同じ視覚的な重みで扱わないでください。
• 装飾的なグラフ、汎用カード、根拠のない数値、何も説明しないビジュアルを加えないでください。
• 承認、承認状況、関係者間の議論、ガバナンスを過度に強調しないでください。

視覚的な密度：

• 情報が詰め込まれた領域やテキスト量の多い領域は欠陥として扱ってください。密度が高いということは、そこにふさわしいビジュアルが欠けているということです。
• 密度の高いブロックには、すでに形が含まれています。連続、漏斗、分岐、合流、タイミングの競合、境界などです。その形を見つけ、文章で説明するのではなく、空間的に表現してください。
• 各セルが文章になっている表は、グリッドに入った文章であり、ビジュアルではありません。
• テキストとビジュアルは互いに補完し合う必要があります。周囲のテキストがビジュアルの内容を言い換えている場合は、そのテキストを削除してください。
• 利用可能な既成コンポーネントによって、描けるものを制限しないでください。組み込みの部品ではテキストを箱に入れるだけになってしまう場合は、アイデアに本当に必要な配置を組み立ててください。

図：

• 文章より速く、または明確に要点を伝えられる場合は、図を使ってください。
• 図は装飾ではなく、説明のためのツールとして扱ってください。
• 関係性、フロー、境界、状態、タイミング、責任範囲、因果関係を説明するために使ってください。
• 図でアイデアを伝えられる場合は、補足テキストを最小限にしてください。
• すべての図が具体的な疑問に答え、説明がなくても理解できるようにしてください。
• 文章や短い箇条書きのほうが明確な場合は、無理にビジュアルを使わないでください。

アイデアの理解に本当に役立つビジュアル表現だけを選んでください。たとえば次のようなものです。

• システムまたはコンポーネントのマップ
• ユーザーからシステムまでのジャーニー
• シーケンス図またはデータフロー図
• ライフサイクルまたは状態モデル
• 責任範囲と所有権の境界
• 段階的な実装計画
• 重要なトレードオフに焦点を当てた比較 提案する構成：

1. 構築するものとその理由
2. 1分で把握できるメンタルモデル
3. システム全体の仕組み
4. 主な構成要素とそれぞれの役割
5. 重要なフロー、状態、エッジケース
6. 実装を形作る意思決定
7. 構築と段階的な展開の方法
8. リスク、前提、意図的に先送りした詳細
9. 詳細を必要とする読者向けの簡潔な技術リファレンス

正確性に関する要件：

• 原文の意図を保ってください。
• 合理的に推測できる範囲を超えて、要件、決定事項、確実性を作り出さないでください。
• 決定済み、仮定、提案、未解決の項目を明確に区別してください。
• 原文の重要な用語を保ってください。
• 入力に矛盾や不足がある場合は、キャンバスをレビュー報告に変えることなく、控えめかつ正確に示してください。

キャンバスに関する要件：

• Cursor Canvas スキルを使用して、実際の.canvas.tsxアーティファクトを作成してください。
• 元の入力が手元になくても、単独で役立つものにしてください。
• 視覚的な階層を明確にし、構成に変化をつけてください。同じカードが並ぶだけのものにしないでください。
• 二次的な詳細は、必要に応じて表示する構成にしてください。
• すべてのビューに目的を持たせ、ひと目で把握できるようにしてください。
• プレースホルダーや空のセクションを含めないでください。
• 完成前に、理解や実装の認識合わせに役立たないものをすべて取り除いてください。

最終確認： 各セクションについて、次の点を確認してください。

1. 読者がここで理解すべきことは何ですか？
2. 文章よりも明確に示す方法はありますか？
3. 意味を損なわずに削除できるものは何ですか？
4. まだ文章が中心なら、どのような図や構成が適しているでしょうか？