heyeddi-design

HeyEddi のデザイン

HeyEddi アプリ向けのスタック非依存の UI デザイン：探索、ブリーフ、批評、デザインシステムのドキュメント作成。実装（Vue、Flutter、コンポーネント内の CSS）はスタック別スキルの担当です。reference/implement-routing.md を参照してください。

チーム： @taste-penpot が Anthropic frontend-design とトークンを使って、1 回の工程で外観を決めます。このスキルは、プロダクトとの適合性と実装への引き継ぎを担当します。デザインに取りかかる前に reference/design-team.md を読んでください。2 つ目の配色を作成したり、外観を探すために探索 → 調査 → 検討をやり直したりしないでください。

自動読み込み： デザインに関する会話では、このスキルが読み込まれます。また、まだトークンが作成されていない場合は、直ちに @taste-penpot を読み込みます。その後、それらのトークンを記録してください。reference/brief-language.md はブリーフ向けのプロダクト用語であり、2 つ目のアートディレクションではありません。

デザインと実装（必須の分離）

レイヤー	スキル	提供するもの
デザイン（このスキル）	@heyeddi-design	ブリーフ、ワイヤーフレーム、批評、design.md、IA、美的方向性
実装（スタック）	@heyeddi-handoff, @design-handoff-flutter	Vue / Flutter の本番 UI コード
適用（スタック）	@vue-design-system	Quasar シェル、PrimeVue Aura、モーション、トークン、CLI
検証（非依存）	@visual-auditor, @ux-flow-auditor	スクリーンショット、コントラスト、フロー、修正

リリースする UI に至るセッションでは毎回、reference/implement-routing.md を読んでください。

デフォルトの動作（確認不要）

• あらゆる種類のデザインに関する会話： まず brief-language.md を読み込み、クロームに取りかかる前に好み + 対象 + 明確な却下条件を固定します
• より良いデザイン／再デザイン： 「より良いデザイン」「もっと良くして」「再デザイン」「新しい外観」「全面刷新」「驚き」「一流」→ 表面的な磨き込みだけで済ませないでください。批評の意欲ゲート（reference/critique.md）を実施し、テンプレートのように見える場合、または意欲の基準を満たさない場合は → shape → 制作 → 実装。これらの表現に対して、余白やトークンの調整だけで済ませるのは不適切です。
• 批評 + 修正（局所的）： 「見栄えが悪い」「このページを直して」「磨き込んで」「余白を調整して」→ 批評 の後に スタック実装担当者 + @visual-auditor — ただし、意欲ゲートで shape へのエスカレーションが指示された場合を除きます（その場合は先に shape を実施し、確認を求めないでください）。
• 制作： 確定済みのブリーフ → 同じワークフロー内でスタック実装担当者に引き継ぎます
• 意欲の基準： 主要ルートでは、優れた制作がデフォルトです。ユーザーから求められるまで待たないでください

サブエージェント（デフォルト）

サブコマンドごとに委任します：reference/subagents.md を参照してください。メインチャットではブリーフを確認し、結果を統合します。

必ず委任するタスク	サブエージェント
@visual-auditor / Playwright	shell
validate_vue、npm test、build	shell
critique、craft、polish（ルート作業）	generalPurpose
research、ワイヤーフレームの explore	generalPurpose
document 用のコードベーススキャン	explore

引き継ぎのターン中に、インラインで視覚キャプチャを実行しないでください。

ピラー横断の同期（必須）

reference/cross-pillar-handoff.md を読んでください。craft、critique、polish、shape（ブリーフ確定時）の開始時と終了時に実施してください。

@heyeddi  load_workflow_context --route /path
… design work + Decision log in design.md …
@heyeddi  append_pillar_opinion --pillar design …
→ @heyeddi-product scope check; @ux-flow-auditor flow note if IA affects tasks

セットアップ（毎セッション）

1. セッションごとに一度、python scripts/load_context.py --project-root <root> を実行します（出力がすでに会話内にある場合はスキップします）。
2. product_exists が false で、タスクに戦略的なコンテキストが必要な場合は、shape／craft の前に init を実行します。
3. 実行するモードのサブコマンドリファレンスファイルを読みます（必須：省略しないでください）。 3a. デザイン／見た目／雰囲気に関する話題（discover、shape、craft、critique、polish、または「こんな見た目にして」といったカジュアルな依頼）では、まず reference/brief-language.md を読みます：テーマ／メタファー、明確な却下事項、ヒーロー／タイポグラフィ／アクセント／レスポンシブ対応／SSOT、ファーストビューのチェックリスト、完了基準。 3b. ルートを shape、craft、critique、polish する場合は、reference/implement-routing.md を読みます。 3c. ルートを shape、craft、critique する場合は、セッションごとに一度 reference/surface-completeness.md を読みます。 3d. セッションごとに一度 reference/foundations.md を読みます：product.md で免除されない限り、レスポンシブ対応、テーマ、i18n、a11y、読書モードは 常に有効 です。 3e. マーケティング、ダッシュボード、または設定のルートを shape する場合は、reference/modern-reference.md を読みます。 3f. ユーザー向けのルートを shape、craft、polish する場合は、reference/audience-design.md を読みます。 3g. 主要ルートでは reference/design-ambition.md を読みます。 3h. ユーザー向けのルートでは reference/aesthetic-direction.md を読みます。 3i. brief または design.md で UI コピーを作成する場合は、context/PROSE_ANTI_SLOP.md を読みます。 3j. 主要ルートの explore、shape、critique では、reference/visual-tools.md を読みます：IDE で利用できる場合は、方向性のプローブに GenerateImage を、比較／brief／critique の要約に Canvas を使用します。
4. shape（brief 確定後）、critique、または polish の後に、.heyeddi/design.md の Decision log に追記します。
5. スタックの実装担当者が作業を終えたら、反復中に @visual-auditor を fast、幅 375,768,1440 で実行します。主要ルート／マーケティングルートを完了とする 前に、done を幅 375,430,768,1024,1440,1920 で実行し（--preset done）、確認した問題を修正します。ロゴ非表示テスト：ブランドを取り除いた後に別のスタートアップのサイトにも見えるなら、まだ完成ではありません。

コマンド

コマンド	目的
(サブコマンドなし)	曖昧なデザイン依頼 → discover を開始
init	PRODUCT.md を作成または更新し、DESIGN.md のドキュメント化を提案
discover	発見インタビューのみ：コードは作成せず、最終 brief も作成しない
research	現在のデザイン方針について、ウェブ上のトレンド／参考資料を調査
explore	コンセプト画像（GenerateImage）＋ Canvas による比較＋ワイヤーフレーム
shape	完全な計画フロー：discover → research → explore → 確定した brief
document	コードまたは初期質問をもとに DESIGN.md を生成または更新
craft	brief の準備完了 → スタックの実装担当者に 引き継ぎ（implement-routing を参照）
critique	既存 UI の UX レビュー → レポート → 実装＋visual-auditor を自動で連続実行
polish	critique 後のデザイン仕様の調整＋コード担当のスタック実装者

ルーティングルール

1. より良いデザイン／再デザインの意図（既存のルートに対する「better design」、「make it better」、「redesign」、「new look」、「overhaul」、「major improvement」、「wow」、「top notch」）：reference/critique.md の ambition gate を読み込みます → エスカレーションする場合は、reference/shape.md を読んでから craft を実行します（polish のみではありません）。「改善」か「再デザイン」かについては、reference/design-ambition.md § Improve vs redesign を参照してください。
2. 既存 UI：局所的な修正（「critique」、「looks bad」、「fix this page」、「polish」）：reference/critique.md を読み込みます → ambition gate を実行します → gate が局所的な対応を指示した場合に限り、polish パスを実装して @visual-auditor を実行します。質問はしないでください。
3. サブコマンドなし、曖昧な新規作成：reference/discover.md と brief-language.md を読み込みます。
4. サブコマンドが表に一致する場合：reference/<command>.md を読み込みます（shape/craft/critique/polish の場合は brief-language.md も読み込みます）。
5. 確認済みの brief がない状態での craft：まず shape を実行します（brief には subject と hard rejects が必要です）。 5b. ペルソナのない flagship routes：まず @heyeddi-intake または discover を実行します。
6. このセッションで critique を実行せずに polish を実行する場合：まず critique を実行します（ambition gate も含みます）。
7. スクリーンショット／承認済みのモックアップ：デザインの craft コードではなく、@heyeddi-handoff を使用して実装します。
8. impeccable は決して呼び出さないでください：このスキルがその役割を置き換えます。

成果物

成果物	場所
デザイン brief（確認済み）	.heyeddi/designs/<feature>/brief.md
ワイヤーフレーム	.heyeddi/designs/<feature>/wireframes/
調査メモ	.heyeddi/designs/<feature>/research.md
デザインシステム	.heyeddi/design.md
プロダクトのコンテキスト	.heyeddi/product.md
critique、監査	.heyeddi/docs/

<feature> には kebab-case を使用してください。

基礎（デザイン仕様 — 実装者がコードで適用します）

レスポンシブ、ライト／ダーク、en+es の i18n、WCAG 2.2 AA、セマンティックトークンについては、reference/foundations.md、reference/token-strategy.md、reference/brief-language.md を参照してください。

context/VOCABULARY.md、context/ANTI_PATTERNS.md、context/PROSE_ANTI_SLOP.md、context/EXAMPLES.md、reference/brief-language.md を参照してください。

タスク完了時：次に使うスキルを提案する

python .agents/skills/heyeddi/scripts/suggest_next_skill.py \
  --current-skill heyeddi-design --project-root .

分かっている場合は、--route /path と --mode <sub-command> を追加してください。