Document
/impeccable document
Good fit
- コードベースにはすでに本物のデザイン言語が含まれている。
- カラー、タイポグラフィ、スペーシング、コンポーネントのポータブルな要約が必要。
- システムが暗黙的であるため、今後のデザイン作業が逸脱している。
Creative North Star: “The Editorial Sanctuary.” Quiet type, generous air, one committed accent.
Flat by default. Shadows appear only as a response to state.
6つのセクションは固定順序、固定名。併せて DESIGN.json がLive Modeデザインパネル用の機械読み取り可能なサイドカーとして出力されます。
いつ使うか
ドキュメント化するだけのビジュアルシステムができたら /impeccable document を実行してください:カラー、タイポグラフィ、少なくともボタンとカード。コマンドはコードベースをスキャンし、見つけたトークンとコンポーネントパターンを抽出し、Google Stitch DESIGN.md形式に従う DESIGN.md をプロジェクトルートに書き込みます。6つのセクションが固定順序で、他のすべてのDESIGN.md対応ツールと相互運用可能です。
次のような場合に使ってください。
/impeccable teachを実行したばかりでPRODUCT.mdが存在する。Documentは対応するビジュアル側のファイル。- コマンドから促された。 Live、craft、polishはすべてDESIGN.mdを読み込みます。欠落している場合、スキルはまずdocumentの実行を提案します。
- デザインが古いDESIGN.mdから逸脱し、ファイルがもはや稼働中のシステムを記述していない。
- 大規模なリデザインの前に、次の方向性の参照として現在の状態をキャプチャする。
コードがまだないプロジェクト(新規の teach 実行、何もビルドされていない)では、シードモードがあります:/impeccable document --seed は5つの短い戦略的質問(カラーストラテジー、タイプ方向、モーションエネルギー、リファレンス、アンチリファレンス)をしてスキャフォールドを書き込みます。コードができたらスキャンモードで再実行してください。
仕組み
スキャンパスは優先順位に従ってデザインアセットを見つけます:CSSカスタムプロパティ、Tailwind設定、CSS-in-JSテーマ、デザイントークンファイル、コンポーネントソース、グローバルスタイルシート、最後にブラウザが利用可能な場合はライブレンダリング出力からの計算スタイル。可能な限りすべてを自動抽出し、クリエイティブな入力が必要な部分について1つのグループ化された質問をします:Creative North Star(システム全体の単一の名前付きメタファー、「The Editorial Sanctuary」のような)、説明的なカラー名、エレベーション哲学、コンポーネントキャラクター。
出力は丁度6つのセクションを持つDESIGN.mdです:Overview、Colors、Typography、Elevation、Components、Do’s and Don’ts。ヘッダーは文字単位で固定されており、ファイルが他のツールで解析可能です。併せて DESIGN.json が機械読み取り可能なサイドカーとして書き込まれます。このサイドカーがライブモードデザインパネルで、汎用の近似ではなくこのプロジェクトの実際のボタン、入力、ナビ、カードタイルをレンダリングするために使われます。
他のすべてのコマンドは呼び出し時にDESIGN.mdを読み込みます。バリアント、ポリッシュ、監査、新機能は、指示されなくてもビジュアルシステムを継承します。
試してみる
/impeccable documentすでにトークンが定義されているプロジェクトでは、約2分かかります:スキャンがパレットとタイプスタックを見つけ、2〜3のオプションからNorth Starを選び、説明的なカラー名を確認(“blue-800”ではなく“Deep Muted Teal-Navy”)し、ファイルがプロジェクトルートに配置されます。
新規プロジェクトの場合:
/impeccable document --seed5つの質問、約5分。ファイルはスキャフォールドで、正直に何であるかを示す <!-- SEED --> コメント付き。トークンを実装したらフラグなしで再実行してください。
注意点
- 早すぎる時期に実行すること。 実装されたトークンがないプロジェクトでは、シードモードが正しいです。コードが裏付けられない完全な仕様を捏造しないでください。偽のDESIGN.mdはDESIGN.mdなしより悪いです。
- DESIGN.mdを人間向けのドキュメントとしてのみ扱うこと。 主にAI向けです。他のすべてのコマンドが読み込みます。形式の強さ(“never”、“always”、Named Rules)は意図的です。
- Layout / Motion / Responsiveのトップレベルセクションを追加すること。 仕様には6つのセクションが固定順序、固定名であります。レイアウトやモーションの内容はOverview(哲学レベルのルール)またはComponents(コンポーネントごとの動作)に折りたたんでください。
- 既存のDESIGN.mdを黙って上書きすること。 Documentは常に最初に確認します。新規開始したい場合は、既存のファイルを別の場所にリネームするか、スキルに上書きを明示的に伝えてください。
アイデアを、出荷できるソフトウェアへ。
HagiCode はエージェント型コーディングワークスペースです。OpenSpec ワークフローで変更を計画し、マルチエージェント実行で進め、Hero Scenario で長い作業の進み具合を見える化して、アイデアを出荷できるソフトウェアにします。
- スマート
- OpenSpec ワークフローが、意図を提案からリリースまでの実行可能な道筋にします。
- 効率的
- マルチエージェント実行で、調査・実装・レビューを並行して進めます。
- 楽しい
- 使いやすい UI で、計画・Agent 実行・プロジェクト作業を進めやすくします。
エコシステムサイト
クイックリンク
コミュニティ
© 2026 HagiCode | Powered By hagilight-starlight@0.18.0 | Branch: main | Commit: 4369090 | Built:
