Skill.md検索

設計JSON（トークン・コンポーネント・コンテキスト）から見た目のみのUI骨格を自動生成：ロジック・状態管理・API通信は一切含めず、Figma レイアウト（Auto Layout・constraints・resizing）を CSS flex・grid・breakpoints に忠実に変換。 複数技術スタック対応で標準配置を自動適用：React（src/components/）、Vue（src/components/*.vue）、SwiftUI（Sources/UI/）など、スタック別の公式ディレクトリ構造に自動配置、Storybook 対応も同時に生成。 トークン・コピー・アセットの SSOT 一元参照で二重管理を排除：design-tokens.json の color・typography・spacing、copy.json の文言、assets.json の画像を外部参照、値の埋め込みは禁止（magic number ゼロ）。 レスポンシブ規則（Figma→CSS マッピング）を自動適用：constraints/resizing ルール（SCALE→flex-grow、TOP_BOTTOM→h-full など）を breakpoints に従い自動変換、手作業ブレを完全排除。 デザインシステムオーナー・UI エンジニア：SSOT 確定後、実装前のUI骨格を素早く可視化したい フロントエンドアーキテクト：複数スタック対応の UI ファイル配置を標準化・保守しやすくしたい プロダクト開発チーム：Figma → コード間のスタイルズレを自動検出・修正したい デザイナー×エンジニアの協働チーム：「見た目は完成、あとはロジック」という分業を効率化したい コマンド：/design-ui [$TARGET] [$PAGE_KEY]（$TARGET：react/vue/svelte 等、$PAGE_KEY：design_context.json の pages[].key、省略時全ページ対象）。実行は /design-ssot または /design-mock の SSOT 成果物（design-tokens.json、components.json、design_context.json、copy.json、assets.json）を入力。出力：スタック別標準配置への静的 UI ファイル一式＋Storybook（対応スタックのみ）。禁止：状態・ロジック・データ取得・RDD逸脱スタック（指定時は ADR-lite 要）・copy.json の推測埋込。copyKey 不足は推測禁止、ユーザーに /design-ssot やり直し依頼。レスポンシブ規則：Auto Layout→flex + tokens gap/padding、constraints（SCALE→w-full、TOP_BOTTOM→h-full）、resizing（FILL→flex-1、HUG→max-content）、breakpoints は design-tokens.json 準拠、tokens 外の値・magic number 禁止。見た目基準ビューポート：rdd.md 「ターゲット表示環境」参照、未記入時は desktop 1440x900・mobile 390x844・tablet 834x1194 推奨デフォルト。

セッション冒頭で「ゴール」「完了条件」「チェックポイント」を書き出すことで、作業の方向性を明確にできます。 大きなタスクを1セッションで完了できる粒度に自動で分割し、実装スコープを絞った計画が立てられます。 複数のチェックポイント（CP）を設定して、途中で中断されても進捗が残る実装計画が作成できます。 「partially_achieved（部分的な完了）」を防ぎ、セッション終了時に確実に成果を積み上げられます。 大きなタスク（機能実装、PRレビュー対応など）を細かく分割したい人 セッション中に中断や割り込みが入る環境で働く人 セッション終了時に「何が完了して何が残ったのか」を明確に記録したい人 チームで進捗共有するときに、タスクスコープを正確に伝えたい人 セッション開始前の 5ステップ手順：(1)タスク確認（引数ありなしで分岐、選択肢から選択可能）、(2)ゴールと完了条件定義（チェックリスト形式）、(3)大きなタスクの場合のみ分割案をテーブル表示・優先度・今回対応範囲を明記、(4)チェックポイント設定（各 CP で中間コミット実施）、(5)セッション開始宣言。1セッション1～2タスク推奨、完了条件は「〜する」ではなく「〜が完了している」と具体的に記述。計画作成に要する時間目安は 5分以内。連携スキルは /session-end（終了時の進捗サマリー）、/pr-respond（PR対応）、/task-run（Issue実行）。

components.json で定義されたUIの見た目パターン（variants）を、React・Vue・Swiftなど各フレームワークの「型付きProps」に自動変換できます。 size（小/中/大）や色、状態などのバリエーションを、それぞれのフレームワークの正しい書き方に統一できます。 再利用可能なUIコンポーネントとして仕上げ、Storybook（UI見本帳）への自動登録・テストも同時に完了させます。 デザイン仕様を実装コードに自動反映するため、手作業でのコピペ・ミスを防ぎます。 デザイナーが作った UI部品を、エンジニアが実装する際の橋渡しが必要な方 React・Vue・Swift など複数フレームワークで同じUIを使い回したい組織 「デザイン → 実装」の工程を自動化・スピードアップしたいチーム このスキルは /design-assemble コマンドで実行します。doc/input/design/components.json の variants（size/tone/state等）を型付きProps/属性にマッピングし、選択されたテクノロジースタック別に再利用可能なUIコンポーネントを生成します。デフォルトは doc/input/rdd.md で指定されたスタック；引数で変更する場合は ADR-lite 承認が必須です。出力は React の場合 src/components/{Name}.tsx（Props型定義付き）、Vue は src/components/{Name}.vue、Svelte は src/lib/{Name}.svelte、SwiftUI は Sources/UI/{Name}.swift（enum/case）、Flutter は lib/widgets/{name}.dart、Web Components は src/components/{name}.ts となります。すべてのコンポーネントに JSDoc/Docstring/Swift Doc による Docコメントを付与し、a11y（アクセシビリティ）準拠（セマンティックHTML・WAI-ARIA）、Lint/Type/Test/Story の全緑、仕様追加禁止が必須です。マッピング規約は doc/input/design/ssot_schema.md を参照し、RDD/SOLID 原則に従う；逸脱は ADR-lite で理由と影響を明記する必要があります。

設計書とコードの整合性を自動チェック：RDD（Requirement Design Document）、アーキテクチャ設計書との齟齬を検出し、改善提案を提示します。 セキュリティ・アーキテクチャ・設計品質を同時にレビュー：複数の観点（OWASP基本・入力検証・認可・秘密情報・依存関係・責務分離・SOLID原則など）から、PR内容を多層的に評価します。 Docコメントを自動生成・転記して実装の意図を記録：設計書の責務や制約情報をコード側のDocコメントに反映させ、実装者の意図を後続開発者に伝えやすくします。 設計書の図表（Mermaidダイアグラム）の妥当性を検証：構文エラー・図と説明の不整合を自動検出し、修正を促します。 mainマージ前の最終品質ゲートとして機能：basic-review後の二次レビューとして、基本レビューではカバーしきれない深い観点を確認できます。 複数プロジェクトで統一的な品質基準を維持したいアーキテクト：各観点をスキル化することで、レビューの属人化を減らせます。 セキュリティリスクを最小化したいセキュリティ担当者：入力検証・認可・秘密情報漏洩などの脆弱性をPR段階で検出できます。 設計と実装のズレを早期に発見したい技術リード：RDD整合性チェックにより、仕様漏れや実装ズレを防げます。 mainブランチへのマージ品質を厳格に管理したいチーム：複数観点のゲートにより、本番リリース後の不具合を削減できます。 Deep Reviewスキルは、設計品質・セキュリティ・RDD整合を深掘りチェックする二次レビュースキル。対象ファイルのパスで自動判定され、doc/**/*.mdは「設計書モード」、それ以外は「コードモード」で動作。コードモード対象範囲は、セキュリティ（OWASP・入力検証・認可・秘密情報）、アーキテクチャ（境界・依存・責務分離）、設計品質（SOLID・重複・抽象度）、RDD整合、複雑さ、アクセシビリティ（UI変更時）、フロントエンド（該当技術時）。設計書モード対象は、SSOT整合（rdd.md・architecture.md整合）、Mermaid図検証、ADR-lite妥当性、網羅性、構造品質（見出し・セクション・リンク）、用語統一。コード変更時、設計書内容をDocコメントに転記：対応関係特定→転記内容抽出→転記フォーマット（@description @constraint @see）→レビュー指摘提案。実行手順は3段階：（1）RDD読み込み・差分取得・変更ファイル一覧化、（2）変更内容に応じたスキル特定、（3）セキュリティ・アーキテクチャ・設計品質・RDD整合の多観点レビュー実施。

曖昧な仕様を質問で埋め、推測実装を避けて正確な設計・実装を実現する 責務を正しい場所に配置し、重複や混在を防ぐことで長期的な保守性を確保する レビュー可能な最小単位の差分に分割し、ロールバック容易性と理解容易性を高める テスト駆動開発（RED→GREEN→REFACTOR）で安全な実装進行を実現する 実装前に設計を深掘りし、後から大きな修正を避けたい開発者 コードレビュー時に「なぜこの実装？」と質問されない、意図が明確な実装を目指す人 既存のパターン・テスト雛形を再利用して効率化と一貫性を両立したい人 責務の混在やリファクタリングの負債を作らず、チームとしての品質を保ちたい人 このスキルの基本方針は「既存優先」と「差分最小」です。実装前に、期待する入力・出力、失敗時の振る舞い、変更の影響範囲、既存規約（命名・ディレクトリ構成・テスト方式）を必ず確認します。 出力フォーマットは7段階：(1)目的、(2)前提（RDD・既存規約・制約）、(3)設計方針（責務・境界・例外・データ）、(4)実装手順（最小ステップ）、(5)差分、(6)テスト（RED→GREEN順）、(7)次の一手。 思想：①実装は仕様の翻訳で推測しない、②責務が混ざったら必ず腐る、③暫定対応を避け恒久化の出口を明記、④失敗時は最小サンプルで切り分ける。 チェックリスト：責務が単一目的か、依存方向が自然か、命名がドメイン意図を表しているか、RED→GREEN→REFACTORが成立しているか、境界条件を押さえているか、重複を増やしていないか、Docコメントで意図が説明されているか。

Issueからブランチ自動作成: GitHub Issue から修正内容を自動抽出し、命名規則に従ったブランチを一発生成できます。 段階的な修正案実行: Issue に記載された複数の修正案を上から順に試行し、各案の効果を検証します。 無効な修正は自動ロールバック: 修正を適用してテストした結果、効果がなければ git revert で修正前の状態に戻すため、失敗による影響を最小化できます。 恒久対応を強制: 一時ファイル削除やタイミング依存などの暫定策を排除し、本質的な原因改善のみを実施します。 修正完了後の自動PR作成: 修正完了時点で Pull Request を自動作成し、Closes #{ISSUE_NUMBER} で Issue に紐づけるため、マージ時に自動的に Issue がクローズされます。 開発チーム全体: バグ修正プロセスを標準化し、修正漏れや暫定対応の混在を防ぎたい 本番バグに迅速対応したい方: Sprint統合バグと本番緊急バグを分けて管理し、ホットフィックスを素早く対応したい 品質保証エンジニア: テスト実行と効果検証を自動化し、修正の有効性を数値で判定したい DevOpsエンジニア: CI/CDパイプラインにバグ修正フローを統合し、マージから自動デプロイまで一貫させたい バグ修正をブランチ作成から PR 作成まで実行する自動化スキルです。前提ポリシーは「安全第一」「検証必須」「可逆性」「恒久性」です。 実行手順：(1) Issue 内容を gh issue view で取得し、問題概要・再現手順・修正策候補を抽出、(2) .claude/rules/git.md に従いブランチ作成（feature_fix/{ISSUE_NUMBER}-{short-description}、base は sprint/* または main）、ベースブランチは sprint/* の存在確認後に決定、並行修正時は git worktree 利用、(3) Issue にコメント「修正着手」を記入、(4) 修正案を逐次実行ループ（最小コミット→検証→効果判定）し、無効時は git revert でロールバック、(5) 各修正後に pnpm lint --fix && pnpm type-check && pnpm test を実行して効果検証、(6) 修正完了後 PR 作成時に Closes #{ISSUE_NUMBER} で Issue に紐づけマージ時に自動close。

セマンティックHTMLで正しい構造を構築: 見出しやリストなど意味のあるHTML要素を優先的に使い、スクリーンリーダーが正しく読み上げられるUIの下地を作ります。 キーボードだけで全操作が可能に: マウスがなくてもタブキーやEnterキーで全機能を操作でき、どんなユーザーにも対応したUIになります。 最小限のWAI-ARIA（ラベル・役割・状態）を適用: 「何ができるボタンなのか」「今チェック済みなのか」といった情報を支援技術に正しく伝え、過剰な属性追加を避けます。 アクセシビリティ対応の判断軸を提供: UIデザイン・実装時に「何をどこまで対応すべきか」の迷いを解消し、実装品質を統一できます。 UIエンジニア・フロントエンド開発者: アクセシビリティ対応の正しい方法を学びながら実装したい人。 デザイナー・デザインシステムチーム: すべてのユーザーに使いやすいコンポーネント設計を目指す人。 QA・ユーザビリティテスター: 実装のアクセシビリティ準拠状況を判断し、要件を詰める場面で。

ブラウザ自動化でUIフローをテスト: 「ページを開く→ボタンをクリック→テキストを入力→送信」といったユーザー操作を自動実行し、期待通り動作するか確認できます。 スクリーンショットを自動取得・比較: ページの見た目を画像で記録し、レイアウト崩れやビジュアルリグレッション（意図しない見た目の変化）を検知できます。 壊れにくいテスト設計が可能に: CSSクラス名などの実装詳細に頼らず、「〇〇という名前のボタン」といった人間にも読みやすい要素選択で、コード変更時に失敗しにくいテストが書けます。 キーボード操作やアクセシビリティも検証: マウス操作だけでなく、キーボードフォーカスやスクリーンリーダ対応がちゃんと機能しているか確認できます。 QA・テストエンジニア: UI動作の自動テスト・ビジュアルテストを効率化したい人。 フロントエンド開発者: コミットやMR前に自分で簡単にE2Eテストを走らせたい人。 デザイナー: 実装後の見た目が仕様通りか、スクリーンショット比較で確認したい人。

アニメーションの役割を判断する 情報を伝えるために本当に必要な動きなのか、単なる装飾なのかを判断して、効果的で無駄のないアニメーション設計ができます。 自然で心地よい動きを実現する 物理法則（重力・慣性・摩擦）に基づくイージングやタイミングを理解し、ユーザーが違和感なく受け入れられる動きを実装できます。 アクセシビリティを確保しながら設計できる モーション酔いやストレスを感じるユーザーのための prefers-reduced-motion 対応を前提に、全員が快適に使えるアニメーション設計ができます。 ツールに依存しない判断軸を持つ CSS・JavaScript・Framer Motionなどツール選択に先立ち、「なぜこう動かすのか」をディズニーの12原則やMaterial Designで言語化でき、チーム全体で判断基準を共有できます。 ボタンやモーダル、メニューなど各パターンに最適な動きを設計できる タップフィードバック、画面遷移、メニュー展開など、UIパターン別の動きの工夫を具体的に実装できます。 UXデザイナー・プロダクトデザイナー アニメーションの「説得力ある理由」を持つことで、デザインレビューでの判断が速くなり、デベロッパーとの協業もスムーズになります。 フロントエンドエンジニア デザインの意図を理解した上でコードに落とし込め、ツール選択時の判断も自分で行えるようになります。 UIアニメーション・モーション設計に関わる全職種 基準がぶれないため、プロジェクト内での一貫性が保ちやすくなります。

不確実な設計判断を明確にする マイクロサービス化やモジュール分割など、「どう分けるべきか」という問いに対して、性能・可用性・保守性といった非機能要件とのトレードオフを整理し、複数の選択肢から最適解を選べます。 設計内容を記録・共有できる 設計判断が「なぜそうしたのか」とともにADR（Architecture Decision Record）で記録されるため、将来の変更時に過去の判断根拠を参照でき、組織の知見が蓄積されます。 運用を前提にした設計を立てられる 障害検知・復旧手順・ログ設計を含めた包括的なアーキテクチャを提案でき、本番環境での問題対応がスムーズになります。 データの所有権や責務の曖昧さを解消できる コンポーネント間の依存関係やデータ流向きを明確化し、実装時に「この責務はどこに置くべき？」という迷いが減ります。 スケール変化に対応しやすい構造にできる アーキテクチャの段階的な成長戦略を設計でき、今必要な最小構成から始めつつ、将来の拡張を見越した構造になります。 バックエンドエンジニア・アーキテクト 新規プロジェクトや大規模な設計変更で、説得力ある提案ができるようになります。 テックリード・エンジニアリングマネージャー チーム全体の設計判断を可視化・合意形成でき、実装の上流で問題を潰せます。 プロダクトマネージャー・PO 技術的な実現可能性と制約を理解した上で、優先度やスケジュール計画が立てられます。 スタートアップの初期メンバー 限られたリソースの中で、今必要な構造と将来への投資バランスを判断できます。

表面的なミスを自動検出できる typo（タイプミス）、命名規約の違反、不要な空白など、人間が見落としやすいミスを素早く洗い出し、修正できます。 コード品質の基本を統一できる PR（プルリクエスト）段階で軽微なミスを指摘することで、深いレビューにリソースを集中させ、チーム全体の品質ベースラインを上げられます。 設計書とコードの乖離を防げる コード変更時に対応する設計書の内容をDocコメントに転記する仕組みで、「設計書に書いてあるのにコードには反映されていない」という状況を事前に防ぎます。 未使用インポートや明らかなバグを見つけられる 到達不能コード、console.log の残存、debugger キーワードなど、開発時の落とし穴も気づきやすくなります。 Markdownやアーキテクチャドキュメントも同じフレームワークで確認できる 設計書のリンク切れ、見出し階層の乱れ、Mermaid図の構文エラーも同じレビュー体系で検出できます。 開発チーム全体・すべてのエンジニア PR作成前やコード変更後の最初のレビューパスとして、素早く形式的な問題を洗い出せます。 コードレビュアー 誤字やフォーマット指摘の時間が減り、設計や実装の深い部分にフォーカスできます。 テックリード・スクラムマスター チームのコード品質ベースラインを統一し、レビューサイクルを高速化できます。 ドキュメント担当者・アーキテクト 設計書の記述ルール検証や見出し整合性の確認が効率化されます。

市場や競合の情報を根拠つきで整理できる 価格設定、ターゲットセグメント、機能優先度など、経営判断が必要な問題に対して、信頼度の高い出典を明記した分析資料を作成できます。 確かなことと推測を分離できる 公式データと推定、事実と仮説をはっきり区別して記録し、「この判断にはどのくらいのリスクがあるのか」を可視化できます。 競合との差別化ポイントを見つけやすくなる プロダクト比較だけでなく「ユーザーは現在どう代替行動をしているのか」という視点で市場を分析でき、真の競争相手を認識できます。 調査から意思決定まで一気通貫で進められる 調査結果がそのまま「何を優先すべきか」という行動判断に繋がり、作業で終わらず経営判断に寄与します。 次に何を調べるべきかが明確になる 現時点での不確実性を明確にし、期限やコスト内で最小限の追加調査に絞り込めます。 プロダクトマネージャー・事業企画 市場規模やターゲット検証の説得力が高まり、経営層への提案がより実現的になります。 スタートアップの創業者・メンバー 限られた時間・予算の中で、本当に調べるべきことに集中でき、ピボット判断も早くなります。 マーケティング担当者・営業戦略策定者 競合と代替サービスの動向を整理でき、セグメント選定やチャネル戦略が根拠を持って立てられます。 経営陣・意思決定者 部下からの報告に「どこまで信頼できるのか」を見極め、判断の精度が上がります。

バグの原因候補を絞り込める ログ解析、コード検索、環境確認など段階的な調査を実行し、「何が原因で起きているのか」の仮説を精度高く更新できます。 調査内容をIssueに記録できる 実施した調査、観測されたログ、導き出された新しい仮説をGitHub Issue のコメントに自動追記し、チーム全体で調査進捗を追えます。 再現方法や前提条件を明確にできる バグが「いつでも再現するのか」「特定の環境でだけ起きるのか」を確認し、修正時の検証範囲を適切に設定できます。 修正策を立てやすくする 原因が明確になることで「どこをどう直せばいいか」が見えやすくなり、修正時間が短くなります。 同じバグの再発防止に役立つ Issue に記録された調査プロセスと原因が将来の参考資料となり、類似バグへの対応が高速化されます。 バグトリアージを担当するエンジニア バグIssue の内容から効率的に原因を追跡でき、本当に優先すべき不具合を見極められます。 フロントエンド・バックエンド開発者 報告されたバグに対して、データドリブンで原因を特定でき、修正の自信度が上がります。 QA・テスト担当者 バグの再現条件や観測ポイントを明確にすることで、開発チームへの報告品質が向上し、修正検証が効率化されます。 スタートアップやスモールチーム 専任の調査者がいなくても、体系的にバグ原因を追跡でき、チーム全体の対応力が向上します。

問題の整理・可視化: エラーの内容、発生環境、再現手順をGitHub Issue上に自動で構造化して記録し、チーム全体で現状を素早く把握できます。 原因の仮説を複数立てる: 「こうに違いない」と決め打ちせず、考えられる原因を複数リストアップし、どの仮説から調査すべきかを整理できます。 調査・対応計画の事前設計: 実装に入る前に、検証方法や暫定/恒久の対応策をまとめておくことで、修正後の品質低下や再発を防ぎます。 問題の履歴を一元管理: 発見から解決までの経過をIssueコメントで時系列に記録し、同じバグが再発したときの対応を迅速にできます。 開発チーム全体: バグ報告時に「どう説明したらいいか」と悩む時間を短縮し、本当に大事な解決作業に集中したい方。 エンジニア: エラーが発生したとき、焦らず原因を一つ一つ検証できる「思考のテンプレート」が欲しい方。 プロダクト管理者: バグの進捗状況をIssueで一目で把握し、どのバグが重要かを判断したい方。

複数の修正案を根拠付きで提案: 原因の仮説ごとに「こういう修正方法がある」という案を複数挙げ、それぞれどの公式ドキュメントやプロダクトで確認されているかを明記します。 修正による影響範囲を事前評価: 各修正案が他のシステムやユーザーに与える影響、リスク（不具合が起きないか）、実装に必要な前提条件を整理し、採用判断の材料にできます。 実施手順とロールバック方法をセット: 「やってみたけど戻せない」という事態を避けるため、修正手順と万が一のときの戻し方を一緒に記録します。 検証方法を明記: 修正後に「本当に直ったのか」を確認する方法（テスト内容や確認ポイント）を事前に決めておくことで、リリース後の問題を減らせます。 技術リーダー・テックリード: 複数の修正案の中から「今このプロダクトに最適な方法」を判断し、チームに指示したい方。 保守性重視の開発チーム: 「今は動いているけど、3ヶ月後も安心」な修正策を選びたい方。 本番環境に強い不安を持つエンジニア: 修正前に影響範囲やロールバック方法を確認し、自信を持ってデプロイしたい方。

体験を数値化・設計化する: 「なんか気持ちいい動き」を「どんな状態変化が、どのタイミングで起きるか」という仕様に翻訳し、誰でも同じように実装できるようにします。 すべてのユーザーが快適に操作できる: 動きが苦手な方でも操作に支障がない配慮（アクセシビリティ）と、モバイルやスマートウォッチでも素早く動作すること（パフォーマンス）を両立した表現を実現できます。 実装を段階的に強化する計画立て: 最初は最小限の実装から始めて、本当に価値のある動きだけを残すことで、コードの複雑さとバグを減らせます。 デザインの意図を実装チームに正確に伝える: アニメーション・スクロール表現・タッチ反応など、複雑な演出もルール化して共有でき、デザイン意図の再現性が高まります。 デザイナー: 心地よい動きのアイデアを、開発チームが実装しやすい「仕様書」に落とし込みたい方。 フロントエンドエンジニア: 高速と美しさを両立させたUIを作りたい、複雑なアニメーション実装に不安がある方。 プロダクト全体の品質を気にかける方: すべてのデバイス・能力のユーザーが同じレベルで楽しめるプロダクトを作りたい方。

デザインの重複を自動検出・整理: 見た目が似ているUIパーツ（ボタン・カード・フォームなど）を自動で見つけ出し、「これは再利用コンポーネントにしよう」という判断がしやすくなります。 ページ固有の枠と再利用部品を分離: 「ホームページ独自のレイアウト」と「複数ページで使えるボタンやカード」の境界を明確にし、後の実装や保守で無駄なコード重複を防ぎます。 既存の規約を尊重した整理: プロジェクトの既存のフォルダ構成や命名ルールに合わせて自動整理するため、チーム内で「なぜこんなことを？」という混乱が起きません。 次のステップへのスムーズな引き継ぎ: コンポーネント化が終わった状態から、UIバリエーション（サイズ・色・状態）の管理や実装へと自然に進めることができます。 デザインシステムを整えたい組織: 「デザインがバラバラで、何度も同じUIを作っている」という課題を解決したい方。 フロントエンド開発チーム: 実装に入る前に「何をコンポーネント化すべきか」を明確にして、スムーズに開発したい方。 デザイナー・エンジニアの連携を強化したい方: デザインの意図を「実装可能な単位」に翻訳するプロセスを自動化したい。

デザイン設計をHTMLで可視化: デザイン設計の定義ファイル（JSON）をそのままブラウザで見える形に変換し、「このトークンやコンポーネント、実際の画面でどう見えるの？」をすぐに確認できます。 実装前にUIの齟齬を発見: 完成したHTMLを目で見ることで、デザイナーとエンジニアの「実装イメージのズレ」を早期に気付き、手戻りを減らせます。 チーム・クライアントへ視覚的に共有: Figmaやドキュメント文字だけでなく「実際に動作するHTML」として共有することで、説明なしに見た目が伝わり、レビュー効率が上がります。 実装環境に依存しない確認: React・Vue・HTMLどのスタックでも、デザイン設計が正しく反映されているかを統一フォーマットで確認できます。 デザイナー: デザイン設計を言語化（JSON）した後、実装環境を待たずに見た目を確認したい方。 デザインレビューを丁寧にしたいチーム: テキストだけでなく、実際にブラウザで見える形でレビューしたい。 複数ページのデザイン統一を確認したい方: 各ページのHTML見た目を並べて、デザイン矛盾や漏れを一気に発見したい。

会話ベースでUIの初期案を素早く形にする。Figmaやデザインツールがない・固まっていない段階で、ユーザーの要件を聞きながらデザイン構成（JSON形式の設計書）と静的HTMLの雛形を同時に作成できます。 複数ページを一度に設計できる。「ホームページ、料金ページ、ログインページ」のように複数画面を指定すれば、それぞれのHTMLと統一された設計情報が生成されます。 後の実装工程へ自動で引き継げる。生成された設計書（トークン・コンポーネント・文言のルール）は実装チームが参照でき、デザインと実装のズレを防げます。 反復調整が簡単。生成されたHTMLを見ながら「ここをこう変えたい」という修正内容をAIに伝えれば、HTMLだけでなく設計書も同時に更新されます。 見た目と情報設計に集中できる。状態管理やデータ取得などの技術的な実装は後にして、まず「どう見えるか」「どう並べるか」を決められます。 プロダクトマネージャー・企画担当者：要件をAIと対話しながら、デザイン案を素早く可視化したい場面 スタートアップ・少人数チーム：デザイナー不在で、まず画面イメージを確認してから開発を進めたい場合 デザイナー：Figmaで本設計する前に、ユーザーとの対話で方向性を固めておきたい時 開発チーム全体：デザインのルール（色・文言・コンポーネント構成）を共有ドキュメントとして持ちたい場合

複雑なコードベースを人間が読める形に翻訳する。ディレクトリを指定するだけで、AIがコード構造を分析し、全体像・アーキテクチャ・データベース設計などの設計ドキュメントを自動生成します。 引き継ぎ資料を素早く作成できる。新しいチームメンバーや新しい開発者が「このコードは何をしているのか」「なぜこう設計されているのか」を短時間で理解できる一連のドキュメントが揃います。 設計判断の背景を可視化する。なぜその技術を選んだのか、どんな代替案があったのか、その決定による得失は何かなど、Google Design Doc形式で整理されます。 技術負債や矛盾を発見できる。生成されたドキュメント内で、公式な設計書（RDD）とコード実装にズレがあれば指摘されるため、意図しない実装の乖離に気づけます。 定期更新で常に最新を保つ。コードが変わったら再解析して、ドキュメントを上書き更新できます（Git履歴で変更を追跡）。 新しく加わった開発者：既存プロジェクトの全体構造を素早く理解したい場合 技術リード・アーキテクト：設計の意思決定を記録し、チーム全体で共有したい時 マネージャー・ステークホルダー：技術的な複雑さを簡潔に説明するドキュメントが必要な場合 保守・リファクタリング（コードの整理・改善）を担当するチーム：現在の構造を把握した上で、改善計画を立てたい場面