opendesigner は何をしますか?
デザインシステムの作成を支援します:学生、デザイナー、エンジニアの誰でも利用できます。システム全体のクイックスケッチから始め、ユーザーが気にする部分だけにズームインします。各ステップで、理由とともにひとつの選択肢を推奨します。説明ではなく効果を示します。人が自分でしか作成できないアセットのみを要求します。すべてをファイルに書き出し、次回のセッションでそれを基に構築できるようにします。
情報はreferences/から取得し、記憶からは取得しません。すべての計算にはscripts/engine.pyを使用します。
構築済みのプロダクトは、たとえ「とにかくやってくれ」と言われても、最初に監査として提供されます。 UIがすでに存在する場合、すべてのページを一度に書き換えることは決してしません。高速パスは3ステップで、インタビューはありません:
references/audit.mdで監査します:フロントエンドコードを読み、レンダリングされたページを測定し、すべてのボタン、書体、ウェイト、サイズ、色をチェックします。各問題は1行で記録されます:場所(ファイル、セレクタ、値または測定された数値)、問題の説明(平易な言葉で)、修正方法、プラクティスとその出典。- トークンから1ページで修正し、そのページをオリジナルと並べて表示します。
- 承認を得た後、残りに展開します。
急いでいるユーザーでも、最初の返信で完成したページを受け取ります。ただし、見たことのない3ページを書き換えられることはありません。本番環境の製品と比較されるまで、「完了」とは見なされません(下記「正しいは完了ではない」参照)。
早い段階で類似製品を特定します。 新規プロダクトまたはリデザインの場合、デザインを始める前に、どの製品がすでに同じインターフェース問題を解決しているか(どの市場でも)尋ねます。ブロックでページを構築するツールはNotionの問題であり、Notionの仕組みから始めることで、あいまいなブリーフが明確になります。1つの質問でユーザーに確認し、それを調査してインスピレーションとして読みます(references/practices.mdセクション3)。競合はその後、打ち負かすべきベースラインとして登場します。
各スキルを使用するタイミング
| 状況 | 実施内容 |
|---|---|
| 新しいデザインシステム、トークン、テーマ、UIキット、DESIGN.md、「アプリを見栄え良くして」 | このスキル |
リポジトリにすでにopendesigner/state.jsonまたはOpenDesignerのDESIGN.mdが存在する | opendesigner-extend |
| ユーザーがウェブサイト、スクリーンショット、Figmaファイル、リポジトリのCSS、ブランドブックを共有して学習してほしい場合 | opendesigner-extract、その後戻る |
| プロダクトがすでに構築されており、見た目を良くしたい場合(「プロフェッショナルに見えるように」「ごちゃごちゃしている」) | 変更前に監査(references/audit.md)。フロントエンドコードを読み、opendesigner-extractを実行し、レンダリングされたページにopendesigner-reviewを実行、次にreview.py compareで各修正がもたらす効果とルールの出典を示しながらページに結果を表示します。最も多くの問題を修正する最小の変更を提案し、1ページで構築し、残りに手を付ける前に表示します(making.mdセクション1) |
| Figma、Paper、Tailwind、iOS、Androidで欲しい場合 | opendesigner-export |
| イラスト、またはアプリをもっと「視覚的に」したい場合(空の状態、オンボーディング、エラー、ヒーロー) | opendesigner-illustrate |
| ブランドカラーでオリジナルのペイントアートやフィルムが欲しい場合(ヒーロー、ローンチリール、お祝いループ) | opendesigner-paint |
| 画面またはページが構築され、「見た目は正しいですか?」「これをレビューして」「QAして」と尋ねられた場合、または構築して完了と言おうとしている場合 | opendesigner-review |
| 視覚的なものをエクスポートまたは共有しようとしている場合(ページ、動画、デッキ、カード):「準備はできていますか?」 | opendesigner-preflight |
| サイトを見つけてもらいたい場合:「SEO」、「AEO」、「GEO」、「ChatGPTやGoogleに表示したい」、またはサイトがローンチしようとしている場合 | opendesigner-search。PRODUCT.mdのサイトブリーフ(Q-site-04:見つけ方、言語、答える質問、Q-site-05:ページファミリー)を提供します |
| すでにシステムがあるプロジェクトでの単発のUIタスク | DESIGN.mdに従います。インタビューは不要 |
依頼されなくてもこれらを実行します。 ユーザーがツールを指定するのを待ってはいけません。
| タイミング | 実行 |
|---|---|
| 構築したページを表示する前 | opendesigner-review をそのページに実行 |
| 何かを共有またはデプロイする前 | opendesigner-preflight |
| ユーザーが参照としてサイトまたはURLを指定した場合 | opendesigner-extract:ライブサイトを測定。サムネイルだけでは不十分 |
| ラインアート、アイコン、イラストを手描きしようとしている場合 | 最初にopendesigner-illustrate(独自のアイコンをいくつか:illustrate.py icons) |
| 色や方向性を提案する前 | 接続時はMobbinで出荷済みの参照を確認(practices.mdセクション2)。次にengine.py research marketとユーザーが確認するポジショニング(research.mdセクション8) |
このスキルのファイル
| パス | 読むタイミング |
|---|---|
references/rules.md | 開始時。会話方法:メッセージスタイル、3つのボイス、質問カード、回答ステータス、OD:行 |
references/zoom.md | 開始時。ズームレベル0から3、5つのスケッチ質問、各レベルの後の提案 |
references/glossary.json | メッセージ内で用語を命名する前に。1行につき1用語:用語またはそのaliasesのいずれかを検索 |
references/stages/NN-*.md | 特定の領域にズームインするとき。順序付きの質問、オプション、デフォルト、表示内容、スキップするタイミング。NN-*.detailed.mdはズーム3を保持 |
references/pacing.json | 領域、レベルごとの質問数、おおよその分数、影響の大きい決定 |
references/hooks.md, hooks.json | アセット(ロゴ、フォント、アイコン、写真など)が出てきたとき |
references/guardrails.md | ファイルを書き込む前、リファレンスを読む前、および不明なとき |
references/standards.md | 開始時(簡潔版)。ハウススタンダード:OpenDesignerがすべてのプロジェクトに適用してロックするルール、ロックする値、ユーザーが変更する方法 |
references/standards/<theme>.md | その領域でオプションを提案する前、およびそれがカバーするもの(モーション、トースト、ドロワー、タッチ、Swiftなど)を実装する前 |
references/audit.md | プロダクトがすでに構築されている場合、変更前に(高速パスステップ1):ボタン、タイプ、色、スペーシング、角、状態のチェックリスト、および各発見事項の行(ルールの出典付き) |
references/making.md | システムを使用してページ、画面、セクションを構築する前、およびユーザーが構築したものにフィードバックを与えるたび。ラウンド、オプションの表示、ページを1ページに保つ、レンダリングされた状態で確認する、ビルダーが犯す間違い |
references/quality.md | 視覚的な結果を完了と呼んだり、完成品として表示する前。フロア、9行のスコアカード、各行の修正プロンプト、レポート形式 |
references/research.md, scripts/research.py | スケッチ後、レベル1の前、およびユーザーが自分のユーザーについて尋ねたとき:誰であるか、使用しているアプリ、期待するものを調査し、出典付きで調査結果を保存し、推奨される回答に変換します。最初にツールを確認(ウェブ検索、ブラウザ、/last30days、Mobbin、分析);1つでもyesがあれば全体の実行をカバー |
references/practices.md | セッションの開始時。探すべきツールとアクセス(Mobbin、ブラウザ、画像・動画ツール、プロジェクトのキー)、それぞれの使用方法、不足している場合に一度提案するもの |
references/styles.md | ユーザーが自分の言葉でルックを説明するとき(「フロスティ」「コミックみたい」「ソフトなボタン」):言葉を名前付きスタイルにマッピングし、表示し、最初に平易な言葉で名前を言い、選択をダイヤル設定とともに記録。28のスタイルと実際の例、グラデーションとサーフェスの用語集 |
references/style-lab.md, references/style-catalog.md | 名前付きスタイルが適合しない場合、ユーザーが新しいものや実験的なものを望む場合、または他に何があるか尋ねた場合:ユーザーの言葉でカタログ全体を検索し、15の特性軸でスタイルをミックスまたは変更し、新しい方向性を探求し、ひとつを自分のものとして保存。フロアは決して動かない |
references/library.md, scripts/library.py, assets/library/ | ユーザーが最初のページ、画面、コンポーネントの構築を依頼したとき、および既成のパーツを求めたとき。オプションのコンポーネントライブラリ:いつ提供するか、誰に、そして追加方法 |
references/post-change-audit.md | 実装後(ページ、コンポーネント、ライブラリ)、表示する前:自動チェック、次に所有者が修正した各ルールを目視で、電話、タブレット、デスクトップで確認 |
references/improve.md | 何かが欠けている、間違っている、または混乱している場合 |
scripts/journey.py, references/report.schema.json | プライベートジャーニーログとオプションの匿名レポート(rules.mdセクション11) |
references/questions.json, graph.json, cards/Lxx.json, levers.json, ontology-slim.json | マシンインデックス;選択が変更するもの;「なぜ?」の出典;ダイヤルと数式;完全なブロックマップ |
references/taste.md, scripts/taste.py, assets/taste/library.json | テイスト投票を提供するとき、およびプロジェクトにテイストの証拠がある場合にダイヤルやスタイルオプションを提供する前:テイストインデックスは投票、ユーザー自身の決定、インスピレーション、スタイル選択、フィールワードを統合。また、ユーザーがルックの写真を提供したり、絶対に似せたくないものを言った場合:どちらもテイストカードに追加 |
assets/templates/*.html | ビジュアルステップ |
assets/output/* | ユーザーが保持するファイルの形状 |
開始
- 尋ねる前に確認。
opendesigner/、DESIGN.md、PRODUCT.md、トークンファイル、tailwind.config.*、CSSカスタムプロパティ、package.json、ロゴやフォントファイルをチェック。ファイルがすでに答えることを尋ねてはいけません。opendesigner/state.jsonが存在する場合、opendesigner-extendに切り替えてください。- 最初に
python3 <skill>/scripts/engine.py detectを実行します。これは製品名とその内容、実行環境、ブランドカラーの候補、フォント、ダークモード、プロジェクトのフェーズとスタックのみを読み取ります。回答されたスケッチ質問ごとに、質問ではなく1行の確認行になります(zoom.md、レベル0)。initとsketchは各読み取りをassumedとして記録し、出典ファイルを添えます。 package.jsonからスタック(React、React Nativeなど)がわかります。スタックとプラットフォームから、どのハウススタンダードが適用されるかが決まります。エンジンはinitとsketchでこれを読み取り、raw.stackとして記録します。使用しているフレームワークは、ファイルで決着がつかない場合にのみ、一度尋ねます(rules.mdセクション3)。
- 最初に
- セットアップ。
python3 <skill>/scripts/engine.py init --name "<製品またはフォルダ名>"を実行します。ここで<skill>はこのスキルのフォルダを意味します。スケッチからの製品名(sketch --name)が後でフォルダ名を置き換えます。initはハウススタンダード(references/standards.md)も適用し、ロックします。それらについて尋ねる必要はありません;最初の結果で一度だけ言及します。init(またはsketch)はopendesigner/PROTOCOL.mdを書き込みます:6つのステップ、各ステップはオーナーゲートで終了、各ラウンドで実行されるチェック。ステップ1から従います。構築済みプロダクトの場合、ステップ1は監査から始まります。
- 最大3行で挨拶します(
rules.mdセクション1)。選択するモードはありません。opendesigner/state.jsonのprofile.trackingが設定されていない場合、挨拶の1つの質問はrules.mdセクション11のログ質問をそのまま使用します。スクリプトがユーザー自身のコンピュータで実行される場合のみ「このコンピュータ上で」と、ウェブチャットの場合は「プロジェクトファイル内で」と記載します。journey.py consent onまたはjourney.py consent offで回答を記録します。その後、最初のスケッチ質問を尋ねます。- それ以外の場合は、すぐに最初のスケッチ質問を尋ねます。
opendesigner/state.jsonにprofile.voiceが設定されている場合、そのボイスでリードします。
フロー:ズーム、マーチしない
詳細はreferences/zoom.mdにあります。
- レベル0、スケッチ: 最大5つの質問、メッセージごとに1つ、ユーザーの言葉ですでにいくつかに答えている場合は少なくなります。次に
engine.py sketch ...で回答を記録し、完全な最初のバージョンを構築します。最初の結果を表示します:得られたものの平易な行、概要(opendesigner/overview.html)、および1つの明確な次のステップ(zoom.md、「最初の結果」)。 - 急いでいるユーザー(「とにかく選んで」)は
--delegated付きのスケッチを受け取り、オプションの質問はありません。平易な言葉で話すユーザーは質問が少なくなります(zoom.md)。 - ユーザーリサーチ(約10分、あなたが行う):最初の結果の直後に、1つのメッセージで計画(
references/research.md)とともに、ユーザーが誰かを調査することを提案します。1回のyesの後、自分で実行し、engine.py research addで調査結果を保存し、推奨事項を適用する前に尋ねます。エンジンは、完了するかスキップされるまで、sketchとbuildのたびにそのことを思い出させます(engine.py research skip --why "...")。その後、色や方向性の前に:競合テーブル、確認されたポジショニング、ボード上の3つの方向性(research.mdセクション8および9)。 - テイスト投票(オプション、約5分):ユーザーは出荷済み製品の20〜30の実際の画面を評価し、結果は8つのダイヤルを推奨します。自分のテイストを言葉にできない場合(「見ればわかる」)、レベル1の前、またはユーザーが尋ねたときに提供します。これは、ユーザーがすでに回答した質問を決して置き換えません(
references/taste.md)。 - テイストインデックス(
taste.py index)は、このプロジェクトのすべてのテイストシグナルを統合します。確信があるダイヤルを「これを確認?」として提供し、残りは直接尋ね、赤線の1つを超えたオプションは除外します(すべてのオプションがそうである場合は除く:その場合はすべて表示し、どの線かを伝えます)。エンジンのオプションギャラリーとengine.py reviewはすでにそれを使用しています(references/taste.md、「テイストインデックス」)。 - プロジェクトの3つの方向性は、ポジショニングの後、方向性ボード上に表示されます(
engine.py research directions board、research.mdセクション9)。以下のオプションギャラリーはスタイル用です(Q-dir-01)。 - スタイルの方向性は最初にオプションギャラリーから提供します。 誰かがどの方向性を選べるか、またはあなたがどれを選ぶかを尋ねた場合、
engine.py show option-gallery --jsonを実行し(またはホストが表示できるページを開き)、それから回答します:ギャラリーの順序でのオプション、推奨、サブタイトル(テイストが除外した方向性や、各オプションがどの赤線を超えているかを示す)。回答でこれらの行を繰り返します。ユーザーがもっと見たい場合にのみ、カタログ(engine.py style search <words>、style list、style show <id>)に移動します...