identity-skill

個人ウェブサイト（Personal Website）

コアとなるルール

すぐにコードを書き始めないでください。ウェブサイトを、段階ごとにリファレンス画像をもとに進めるプロジェクトとして扱います。

1. コンテンツとスタイルの確定
2. リファレンス画像の確定
3. 素材の分解リスト
4. 素材の生成・レビュー
5. 高忠実度の再現と QA

ユーザー向けのワークフローでは、デフォルトで次の4つの確認を必須とします。

1. サイトの形式、セクションの構成、コンテンツの充実度、選択済みまたはユーザー提供のビジュアルの方向性を含む、コンテンツとスタイルの完全なブリーフを確認します
2. 一貫性、リズム、実装可能性を審査した後、リファレンス画像のセットを確認します
3. 新しい素材の生成または検索を始める前に、素材の分解リストを確認します
4. ページのコードを実装する前に、生成・整理済みの素材と再現実行ブリーフを確認します

リファレンス画像のセットを確認した後、すぐに実装へ進まないでください。まず確認済みの各リファレンス画像を調べ、ユーザー向けの素材分解リストを作成して、確認を待ちます。リストの確認後は、承認された素材だけを生成、検索、または整理します。素材の準備が完了したら、最終的なパス、確認結果、簡潔な再現実行ブリーフを提示し、ユーザーが承認するか、再生成を依頼するか、分解内容を修正するのを待ちます。この確認が完了してから、高忠実度の再現を始めます。

以前の軽量なビルド前デザインメモは素材レビューの出力に統合し、簡潔な再現実行ブリーフにします。これは独立した追加の確認段階ではありません。ユーザーはコードに着手する前に、素材の結果と再現実行ブリーフを同時に確認します。

後続の段階を通常のフロントエンド構築に短縮しないでください。確認済みのリファレンス画像はムードボードではありません。コードを書く前に、各リファレンス画像に確認済みのレンダーコントラクトを用意し、コードが担当する領域、融合するシーン、独立したメディア、アイデンティティ／真正性の素材、ビジュアルアンカー、最終的なソースと状態の判断に分解する必要があります。

ハードストップ条件：素材分解リストの確認、承認済み素材の生成または整理、素材レビューと再現実行ブリーフの承認がすべて完了するまで、HTML、CSS、JS、React、route、component の各ファイルを作成または変更しないでください。進捗メッセージで「リファレンス画像を分解します」と言うだけでは、完了とはみなされません。

洗練されたリファレンス画像主導のプロジェクトでは、証拠に関するハードストップ条件も適用します：references/evidence-gate.md を読み込んでください。必要な証拠がディスク上にない場合、状態は not verified に限られ、pass と記載してはいけません。確認の一時停止を省略したいというユーザーの要望は、条件を満たした後に自動で続行することを意味するだけです。自動承認、リファレンス画像の無断差し替え、レビューの省略、証拠のない完了を意味するものではありません。

ユーザーの資料が一部しかない場合は、まず不足を確認し、すぐにすべての内容をユーザー自身に書いてもらうのではなく、より手間の少ない資料提供方法を優先して提案します。ユーザーがすでに確認済みのコンテンツ、リファレンス画像、素材を用意している場合は、該当するレビュー、素材レビュー、または再現の段階へ直接進めます。ただし、コードに着手する前の確認境界は同じように維持します。

実行上の規律

段階を進める際は、現在の前提、次に検証可能な目標、その完了を確認する方法を説明します。依頼の解釈が複数ある場合は、具体的な方向に進む前に選択肢を明確に示し、ユーザーに尋ねます。

変更は最小限に抑えます。

• ユーザーが依頼または確認していないセクション、インタラクション、コンテンツ、route、素材の種類、設定を追加しないでください
• 既存のプロジェクトを編集する場合は、確認済みの範囲で必要なファイルだけを変更し、プロジェクト既存のスタイルに合わせてください
• このワークフローで追加した結果不要になったコード、素材、import だけを削除してください。無関係な既存の未使用コードは、削除せず指摘するにとどめます
• 次の段階を確実に進めるために必要な、最小限の設計メモ、素材リスト、プロンプト一式、または実装変更を優先してください
• 複数段階の作業には、推測に頼らず進められるだけの具体的な成功基準を設けてください
• 一度に実装して受け入れ確認するのは、1つのセクションスライスだけです。一部のセクションしか確認していない場合、複数のセクションが合格したと主張してはいけません

言語とローカライズ表現

ユーザー向けの案内は、ユーザーの主要な言語に合わせます。ユーザーが中国語で質問した場合、進捗メッセージ、段階間の案内、確認依頼、選択肢のラベルは中国語にします。たとえば 第一步 / 内容与风格锁定、接下来进入第二步 のようにします。ユーザーが英語で質問した場合は英語にし、Step One / Content and style lock、Next I will move to Step Two のようにします。会話が中国語と英語の混在の場合は、ユーザーが最後に明示した希望、または直近の実質的な依頼の言語を優先します。

ユーザー向けの案内、段階間の移行、確認依頼、選択肢のラベルは、デフォルトで中国語にします。実行上の契約が変わらないよう、必要なファイル名、コマンド、フィールド名、技術用語は英語のままにします。

段階名も最後まで翻訳してください。中国語ユーザーには 第五步 / 高保真复刻与 QA と記載し、Step Five / Build and QA のような中国語と英語の混在ラベルは使わないでください。

内蔵の Companion Skills

この skill には companion reference が内蔵されているため、ワークフローの実行にユーザーが別の skill を追加でインストールする必要はありません。

• references/imagegen-frontend-web.md：第二段階における個人ウェブサイトのリファレンス画像生成に関するハードコントラクト
• references/visual-quality-gate.md：第二段階と第五段階における意味、階層、余白、トリミング、重なり、作者性、fresh-context レビュー
• references/evidence-gate.md と scripts/verify_identity_run.py：上書きできないリファレンスハッシュ、セクションごとのスクリーンショット証拠、トポロジーの帰属、決定論的な完了検証
• references/reference-asset-splitter.md と references/split-patterns.md：第三段階の3軸による素材判定と、実際の修正事例
• references/frontend-app-builder.md：素材レビュー後の高忠実度実装と QA

個人ウェブサイトのリファレンス画像生成段階では、独立した imagegen-frontend-web がインストール済みかどうかにかかわらず、references/imagegen-frontend-web.md を必ず読み込んでください。洗練され、プロフェッショナルで、独自性のある、または Awwwards レベルの仕上がりを目指す場合、第二段階と第五段階では references/visual-quality-gate.md も必ず読み込んでください。これらの内蔵ファイルは、このワークフローにおける必須の契約です。独立した skill はより幅広いクリエイティブな語彙を補足できますが、確認済みのブリーフ、style fingerprint、meaning contract、ビジュアル品質の基準、素材予算、実装可能性のルールに優先することはできません。

素材の判定段階では、reference-asset-splitter がインストール済みの場合はインストール版を使用し、そうでない場合は内蔵版を使用します。いずれも同じ classifier と事例を維持してください。ユーザーが確認したブリーフと、この skill に定める必須の段階境界は、companion のデフォルトルールより優先されます。第五段階では、引き続きインストール版の frontend-app-builder を優先し、内蔵版は fallback として使用します。

companion skill がインストールされていない場合でも、作業を止めたり、@skill の呼び出しが使えるふりをしたり、ワークフローを続けるためにインストールを要求したりしないでください。このパッケージに内蔵された companion reference を読み込み、ローカルでの最低限の実行契約として扱います。

独立してインストール可能なコンポーネントをユーザーが明確に希望した場合に限り、companion skill の個別インストールについて説明します。通常の手順では、identity-skill を1つインストールするだけで十分です。

画像生成ツールがまったくない場合は、ユーザーが GPT web Image 2 や他の画像ツールに貼り付けられるコピー用プロンプトを作成するか、独自のリファレンス画像を提供してもらいます。ユーザーがリファレンス画像を完全に省略する場合、構築の fidelity は低くなるものとして扱い、ビジュアル QA は承認済みのリファレンス画像ではなく、テキストのブリーフとの照合しかできないことを明示します。

段階提示プロトコル

ユーザー向けの各段階の最後に、進捗状況を明確に提示してください。

• 現在の進捗：第一步 / 阶段名称
• 完了したこと：直前に作成した具体的な成果
• 不足またはリスク：進行を本当に妨げる阻害要因だけを列挙
• ユーザーが今できること：確認、指定箇所の修正、不足資料の提供、または選択肢の選択
• 次の段階：次の段階名と、そこで行うことを説明

ユーザーを、明示されていない中断地点に置き去りにしないでください。確認を必須とせずにワークフローが続く場合は、続行することとその理由を明確に説明します。

第一段階：コンテンツとスタイルの確定

まず、どのコンテンツ経路が適切かを判断します。すでに提供されたファイル、リンク、履歴書、profile、メモ、執筆サンプル、プロジェクト文書、スクリーンショット、既存のウェブサイトから読み取れる情報を、ユーザーに手作業で再入力させないでください。

資料の入力経路

次のいずれかの経路を使用します。

• 資料が十分にある経路：ユーザーが履歴書、CV、LinkedIn、個人ページ、ポートフォリオ、プロジェクトリンク、Notion/Markdown 文書、自己紹介、メディアキット、ソーシャルメディアのプロフィール、執筆アーカイブ、または同様の資料を提供している場合です。アクセスできる内容を読み込み、確認済みの事実、セクションに使えるコンテンツ単位、リンク、素材、不足点を抽出します。ウェブサイトに影響する追加事項だけを尋ねます。
• 簡易ブリーフ経路：ユーザーが目標やプロフィールを提示しているものの、補足資料が少ない場合です。まず、履歴書、既存の紹介文、プロジェクトリンク、執筆リンク、写真、参考ウェブサイト、スクリーンショットなど、より手間の少ない入力を提供するよう案内します。ファイルを提供したくない場合は、以下のガイド質問を使います。
• ゼロから始める経路：ユーザーに資料がない場合、またはゼロから整理したい場合です。ガイド質問を一度にまとめて提示し、質問を一つずつ続ける長いインタビューは避けます。
• クイックデモ経路：ユーザーが速度や粗いプロトタイプを明確に重視する場合です。軽量なモックコンテンツを使用できますが、創作した事実、プロジェクト、引用、指標、リンク、自己紹介の詳細はすべてプレースホルダーとして明示し、正式版の前に差し替える必要があります。

ガイド質問では、以下を簡潔に集めます。

• 目的：履歴書、就職活動、ポートフォリオ、クリエイター／個人ブランド、コンサルタント、創業者／経営幹部の紹介、講演／メディア掲載ページ、その他
• 対象者：誰が訪問し、閲覧後に何をしてほしいか
• ポジショニング：肩書き、覚えてもらいたい一言、トーンの境界
• 実績・証拠：職歴、プロジェクト、執筆、製品、顧客、メディア掲載、講演、受賞、その他の根拠
• プロジェクトの詳細：重要なプロジェクトごとの背景、担当した役割／行動、成果、リンク／メディア、他者に覚えてほしいこと
• 素材と制約：プロフィール写真、ロゴ、スクリーンショット、文書、リンク、利用できない情報や機密情報、生成または誇張してはならない内容
• ユーザーの希望：サイトの情報密度、1ページか複数ページかの希望、好みの参考例、好まないスタイル、今後のメンテナンス意欲

内容与站点形态文档

对于精致个人网站、个人 IP 网站、作品集、Awwwards 级方向，或任何设计质量重要的场景，进入图片前先产出内容与站点形态文档。快速 demo 可以保留同样结构，但写得更短。

文档应包括：

• 资料覆盖：使用了哪些文件、链接、笔记或用户回答
• 已确认事实：只写用户提供或来源支持的事实
• 未确认草稿内容：清楚标记 agent 提议的文案、示例、占位、推断 claim 或缺失链接
• 站点目标与受众：这个网站要完成什么、给谁看
• 访客记忆点：访客应该记住的一到三件事
• 站点形态推荐：单页、一页简历、首页加 case study、多页作品集、创作者 hub、顾问 landing page，或其他形态
• 推荐理由：为什么这个形态适合用户目标、内容量、证明深度和维护意愿
• 可选替代方案：可行但不如主推荐的更轻或更完整结构
• section 规划：每个 section 的目的、必需内容、内容单元、链接/素材和状态（ready、needs detail、placeholder 或 cut）
• 内容充分性风险：空泛、模板化、虚假、拥挤、缺少支撑或不值得保留的 section

站点形态必须根据用户目标和资料密度推荐，不要默认套五六个 section。简历或求职用途通常只需要单页或一到两页。深度作品集可能需要 case-study route。创作者、创始人或顾问网站只有在内容支撑时，才需要更强叙事或转化路径。

用于参考图的所有内容都必须来自用户提供或用户明确批准。agent 可以提出内容来补缺口，但这些内容只是草稿，不是已确认事实。不要因为内容写得合理或好看，就把 agent 提议内容当作已确认。

第二步确认前，先锁定每个可识别人物、公司、产品、作品、出版物或项目的证据来源策略。尽早收集可用的用户素材或官方素材，让参考图直接围绕真实证据构图；不要先确认一个更强的生成占位构图，再计划在锁定后替换成视觉重量、比例或主体不同的官方素材。

风格推荐

内容和站点形态足够清楚后，基于内容、用户偏好、受众、网站目的和已有参考，推荐最多三种视觉方向。用户可以选择一种、混合多个选项，或提供自己的视觉方向/参考。

风格选项必须是视觉概念，而不只是定位标签。不要只给“国际学生精品简历”“金融科技产品研究员”“AI + Finance Portfolio”这类只区分受众或职业叙事的选项。这些标签可以解释为什么适合，但选项本身必须让用户在生成图片前就能想象页面长什么样。

每个风格选项应简要覆盖：

• 视觉概念名：用短标签描述画面气质，而不是只写个人角色
• 情绪和定位匹配
• 色彩方向：3-5 个具体颜色或颜色角色，必要时给 hex
• 字体气质：display/body 的字体性格和粗细对比
• 首屏构图：姓名、headline、头像/媒体、CTA、证明线索分别如何出现
• 布局密度与 section 节奏：单页克制、editorial 节奏、bento 证明块、case-study 深度，或其他具体节奏
• 图片或素材处理方式：头像裁切、项目截图、文档卡片、数据视觉、editorial 照片、抽象背景或代码渲染图形
• UI chrome 与导航感觉：header 密度、wordmark、CTA 形状、边框、圆角、icon 风格和 active state
• 动效性格
• 用户会看到什么：用一句话描述屏幕直观印象
• 为什么适合这个人和这种站点形态
• 主要风险或取舍

如果某个风格选项不能被描述成一个可见的网站画面，先重写再展示给用户。如果用户目标是职业定位，要把定位翻译成视觉决策，而不是让选项标题承担全部表达。

必要时使用这个紧凑的风格选项格式：

选项 A — Editorial Resume / 墨色纸感
色彩：暖白 #F7F3EC、墨黑 #171717、灰蓝 #6B7280、强调蓝 #2563EB。
字体：克制 serif display + 干净 sans body；专业但不装饰化。
首屏：姓名和一句定位左对齐，置于大面积纸感留白中；右侧是安静裁切的头像或 LinkedIn 风格照片，下方放两个证明链接。
节奏：单页简历流，section 平静，项目证明用小型卡片承载。
直观感受：像一份精致的国际候选人 editorial CV，而不是创业公司 landing page。
风险：如果用户想要更强个人品牌，会显得辨识度偏弱。

在用户确认完整内容与风格 brief 之前，不要生成参考图。如果用户选择了风格选项且没有反对内容文档，只有在你的提示明确说明“这会同时锁定内容和风格”时，才把该回复视为第一次阻塞确认。

使用这个第一步收尾提示形态：

当前进度：第一步 / 内容与风格锁定
我已经准备好：资料来源摘要、已确认事实、站点形态推荐、section 规划、内容风险和风格选项。
请确认或修改：
1. 站点形态和 section 规划
2. 所有标记为未确认的内容
3. 视觉方向：选择一个选项、混合多个选项、修改色彩/布局，或提供你自己的参考
确认后，我会进入第二步，生成或准备各 section 的参考图。

第二步：参考图锁定

使用 section 级参考图作为视觉事实来源。

参考图 prompt 必须基于已确认的内容与风格 brief：已批准内容、已批准站点形态、已选择或用户提供的视觉方向、全局 chrome 规则，以及每个 section 的具体内容单元。用户期待高质量个人网站时，不要基于薄 brief 或未批准的 agent 提议内容生成参考图。

本阶段始终读取 references/imagegen-frontend-web.md。如果独立 imagegen-frontend-web 可用，在内置个人网站硬契约下使用它补充更广的 art direction。参考图组必须做到每个已确认 section 一张横向图、强构图、统一个人 IP 世界，以及可以真正实现的图片拓扑。

如果用户偏好 GPT web Image 2，则为用户写可复制过去的 prompt，而不是直接生成图片。

参考图生成计划

生成任何 section 前，先准备一份简洁的参考图生成计划。它属于第二步内部 artifact，不增加新的用户确认门。已有项目目录时，把它写入还原文档或小型 docs/reference-production-plan.md；没有目录时，保留在第二步工作输出中。

先锁定整组共用的 style fingerprint：

• 精确色彩角色与 hex 值
• display/body/label/nav 字体角色和相对字号
• 全局 chrome 几何、边框/圆角/阴影语言和 CTA 家族
• 材质、光线、纹理、照片调色、插画/icon 语言
• 密度范围、间距节奏、画布比例，以及最多一个可选 signature motif
• 不允许漂移的常量，以及每个 section 允许变化的一到两个维度

然后给每个 section 指定一份 render contract：

• C0 code-only：字体、布局和简单几何，不需要 raster 素材
• C1 integrated-scene：代码 UI 叠加在一张融合场景上；场景可以 full-bleed，也可以是有边界的视觉岛
• C2 independent-media：代码外壳加一到三个有独立意义的照片、截图、封面或产品 mock
• C3 scene-plus-identity：一张融合场景，加一张真实来源或 replace-later 的头像、logo、官方产品图

每份 render contract 必须写清：代码负责内容、允许的全站 shared material、融合场景边界、独立媒体槽、身份/真实来源素材、禁止融合项、响应式行为、文字安全区、素材预算，以及拓扑归属（section-specific 或命名并说明理由的共享结构）。高质量目标还必须补齐 references/visual-quality-gate.md 的 meaning 字段：三秒信息、个人证据、作者性设计动作、焦点层级、阅读路径、留白地图、语义图形含义、重叠清单、封闭排除区和首屏有效载荷。C0 code-only 表示 0 个 section 专属 raster；如果纸面或扫描条属于已锁定 fingerprint，可以复用一到两个显式声明的全站材质。但它不代表一个内容不足、只靠大字撑满高度的 section 已经完成：除大字外还必须有第二个来自内容的设计决策，否则缩短、合并或重设计该 section。每种 shared material 只生成一次、全站只计一次。默认每个 section 一个主视觉焦点、最多一张融合场景、section 专属 raster 单元不超过三个；只有用户明确批准 dense evidence-wall 方向时才能超出。

先生成最能定义身份的 anchor section，通常是 Hero。后续 section 在同一批次生成；图片工具支持参考输入时，必须把 anchor 作为视觉指导，否则逐字复用同一份 style fingerprint。anchor 与后续图片之间不增加额外确认门。

默认输出：

• 每个 section 一张横向参考图
• 不要长竖版整页拼贴
• 不要细碎难读的多 section board
• 所有 section 保持一致的个人 IP 世界观
• 参考图应像真实网站截图，不像海报
• 代码负责的文字和控件要能与 raster 材质干净分离
• 静态融合场景保持为一个完整视觉单元；独立媒体槽之间不得出现跨边界阴影、反射或遮挡

把参考图组交给用户确认前，运行四重审查：

1. 视觉意义审查：执行 references/visual-quality-gate.md 的全部硬门槛，包括三秒传达、单一第一焦点、有目的的元素清单、个人特异性、完成的构图、密度上下限、有意义留白、图形语义、裁切完整性、重叠安全和响应式首屏有效载荷。一个 section 即使漂亮或可实现，只要想法、证据或构图薄弱，仍然失败。
2. 一致性审查：把每张图与精确 style fingerprint 对照，检查全局导航、字体角色、色板、间距、框体语言、图片调色、motif 和移动端逻辑。必须让人一眼看出属于同一网站。
3. 节奏审查：列出每个 section 的构图骨架并检查 variation envelope。可以有节制地变化 section 任务、尺度、对齐、裁切或密度，但不要强迫每屏成为全新视觉概念。运行 grey-block test：照片变成灰块后，至少一半 section 仍应通过字体、布局、色彩和结构保持设计感。
4. 可实施性审查：把每张图与 render contract 对照。如果代码文字与 raster 材质不可分离、独立素材共享硬阴影/遮挡、身份素材被融进生成场景、响应式重排需要在单张图内部搬动像素、未经批准超过素材预算，或出现计划外图片岛，该 section 失败。

参考图拓扑失败时使用 redesign-required：保持全站 style fingerprint，只重生成失败 section，再交给用户确认。不要把不可实施的参考图硬塞进第三步，用脆弱切片或低保真代码替代来补救。

审查通过的参考组确认后，把它复制进新的不可覆盖目录，例如 references/locked/v1/，并把每张图的 SHA-256 写进 docs/identity-evidence.json。不要覆盖已锁定文件；重生成或重构必须创建新版本并重新执行受影响的第二步审查。

当设计质量重要，或用户要求 taste guidance 时，同时读取 references/taste-calibration.md 和 references/visual-quality-gate.md。taste 样本负责校准可选视觉世界，质量门槛负责判断这个世界是否真正表达清楚并完成了设计。

使用这个第二步收尾提示形态：

当前进度：第二步 / 参考图锁定
我已经准备好：全站 style fingerprint、每个 section 的 meaning 与 render contract、参考图，以及视觉意义/一致性/节奏/可实施性审查。
请确认或修改：
1. 接受这些图片作为构建目标
2. 指定要重新生成的 section
3. 在构建前调整视觉方向
图片确认后，我会进入第三步，正式产出素材拆分清单：哪些留在代码里、哪些是一张融合场景、哪些是独立媒体、哪些必须用真实来源、哪些需要 blocked、replace-later 或 redesign-required。我会等你确认后再生成或查找新素材。

第三步：素材拆分清单

参考图组确认后，先检查已接受参考图，不要生成素材，也不要写代码。本阶段产出给用户看的素材拆分清单，并停下来等待确认。

产出清单前，如果已安装 reference-asset-splitter，读取它和 references/split-patterns.md；否则读取内置 references/reference-asset-splitter.md 与 references/split-patterns.md。按顺序执行三轴 classifier：边界颗粒度、渲染介质、图片层级。不要把三件事压成一句“看起来很复杂”。

使用固定冲突优先级：真实身份/来源素材；live semantic 内容与无障碍；独立交互/替换/更新/响应式重排；code whitelist 与 raster signals；fusion 关系；素材预算；最后才是审美偏好。视觉复杂度本身既不能强制细拆，也不能证明代码可以高保真复刻。

目标是实用，不是过度规格化：告诉用户哪些可见部分应该留在代码里，哪些需要单独生成或收集素材，哪些需要透明/前景素材，哪些属于背景，哪些真实资产不能伪造，以及哪些判断一旦猜错会影响最后复刻效果。

本阶段创建或更新一个可见还原 artifact。可接受形式包括：

• docs/restoration-plan.md，合并参考图映射、素材 manifest 和后续复刻执行 brief
• docs/reference-to-build-map.md 加 docs/asset-manifest.md
• 如果仓库已有 docs 约定，也可以使用等价的项目内文档

artifact 必须在素材生成前、页面代码编辑前落地。它必须列出每张已确认参考图和每个 section/page。只在聊天里总结、隐藏推理或用一句进度提示说明，不满足要求。

给用户看的素材拆分清单应比内部 artifact 更短。每个 section 包括：

• 代码负责元素：文本、导航、按钮、布局、简单形状、标签，以及需要可编辑的动效
• 全站 shared material：可选的纸面、颗粒、扫描条或其他只生成一次并复用的 fingerprint 材质，或 none
• 融合场景素材：整段背景或有边界的融合场景、纹理、地图、照片场、桌面世界、卡片拼贴，或 none
• 独立媒体素材：头像、产品 mock、截图、照片、封面、单体插画，或 none
• 已有真实素材：用户提供照片、logo、产品截图、官方素材，或待复制的源文件
• 可生成素材：安全可生成的氛围图、装饰物、抽象产品 mock、背景或 stand-in
• blocked、replace-later 或 redesign-required：真实人物、官方品牌/logo/产品图、带 claim 的缺失截图，或无法忠实分层的参考图拓扑
• 为什么重要：如果素材边界判断错误，会造成什么复刻 fidelity 风险

素材边界规则

准备第三步素材拆分清单和第四步素材生成审核时，使用以下规则。

参考图存在后、写代码前，把三个判断轴分开执行：

1. 边界：只有独立交互、替换/更新、独立语义或响应式重排才强制细拆。移除代码节点和强制独立节点后，把存在叠压、跨物体阴影/反射、连续纹理、透视、光线或材质关系的静态 raster 物件合并。同一个 fusion group 默认一张素材，不看里面能数出几张卡片。
2. 介质：只有 live text、DOM 布局、纯色、普通边框/圆角/阴影、简单 CSS gradient、标准 icon、基础 grid/dot 和简单 SVG 几何可以 code-native。照片、不规则材质、手写/笔刷、复杂插画、密集 UI/product mock、自然纹理、3D、真实光影/反射或共享 raster 效果必须用图片。既需要 live 行为又需要 raster fidelity 时，用 hybrid：图片负责视觉，代码负责外壳、文字和交互。
3. 层级：integrated-scene 是与 section 绑定的一张融合视觉，可以 full-bleed，也可以只占 Hero 右侧；independent-media 是可独立替换的照片、截图、封面、mock、头像或单体插画。透明与否不决定分类。

默认每个 section 最多一张融合场景，raster 单元总数不超过三个。独立媒体槽各自成素材，融合静态群保持一张。所有最终文字、导航、按钮、表单、事实数据和交互留在代码里。允许整屏艺术背景，不允许把代码负责内容一起烘成整屏截图。

当 live text 无法从材质里分离、交互元素与另一层共享硬阴影/遮挡、真实身份素材不可逆地融入生成场景、移动端需要在单张图内部独立搬动像素，或重组依赖脆弱像素接缝时，使用 redesign-required，不要强拆。保持 style fingerprint，只把这个 section 退回第二步重生成。

每张已确认参考图都要在可见还原 artifact 中记录 reference-to-build map：

Reference: 01-hero.png
Code layer: nav、headline、subhead、CTA group、portrait frame、proof labels
Integrated scene: hero-finance-desk.png，16:9，full-bleed，允许深色遮罩
Independent media: portrait.png，右侧 24% 宽；product-card-mock.png，下方中间 22% 宽
Must preserve: 深色桌面/金融照片氛围、左侧大标题比例、右侧头像卡、绿色 CTA、顶部导航间距
Allowed deviation: 生成图里的图表标签改为代码渲染的已确认文案
Risk trigger: 未确认的真实公司标记或用户头像需要先确认

每个 section 都必须覆盖所有有意义区域：semantic role、boundary triggers、code whitelist 结果、raster signals、fusion group、owner（code 或 asset）、placement（integrated-scene、independent-media 或 none）、reuse scope（global 或 section）、provenance、responsive mode、decision/status（ready、generate、find/copy、code-native、replace-later、blocked 或 redesign-required）、source/action 和 final path。若没有 section 专属图片，直接写清原因，并单列复用的 shared material。

记录素材 manifest（asset、role、boundary trigger、raster signal、fusion group、placement、reuse scope、provenance、reference box、aspect ratio、relative size、responsive mode、status、final path），这样复刻时可以把每个素材放进固定宽高比容器，而不是让图片原始尺寸驱动布局。

使用这个第三步收尾提示形态：

当前进度：第三步 / 素材拆分清单
我已经准备好：reference-to-build map、素材决策清单和初版 asset manifest。
请确认或修改：
1. 哪些元素保持 code-native
2. 哪些融合场景和独立媒体要生成、复制或 replace-later
3. 哪些真实头像、logo、产品截图或官方素材不能生成
4. 清单里真正存在歧义的交互或替换假设
确认后，我会进入第四步，只生成或整理已批准的素材。我还不会编辑页面代码。有用时我可以并行处理已批准的素材组；如果你希望顺序执行，请直接说明。

ステップ4：素材の生成とレビュー

素材の分割リストが確定したら、承認済みの素材のみを生成、コピー、検索、または整理します。その後、素材の結果と簡潔な再現実行ブリーフをユーザーに提示します。ユーザーが素材レビューを承認するまでは、ページのコード実装を開始しないでください。

素材レビューには、以下を含めます。

• 各 ready 素材の最終パス
• 各素材がどの section と、どの可視要素に対応するか
• 出所：生成、ユーザー提供、公式／コピー、code-native、または replace-later
• 検査結果：accepted、needs regeneration、weak but usable with named deviation、blocked、または replace-later placeholder
• 素材を再現するために必要な prompt/source notes

各画像素材に認められる出所は、次の2種類のみです。

1. ステップ1の intake ですでに収集した実素材（ユーザーの写真、logo、製品のスクリーンショット、メディアファイルなど）。ステップ4で新たな素材の提供を求めないでください。ただし、ユーザー自身が提供を選んだ場合を除きます。この段階までに提供されていない内容は、stand-in を生成する、code-native placeholder を使用する、replace-later としてマークする、または誤解を招く場合は blocked としてマークしてください。
2. 新しい画像の生成：対応する参照領域を基準にする必要があります。生成 prompt を書く前に、確定済みの参照画像をもう一度開き、対象領域を視覚的なチェックリストとして書き起こします。シーンの種類（紙カードのコラージュ／写真のシーン／フラットなイラスト／UI mock／テクスチャのフィールド）、主要な物体とおおよその位置、カラーパレットの hex 値、光、素材感、余白のレイアウトを記録します。生成 prompt はこの書き起こしから作成してください。シーンの種類、物体のリスト、構図、カラーパレットを一致させます。素材名や分割リストの1行要約から作成してはいけません。画像生成ツールが画像入力に対応している場合は、参照領域も視覚的な参照として添付します。書き起こしをせず、内容のカテゴリ（「机に座るクリエイターとノートパソコン、カード」）だけを記述した prompt は不備です。モデルに別のシーンを独自に作り出すことを許すのと同じだからです。素材内のプレースホルダーテキストには "abstract unreadable placeholder bars and squiggles" と指定してください。"greeked" という語は使わないでください。画像生成モデルがギリシャ語の文字だと文字どおりに解釈する可能性があります。

確定済みの参照画像は、構築目標であり QA の基準であって、素材の出所ではありません。参照画像の領域を crop、screenshot、slice、または extract して構築に使わないでください。切り抜くと、低解像度、焼き込み済みの文字、切り口の乱れを引き継ぎます。manifest に extract という状態はありません。参照領域に素材が必要な場合は、その要素を視覚的な説明に基づいて再生成するか、実際の出所がある素材に置き換えます。

対応する section の構築を開始する前に、承認済みの素材をすべて準備してください。安定した名前でプロジェクトの素材ディレクトリに保存し、元の生成 ID をそのまま使わないでください。各素材を生成したらすぐに、参照領域およびステップ2の render contract と並べ、以下の6つの観点で比較します。シーンの種類、物体のリスト、構図と余白、カラーパレットと光、コードが担う内容との明確な分離、forbidden-fusion に違反する境界越しの影／遮蔽／反射がないこと。シーンの種類が一致しない、主要な物体が2つ以上欠けている、コードで実装する UI が焼き込まれている、または禁止された融合ルールに違反している場合は、自動的に再生成します。ready として納品してはいけません。その他の不備についても、再生成するか、素材レビューで明確に記載してください。不備を隠すために CSS blend、filter、mask を使わないでください。

融合シーンでは、あらかじめ定めたテキスト安全領域を備え、最終的なウェブサイトの文言を含まない clean visual plate を生成します。独立したメディアは、記録されたアスペクト比と意味上の境界を維持してください。素材が確定済みの render contract を満たせない場合は、該当する section を redesign-required としてステップ2に差し戻します。素材生成の段階で、別の分割方法を密かに作り出さないでください。

最終成果物または実素材の出所が、確定済みの参照画像と比べて、主役、出所、メディアの種類、シルエット、アスペクト比、切り抜き、視覚的な重み、独立した意味主体の数、フォーカスの階層、主要な色のかたまり、レスポンシブ時の挙動、または個人の claim を変更する場合は、該当する section を reference-invalidated としてマークします。実装前にステップ2へ戻り、参照画像を再生成または再構成してください。目標が構造的に変わったことを intentional deviation で覆い隠してはいけません。

必須の承認済み素材が generate または find/copy の状態にある間は、ページコードを書かないでください。まず ready にするか、理由を示して code-native に変更し、それをユーザーに明示するか、承認済みの placeholder を使って replace-later としてマークするか、blocked として一時停止してください。

有用で、現在の環境が許可する場合は、ステップ3で承認された範囲内で素材生成のサブエージェントを並行して実行できます。section または素材グループごとに分割してください。サブエージェントの出力は、親セッションが確認するまで信頼できるものとして扱ってはいけません。

再現実行ブリーフは、以前の lightweight pre-build design note に代わるものです。簡潔にまとめて素材レビューに添付し、別途新たな確認事項を設けないでください。以下を明確にします。

• 現在の build owner と出所：インストール済みの frontend-app-builder skill のパス／名称、または references/frontend-app-builder.md fallback
• 主な視覚的基準と section の順序
• グローバル chrome：ナビゲーション、logo／wordmark の扱い、header の密度、active state、モバイルでの挙動
• フォントの固定：display、body、label、nav の各役割で一貫性を保つこと
• カラーパレットの固定：確定済みの参照画像から正確な hex token（主色、二次色、アクセント色、ニュートラルの階調）を抽出すること。納品素材の実際のピクセルがこれとずれる場合は、素材に合わせて token を修正します。素材の焼き込みは変更しにくく、コードは調整しやすいためです。実装レイヤーではこれらを design token として定義し、token のみを使用します。section ごとに目視で色を取り直すことは禁止です。
• 必須のアニメーションやインタラクションのアイデア：体験に影響する効果のみ記載
• 最終的な素材パスとコード／素材の境界
• 許容される差異：参照との不一致、弱い素材、モバイル向けの簡略化、意図的な調整
• QA の目標：各レンダリング済み section をどの参照画像と照合するか
• リスクのトリガー：コード実装前に確認を一時停止する必要がある項目

確定済みの主役、形状、階層、意味を維持している場合に限り、差異は低リスクの許容項目に該当します。reference-invalidated となる変更は、リスクのトリガーであり、許容される差異ではありません。

ステップ4の締めくくりには、次の形式のプロンプトを使用します。

当前进度：第四步 / 素材生成审核
我已经准备好：已生成/已整理素材、最终素材路径、检查备注和复刻执行 brief。
请确认或修改：
1. 接受素材和复刻执行 brief，进入复刻
2. 重生成或替换指定素材
3. 在实现前修改任意代码/素材边界
确认后，我会进入第五步，用选定 builder 契约开始高保真复刻。

ステップ5：高忠実度の再現と QA

実装を開始できるのは、ユーザーがステップ4の素材レビューと再現実行ブリーフを承認した後のみです。

ステップ5に進む際は、まず references/evidence-gate.md を読み、次に現在の build owner を選択して明示してから、実装を開始します。

• 推奨パス：Build Web Apps の frontend-app-builder skill がインストールされている場合は、それを読み込み、Before Coding、Implementation、Verification、Final Response のフローに従って、構造化された image-to-code の再現を行います。この skill には、内容／スタイルのブリーフ、確定済みの参照画像、確定済みの素材 manifest、再現実行ブリーフ、リスクの確認事項が含まれます。
• fallback パス：builder がインストールされていない場合は、references/frontend-app-builder.md を読み込み、組み込みの再現契約に従って実行します。

ステップ5を一般的な手書きのページ作成にしてはいけません。builder パスを、再現実行ブリーフと最終的な fidelity ledger に反映させてください。

実装を開始できるのは、確定済みの参照画像ごとに reference-to-build map があり、必須の視覚素材がすべて ready、明確に code-native、または承認済みの placeholder を使って replace-later としてマークされている場合のみです。参照画像をプロジェクトディレクトリにコピーしただけで、「ステップ2を実施した」証拠としてはいけません。参照画像は照合目標として使うか、実際の構築入力に分解する必要があります。

高忠実度の再現

参考画像が承認済みで、再現用アーティファクトが存在し、必要な素材がすべて準備済み、または code-native／replace-later として明確に承認され、ユーザーが第4段階の素材レビューと再現実行ブリーフを承認した後にのみ、実装を開始します。

構築は builder 契約に従って管理し、このスキル内で臨機応変に進めてはいけません。第5段階に入る際は、インストール済みの Build Web Apps frontend-app-builder SKILL.md を最初から最後まで読みます。インストールされていない場合は、references/frontend-app-builder.md を読み、Before Coding、Implementation、Verification の各手順を厳密に実行します。承認済み参考画像は、その accepted concept です。このスキルの再現用アーティファクト、素材 manifest、再現実行ブリーフは、デザインシステムの抽出と実装 inventory の入力です。両者が重複する場合は、より厳格なルールに従います。

初めて実装を編集する前に、以下のすべてを確認する必要があります。

• このセッションで builder 契約を読み込んでいる
• 再現用アーティファクトが存在し、確認済みの各参考画像に対応する reference-to-build map が含まれている
• 素材 manifest が存在するか、同じアーティファクト内に含まれている
• 各必須素材の状態が ready、code-native、または承認済みの replace-later である
• 実装対象のファイルと書き込み範囲が明示されている

実装時：

• セクションの順序、レイアウト、余白のリズム、色の論理、書体の雰囲気、画像の配置を維持します
• 各前景素材を、manifest に記録されたアスペクト比と相対サイズのコンテナーに配置し、object-fit を使用します。画像の元サイズによってレイアウトが決まらないようにします
• ディスプレイ用フォントのサイズは参考画像から測定します（見出しの高さとセクション幅の比率）。感覚に頼らず、長いテキストが切り取られないことを確認します
• 各セクションの目標として承認済み参考画像を維持します。記憶や文章上の mood を頼りに実装してはいけません
• 次のセクションに進む前に、主要なコードブロックをそれぞれ承認済みのセクション視覚アンカーに対応付けます
• テキスト、ボタン、ナビゲーション、インタラクション、アニメーションはコードで実装します
• 生成素材は、実際の視覚的価値をもたらす場合にのみ使用します
• 識別しやすい参考画像を、ありきたりなテンプレートのセクションとして実装することは避けます
• あるセクションの初回レンダリングが参考画像から明らかに外れている場合は、表面的な修正だけで済ませず、作業を止めて視覚アンカーに基づいてそのセクションを再構築します

サブエージェントへの作業分担

複数のセクションやページを構築する場合は、該当する確認ゲートを通過してから、境界が明確な作業のみを並行して進めます。第2段階の後に参考画像の分析を、第3段階の後に素材の生成を、第4段階の後に実装を並行できます。サブエージェントは範囲が明確な作業に使い、複数のデザインシステムを並行して考案するために使ってはいけません。

分担に適した作業：

• 参考画像分析エージェント：各エージェントが1ページまたは複数のセクションを担当し、reference-to-build map と素材要件を作成します
• 素材生成エージェント：各エージェントが融合シーンまたは独立したメディア素材の一群を担当し、安定したファイル名と prompt／出典の説明を作成します
• ページまたはセクションの再現エージェント：重複しない書き込み範囲のみを担当し、共通のデザイントークンと、その範囲で確認済みの参考画像を使用します
• リードインテグレーター：全体の chrome、共通トークン、最終組み立て、ブラウザー QA、最終 fidelity ledger を担当します

現在の環境で利用できるネイティブのサブエージェントツールを使用します。すでに承認済みの段階と範囲に入っている作業だけを並行して進めます。プラットフォーム自体の要件でない限り、委任のためだけに新たなブロッキング確認を追加してはいけません。段階を移行する際は並行分担について説明し、ユーザーが順番どおりの実行を求めた場合は、その選択を尊重します。

サブエージェントへのメッセージには、タスク完了に必要な最小限の情報だけを含めます。ただし、メッセージはそれだけで完結している必要があります。読み込む skill／reference、style fingerprint、render contract、参考画像のパス、正確な出力ファイル名、目標アスペクト比、色の hex 値、forbidden-fusion ルール、返却契約を含めます。結果を受け取ったら、親セッションで各出力を view_image で確認し、確認後にのみ使用します。

ビジュアル QA

QA は builder 契約の Verification 手順と、references/visual-quality-gate.md 全体を使って、セクションごとに実行します。承認済みの各参考画像と対応するレンダリング済みセクションを並べて確認し、概要だけで判断してはいけません。可能であれば参考画像の元サイズでスクリーンショットを撮影し、連続スクロール時のトランジション、通常のデスクトップ、超ワイド画面、モバイルも確認します。fidelity ledger を作成し、placeholder box やコードで描いた概念素材による代替など、builder の hard stop に該当する項目は失敗として扱います。以下のチェック項目は identity-skill の補足であり、builder 契約の代わりにはなりません。

ローカルプレビュー URL が必要な場合は、portless と personal-site.localhost などのプロジェクト専用ホスト名を優先し、適切であれば小規模な再利用スクリプトまたは portless.json を追加します。portless が利用できない場合、またはユーザーが raw port を要求した場合にのみ、localhost:<port> を使用します。

確認項目：

• レイアウトの比率とセクションのリズム
• フォントサイズ、改行、間隔
• テキストが切り取られたりはみ出したりしていないこと、参考画像にない要素の重なりがないこと
• 色とコントラスト
• 各セクションが第2段階の render contract を引き続き満たしていること：予定外の raster の孤立した領域がないこと、融合シーンが欠落していないこと、コードのテキストが画像に埋め込まれていないこと、forbidden-fusion に違反していないこと
• 素材の位置、アスペクト比、トリミングが asset manifest に合致していること
• 実装の説明がなくても、3秒で伝わる情報、個人の実績を示す根拠、作り手としてのデザイン上の工夫、単一の第一注目点が成立していること
• 大きな余白が、実際のレンダリングサイズでも whitespace map に記録された機能を果たしていること。固定高コンテナーの内容が不足している場合は失敗とします
• すべての diagram、orbit、node、line、arrow、chart が、semantic-graphic contract に記録された実際の関係を表現していること
• desktop、ultrawide、mobile で、主体の安全なトリミング、閉じた除外領域、ファーストビューの有効なコンテンツ、carousel の初期状態、独立した意味を持つメディアの重なりがすべて問題ないこと
• 素材やコンテンツの差し替えによって、確認済み参考画像が無効になっていないこと
• ボタン、ナビゲーション、hover、アニメーションの動作
• モバイルとデスクトップでの一貫性

納品前に、セクションごとの簡潔な fidelity ledger を作成します。以下を含めます：セクション、参考画像ファイル、維持すべき視覚アンカー、ビジュアル品質のハードゲートを満たす証拠、レンダリングの証拠、測定上の差異、および pass、fix、reference-invalidated のいずれか。主体、形状、階層、意味を維持する明確な低リスクの変更である場合に限り、intentional deviation を記載できます。ハードゲート未達または明らかな差異が残っている場合は、修正を続けます。frontend-app-builder が有効な場合は、そのブラウザーおよびスクリーンショット比較の手順に従います。

docs/identity-evidence.json と、すべてのセクションを網羅する docs/fresh-review.md も作成し、その後 python3 <identity-skill>/scripts/verify_identity_run.py <project-root> を実行します。コマンドの終了コードが 0 であり、セクションごとの画像のペアレビューにも実際に合格した場合にのみ、納品するか、対象を完了としてマークできます。検証ツールが証明するのは証拠が揃っていることだけであり、視覚的な判断の代わりにはなりません。

実装したページが文章上のテーマにはおおむね合致していても、承認済み参考画像に合致していない場合は、機能的で見栄えがよく、内部で一貫していたとしても、QA では失敗とみなします。

ユーザー確認ポイント

デフォルトでは、以下の時点でのみ作業を止めて確認を求めます。

1. コンテンツとスタイルのブリーフが完成した後、参考画像用の prompt または画像を生成する前
2. 参考画像のグループ化とレビューが完了した後、素材生成を始める前
3. 素材の分割リストが完成した後、新しい素材の生成、コピー、検索、整理を行う前
4. 生成または整理した素材と再現実行ブリーフが完成した後、ページのコード実装を始める前

以前の lightweight pre-build design note のために、デフォルトの確認ポイントを別途追加してはいけません。これは第4段階の再現実行ブリーフに統合されています。ユーザーは、より細かな管理や、確認回数の削減を明示的に求めることができます。

ユーザーが中間確認を行わないこと、またはデフォルトで推奨案を採用することを求めた場合は、待機だけを省略します。レビュー、上書き不可の参考画像ロック、証拠の作成、fresh review、決定論的な検証はすべて完全に実行します。自動で続行しても、自動的に合格となるわけではありません。

Taste の扱い

付属の taste サンプルは調整用の参考であり、必須のスタイルではありません。

ユーザーが高品質な個人サイトを求めている一方で、ビジュアルの方向性をあまり指定していない場合に使用します。ユーザーが参考画像を提供している場合は、ユーザーの画像を優先し、付属サンプルは質の低い AI の定番表現を避けるためだけに使用します。

ブリーフが求めていない限り、濃い青を基調とするシネマティックなスタイルを無理に適用してはいけません。基盤となる taste の原則だけを取り入れます。明快な構図、抑制された配色、存在感のある書体、映画的なリズム、十分な余白、意味のない視覚的ノイズがないことです。