optimize

ページを最適化する

既存のページに対して /plan-page と /design-page を使用します。公開中のページを読み込み、新規ページの構築に用いるルールに照らして評価し、新規ページと同じ計画ブロック（最終コピー、セクションごとのアセット判断、クレームゲート、作業キュー）を作成します。承認を待ってから、承認済みの変更を保存済みのソースに適用し、ホストされたドラフトを確認します。公開はしないでください。

参照資料

参照資料	読むタイミング
references/plan-page.md	常に。再利用する共通ブロックの用語（アセットスロットの判断、クレームゲート、作業キューの担当者、ステータスラベル）
references/evidence-led-cro.md、references/consumer-behavior-cro.md	証拠に基づく順序付けと、行動に関する仮説を1つ立てるとき
references/offers/offer-strategy.md	ポジショニング、オファーの価値、構成、価格設定を診断するとき
references/industry-cro.md の該当セクション	業界が判明しているとき
references/page-types/_index.md、次にページタイプのファイル	ページを該当タイプの要件（ファーストビュー、証拠、オファーとCTA、画像、コピー、禁止事項、チェックリスト）に照らして評価するとき
references/design-rules.md	N1〜N14 と A1〜A12 を評価するとき
references/proof/proof-ledger.md、references/offers/offer-ledger.md	ページに表示されている情報から各台帳を再構成するとき
references/workflows/section-asset-workflow.md のセクション2	ページ上のすべての画像の適合性を確認するとき
references/copy/headline-and-cta-rules.md、references/anti-patterns/copy-anti-patterns.md	コピーを評価するとき
references/anti-patterns/mobile-anti-patterns.md、references/anti-patterns/cro-anti-patterns.md	モバイル対応とCRO上の問題点を評価するとき
references/assets/generation-policy.md	生成または合成するアセットを提案する前
references/page-editing.md、references/qa-recipe.md、references/source-artifact-workflow.md	承認済みの変更を適用し、ホストされたドラフトを確認するとき
references/authoring/css-and-styling.md、references/animation-system.md	CSS、クラス、モーションを変更する前
references/lexsis-design-capabilities.md	より詳しいデザインガイダンスが必要な場合（任意）

lexsis_pages.edit_context、lexsis_pages.get、lexsis_pages.inspect、 lexsis_pages.source、lexsis_pages.section_source、lexsis_pages.compile、 lexsis_pages.integrity、lexsis_pages.diff、lexsis_pages.qa、 lexsis_analytics.page、lexsis_analytics.timeseries、 lexsis_analytics.attribution、lexsis_catalog.get、lexsis_catalog.reviews、 lexsis_assets.view、lexsis_asset_library.search、 lexsis_asset_select.select、 lexsis_asset_import.import、lexsis_asset_upload.upload、 lexsis_workspace.credits、lexsis_drafts.asset_generate、 lexsis_template_library.search_page_kits、 lexsis_template_library.search_sections、 lexsis_drafts.page_update_section、lexsis_drafts.page_patch、および lexsis_drafts.page_record_qa を使用します。不明なスキーマの解決には、正確なルーター／アクションの検出のみを使用してください。ディレクトリ検索で結果が0件でも、ページや分析データを取得できないことにはなりません。実際のライブデータ読み込みに失敗した場合は、その制約を明示してください。一般的なCROガイダンスをライブデータの代わりにしてはいけません。

目的を確認する

まず、次の項目を確認します。

1. 目標とする成果：コンバージョン、カート追加、AOV、直帰率、信頼性、モバイルUX、速度、またはSEO。
2. 対象ページ、オーディエンス、トラフィックソース。
3. 診断のみか、承認後の編集権限も含むか。
4. 変更せずに維持する必要があるコピー、セクション、SEOフィールド、またはオファー。

目的と範囲が明確になるまで編集しないでください。保存済みの設定または現在のMCPコンテキストから、ページに紐づくワークスペース、ストア、テーマを確認してください。不明な場合は、Run /setup for this store and theme first. と伝えて停止します。セットアップを自動的に実行してはいけません。

ライブページを確認する

1. lexsis_pages.edit_context、続いて lexsis_pages.get、lexsis_pages.inspect および lexsis_pages.source：現行バージョン、セクションの順序、アイランド、コピー、 メディア、head。
2. lexsis_analytics.page、.timeseries、.attribution で成果の 計測期間を確認します：コンバージョン、直帰率、デバイス別内訳、セクションごとの離脱、 トラフィックソース。分析データと観察された行動は、一般的なパターンより優先します。
3. ホストブラウザーで390、768、1280の各幅を確認します：スクリーンショット、ファーストビュー、固定 要素、ハイドレーション、コンソール。
4. ページに表示されるすべての画像に対して lexsis_assets.view を実行します：対象、用途、トリミング、 画像に埋め込まれたテキストや透かし、セット内の一貫性。ファイル名は根拠になりません。
5. ページで訴求している商品と根拠について、lexsis_catalog.get と lexsis_catalog.reviews を確認します。
6. ライブ構造とブリーフから、references/page-types/_index.md を使ってページタイプを特定し、そのタイプのファイルだけを読み込みます。

スコア

まずスコアカードを記入します。各行にルールの参照元と所見を記載してください。

## Scorecard

| Area | Rule source | Result | Blocking findings | Notes |
|---|---|---|---|---|
| Page type contract | <type>.md checklist, Above the fold | 7/10 | price below 1.5 screens at 390 (A8) | |
| House rules | design-rules N1-N14, A1-A12 | 11/14 | N2 band in benefits, N1 emoji in trust strip | |
| Proof | proof-ledger per-kind table | 2 verified / 3 unledgered | "50,000 customers" has no source | |
| Offer | offer-ledger rules 1-6 | ... | compare-at without basis (O2) | |
| Assets | section-asset-workflow section 2 | 5 pass / 2 fail | hero carries a baked-in ad headline -> reference-only | |
| Copy | copy-frameworks CF5, headline HC rules, copy blacklist | ... | h1 14 words; "seamless" x3 | |
| Mobile | mobile-anti-patterns | ... | sticky bars 22% of viewport | |
| CRO anti-patterns | cro-anti-patterns | ... | | |
| Analytics | evidence-led-cro | CVR, bounce, device split, drop-off section | | |

根拠とオファーに関する所見を記載します。ページ独自のプランに記録されていない限り、タイプからの逸脱とコピーに関する所見はレビュー注記とします。references/consumer-behavior-cro.md を使い、訪問者のモード、未解決の最重要な判断事項、最小限の行動仮説を特定します。

オファー価値に関する所見

ポジショニング、オファー価値、構成、または価格が対象となる場合は、references/offers/offer-strategy.md を使います。価値訴求の弱さ、根拠の不足、条件のわかりにくさ、購入時の摩擦を区別します。それぞれ必要な対応が異なります。関連する根拠を記録し、オファーを実質的に再設計する場合は、「Page strategy」の7つの価値戦略項目をすべて記入します。

固定されたオファーとキャンペーンの約束は維持してください。未確認の商業的な代替案は、最終的な差し替えコピーと分けてください。利益率が不明な場合に制限されるのは収益性に関する結論であり、既存の有効なオファーではありません。オファーの効果低下を診断する前に、トラフィックの構成、在庫、季節性、トラッキングを確認してください。

コピー、レイアウト、速度、メタデータの無関係な修正に、戦略の書き換えを求めないでください。以前に承認されたプランは引き続き使用できます。承認済みの対象範囲が変更されない限り、その訴求内容を引き継いでください。

セクションごとの所見

セクションごとに1項目をページ順に記載し、/plan-page と同じコピー項目を使います。差し替えテキストはブリーフではなく、確定稿にしてください。

## Findings by section

### S3. benefits - keep | improve | replace | remove | test

**Finding.** three icon tiles on a tinted band; no image of the product in use
**Evidence.** screenshot 390 and 1280; N2, N3; drop-off 38% at this section (analytics)
**Rule.** design-rules N2, N3; <type>.md Imagery
**Proposed change.** rebuild around one in-use image per benefit
**Copy.** (only when copy changes)
- Eyebrow: <text or none>
- Headline: <text, at most 10 words, sentence case>
- Subhead: <text, at most 20 words, or none>
- Body: <paragraph(s), at most 45 words each>
- Labels / bullets: <exact strings, or none>
- CTA: "<verb + object>" -> <destination>
**Claims in this section.** <C# ids> or none
**Layout.** 1280: ... | 390: ...
**Interaction.** none | <behaviour and decision inputs>; no island names or props
**Asset.** <slot id: decision state> | none-required: <why>

主力商品の選択と、ユーザーが変更しないよう指定した要素を守ってください。コピーのみ、オファーのみ、メタデータのみ、または軽微なビジュアル変更では、テンプレート比較を強制しないでください。構造を再設計する場合は、現在の構造を関連するページキットおよびセクションと比較します（lexsis_template_library.search_page_kits、search_sections）。

アセット計画

/plan-page の定義（references/plan-page.md）どおりに ## Asset slots テーブルを記述します。提案するページ上のメディアスロットごとに1行とし、reuse-selected、shopify-product-media、user-selection-required、user-upload-required、generate-required、composite-required のいずれかを指定します。セクションの Asset 行には none-required を指定します。適合性レビューに不合格の現行画像、または画像にコピーが埋め込まれている場合は reference-only とし、差し替え先のスロット名を記載します。

## Asset slots

| Slot | Section | Role/purpose | Aspect | Decision | Source decision | Id / URL | Status |

適合性レビューに合格した既存画像は、現在のIDを指定して reuse-selected とします。1つの役割に適合する候補が複数ある場合は ## User selection を追加し、generate-required または composite-required のすべてのスロットについて /plan-page の定義どおりの形式で ## Generation briefs を追加します。生成には references/assets/generation-policy.md が適用されます。このスキルでは承認前にクレジットを消費しません。

クレームの審査

/plan-page の定義どおりに ## Claim gate テーブルを記述します。現在ページにある各クレームと提案する各クレームについて1行ずつ作成し、approved evidence available、merchant evidence required、remove from V1 のいずれかで判定します。台帳の該当行、またはそのクレームを含めずに公開するV1コピーを記載します。

## Claim gate

| # | Claim (verbatim) | Where | Gate | Evidence | V1 copy if not approved |

ライブページ上に根拠のないクレームがある場合は、ブロッキング所見とします。判定は remove from V1 または merchant evidence required とし、現状維持にしてはいけません。

Work Queue

/plan-pageで定義されている担当者（user、agent、merchant、blocked-by-evidence）を使って、## Work queueの表を記述します。タスクには、承認済みの変更、保留中のアセット、未解決の主張、適用手順、ホスト環境でのレビュー、/ab-testへの引き継ぎがあればそれもすべて含めます。

## Work queue

| # | Task | Owner | Section / slot | Unblocks | Status |

Approval

スコアカード、セクション別の調査結果、アセット枠、主張のゲート、作業キュー、保護対象の要素、測定結果を提示します。

Outcome:
Evidence:
Main friction:
Visitor mode:
Behavioral hypothesis:
Scorecard: <blocking findings n / notes m>
Changes: <keep k / improve i / replace r / remove d / test t>
Asset slots: <n verified / m planned> ; decisions: <counts per state>
Claim gate: <n approved / m merchant evidence required / k removed>
Work queue: <n open: u user / a agent / m merchant / b blocked>
Protected elements:
Expected measurement:
Experiment recommended: yes/no
Status: OPTIMIZATION_PLAN_READY | BLOCKED - evidence required

OPTIMIZATION_PLAN_READYを返します。未解決のタスクがblocked-by-evidenceの場合は、BLOCKED - evidence requiredを返します。明示的な承認を待ち、承認されたらPLAN_APPROVED <who> <date>を記録します。それまでは何も編集しません。

承認済み変更の適用

/design-pageの「既存ページの編集」と「ホスト環境でのデザインレビュー」の手順を実行します。

1. lexsis_pages.edit_contextを実行し、続いてlexsis_pages.sourceまたはlexsis_pages.section_sourceを実行します。想定外のバージョン差異があれば中止します。
2. まず、承認済みのアセットに関する判断を解決します。再利用する場合はlexsis_asset_library.searchとlexsis_assets.viewを、レビュー済みの候補からユーザーが選ぶ必要がある場合はlexsis_asset_select.selectを、提供されたファイルにはlexsis_asset_upload.uploadまたはlexsis_asset_import.importを使用します。ユーザーがバッチを確認した後、lexsis_workspace.creditsを実行し、ブリーフごとにlexsis_drafts.asset_generateを使用します。アセットをソースに取り込む前に、すべてのアセットを確認します。
3. MCPが返したソースを編集し、承認済みのコピーをそのまま配置します。ページ全体に適用するtheme_cssがあれば、それも含めて変更した入力を一度だけコンパイルします。
4. expected_versionを指定して書き込みます。1つのセクションにはlexsis_drafts.page_update_section、複数のセクションにはlexsis_drafts.page_patchを使用します。
5. lexsis_pages.diffとlexsis_pages.integrityを実行します。成功した後にのみ、記録済みのバージョンとハッシュを更新します。
6. references/qa-recipe.mdのコマースに関するチェック項目を使い、390、768、1280の各幅でホスト環境のレビューを行います。証拠をlexsis_drafts.page_record_qaで保存します。修正は同じページに対する別のバージョン付きパッチで行い、ページを置き換えることはしません。

URLとSEOフィールドは、ユーザーが変更を承認していない限り維持します。ソースの代わりにコンパイル済みの出力を編集することはありません。ホスト環境でのレビューに合格し、ユーザーが承認したら、新しいバージョンに対してDESIGN_APPROVEDを返します。/publishではそのバージョンを対象とします。

実験への引き継ぎ

変更の効果が不確かで、トラフィックが測定に十分な場合は、その変更が実証済みであるかのように提示するのではなく、/ab-test向けの焦点を絞った仮説を返します。

返却内容

承認済みの目標、スコアカードの合計、変更したセクション、ページのバージョン、検証結果、MCPの証拠、実験を推奨するかどうか、状態（OPTIMIZATION_PLAN_READYまたはDESIGN_APPROVED）を返します。