visualize

visualize — 美しく、ブランドに沿った HTML アーティファクト

解決済みのビジュアルコンテキストに基づき、templates/*/template.md の仕様に沿って自己完結型の HTML アーティファクトを生成します。既定のビジュアルコンテキストは、プロジェクトの DESIGN.md、PRODUCT.md、サイドカーの tokens.css によって提供されます。以下のアーティファクトテーマでは、ユーザーが承認した範囲内のリファレンスシステムを使用できます。共有パターンのレシピは patterns/ にあり、選択したテンプレートとユーザーの依頼に関連する場合にのみ読み込まれます。シェルの仕組みは、テンプレートで shell: <slug> が宣言されている場合に限り、自動的に読み込まれます。

ヘルパーコマンド内の $SKILL_DIR は、このインストール済み SKILL.md を含むディレクトリの絶対パスを意味します。ホストのスキル保存場所からパスを解決し、シェルで設定して引用符で囲む（"$SKILL_DIR"）か、引用符で囲んだ絶対パスに置き換えてください。ホストによっては、この環境変数がエクスポートされていない場合があります。

デザインの判断

読み手のタスクを特定し、解釈に必要な根拠や限定条件を保ちながら、重要な違いが目に見えるようにします。表現を選ぶ前に、元の資料を構成する関係性、対比、順序、判断、対象を見つけ、それを導入部、セクションのリズム、説明の基本要素に反映させます。役立つ構成上の要素がない場合は、無理に構成のアイデアを作り出すより、抑制の効いた読みやすさを優先します。

アーティファクトモードが示すのはコンテンツの利用方法であり、美的方向性ではありません。document は必ずしも編集記事の制作を意味せず、canvas も必ずしも図表の装飾を意味しません。構成、タイポグラフィ、情報密度、空間的なリズム、画像、インタラクション、色によって説得力を生み出せます。アーティファクトをデザインされたものに見せるためだけに、色合い、装飾、コンポーネントを追加しないでください。

フィードバックに対応する前に、その指摘をアーティファクトの読み手、目的、元の資料、承認済みのブリーフ（存在する場合）と照らし合わせます。実装上の不具合、既存の要件を満たせていないデザイン、要件や前提が変わったことを示す根拠を区別してください。現在の構成は解決策であり、制約ではありません。

ブリーフの範囲内で承認済みの修正を直接行います。ユーザーがまだ承認していない既定の要件変更をフィードバックが示唆する場合は、編集する前に変更案を説明し、同意を得てください。複数の構造的または視覚的な方向性が引き続き妥当な場合は、サポート範囲内で explore artifact を推奨します。方向性が定まっている場合は、通常の作成または調整のワークフローを使用します。そのワークフローの承認要件に従ってください。小さな修正に新たな検討は必要ありません。

提案された修正は、読み手のタスクに照らして総合的に判断します。すべての批評を追加要素に変えたり、差分が小さいことを適切な方向性の証拠と見なしたりしないでください。意思決定に関わる保留中の指摘は、既存のレビューまたはタスクのメモに残します。

コマンド

/visualize はコマンドまたはトピック／パスを受け取ります。

デフォルト（コマンドを指定せず、トピック／パスを指定）： テンプレートと解決済みのコンテキストを使って、自己完結型の HTML を作成します。reference/create.md を読み込みます。コードを書く前に、事前確認を行い、ユーザーの承認を得た形を確定します。エージェントが作成した概要書が、自らの承認を与えることはできません。

名前付きコマンド：

カテゴリ	コマンド	引数	内容	リファレンス
構築	teach	なし	ブランドプロファイルを初期設定（または更新）します。プロジェクトルートに DESIGN.md と PRODUCT.md を書き込みます。	reference/teach.md
構築	explore	artifact|system <topic-or-path>	1 つの成果物の表現、または新規／置換プロジェクトシステムを比較し、適用前に確認します。	reference/explore.md
調整	simplify	<path>	ピクセルを費やす価値のない装飾を取り除きます。polish に引き継ぎます。	reference/simplify.md
調整	bolder	<path>	安全または汎用的な成果物の視覚的なインパクトを強めます。polish に引き継ぎます。	reference/bolder.md
調整	quieter	<path>	汎用的にならないようにしながら、過剰な装飾を抑えます。polish に引き継ぎます。	reference/quieter.md
調整	animate	<path>	prefers-reduced-motion に準拠した、意図のある動きを加えます。polish に引き継ぎます。	reference/animate.md
調整	polish	<path>	最終的な品質チェックを行い、あらゆる観点を確認して、観点ごとの所見を報告します。他の「調整」コマンドは、これに引き継ぎます。	reference/polish.md
評価	review	<path>	決定論的検出器の所見と LLM による判断を報告します。報告のみで、ファイルは変更しません。	reference/review.md
公開	publish	<path>	MCP／CLI／HTTP の順に試しながら、成果物を display.dev にプッシュします。	reference/publish.md

例：/visualize polish ./report.html。スラッシュコマンドに対応していないホストでは、自然言語による依頼を優先します。

ルーティングのルール

1. 引数なし：上記の「コマンド」テーブルをカテゴリごとにまとめて、ユーザー向けメニューとして表示します。何をしたいか尋ねます。
2. 最初の単語がコマンドと一致する場合：実行前に、そのリファレンスを読み込みます。テーブルは手順ではありません。コマンド名の後に続くものはすべて対象です。
3. 自然言語による依頼：デザイン案の比較依頼では reference/explore.md を読み込みます。プロジェクトのアイデンティティの作成または調整では reference/teach.md を読み込みます。それ以外の作成、または既存の成果物の明示的なスタイル変更では reference/create.md を読み込みます。名前付きテーマは「成果物のテーマ」に従い、探索の段階は必要ありません。
4. 作成時の関係図ルート：事前確認で関係図が候補として初めて特定されたら、形状の確認に進む前に reference/diagram.md と、その図に必要な候補の非空間型リファレンスを 1 つ読み込みます。複数の図を含む成果物では、候補となるファミリーごとに 1 つずつ読み込みます：reference/diagram-flow.md、reference/diagram-system.md、reference/diagram-sequence.md、reference/diagram-state.md、または reference/diagram-hierarchy.md。空間図では reference/diagram.md のみを使用します。承認によって図の種類が変わった場合は、作成に取りかかる前に、置き換え後のリファレンスを読み込みます。無関係なファミリーは読み込みません。
5. 作成時の生成画像ルート：承認された形に生成ビットマップ画像が必要な場合は、ルートを選択または呼び出す前に reference/image-generation.md を読み込みます。現在呼び出し可能なインベントリ、または明示的に選択された API アダプターのみを使用します。キー、実行ファイル、マウント、モデルに関する申告からルートを推測してはなりません。また、曖昧な試行の後に再試行やフォールバックを行ってはなりません。
6. Explore の対象範囲：explore では必ず reference/explore.md を読み込み、成果物の表現と、プロジェクトシステムの作成または明示的な置き換えを区別します。1 つの成果物の表現を比較するために、先にプロジェクトのデザインシステムを作成する必要はありません。System Explore では、描画時のフォールバックを既存のアイデンティティとして適用せず、オプトイン方式の権限分類を使用します。

引き継ぎ時の出力形式

simplify / bolder / quieter / animate の実行後は、会話調の Markdown で報告します。動詞と対象、「what to surface」リストをもとにした変更点、差分の割合、適切な次のアクションを含めます。リファインが成功した場合、既定の次のアクションは polish です。polish には独自の出力形式があります。reference/polish.md を参照してください。

バリアントのルール：

• フォールバックコンテキスト： ソース（プロジェクトの指示、README／ドキュメント、シード、または Clean）を一度だけ挙げ、/visualize teach を促します。Brand profile のフォールバック階層に従ってください。
• 差分が40%超： そこで止め、対象範囲を報告します。方向性が未確定なら探索を、確立済みなら新規作成を推奨するために Design judgment を適用してください。polish には進まないでください。
• 動詞を実行すべきでなかった場合： 参照資料の拒否条件に従い、通常の要約を短い理由と適切な代替案に置き換えてください。

animate に固有のルール：ブランドで motion: none が宣言されている場合、5つ目のバリアントが適用されます。reference/animate.md を参照してください。

変更点を先に伝え、読者に合わせて表現を変えます。要約をコードフェンスで囲んだり、強調に大文字を使ったり、<Verb> pass complete · というバナーを出したりしないでください。

絶対禁止事項

パターンに該当した場合は拒否します。すべてのコマンドと既定の作成フローで適用してください。ここで禁止するのは特定のパターンであり、美的なスタイルや表現の調子ではありません。ブランドで、珍しい見た目のフォント、色合い、レイアウトを指定することはできますが、これらのパターンをブランドのアイデンティティとして定めても、禁止が解除されることはありません。明示的な .visualize-detect.json の除外指定で免除できるのは、具体的なルール ID を持つ検出器ベースの禁止事項に限られます。これはプロジェクトのポリシーであり、実行時のブランドによる抑制ではありません。また、レイヤー2の禁止事項を免除することもできません。

BAN 1 — Gradient text on metrics or headings
  PATTERN:   background-clip: text + gradient background on <h*>, [class*="metric"], [class*="kpi"]
  INCLUDES:  -webkit-background-clip: text; CSS `background-image: linear-gradient(…)` + `color: transparent`
  WHY:       AI-essay register tell; reads as 2023-template "make the number pop"
  REWRITE:   Solid `--primary` (or `--foreground`) at one weight up; emphasis through weight + size, not gradient

BAN 2 — Side-stripe callout (border-left as accent)
  PATTERN:   `.callout`, `.tldr`, `.note`, `.tip` with border-left ≥ 3px in --primary / --warning / --destructive
  INCLUDES:  border-inline-start, border-l-4 utility class, ::before pseudo with positioned bar
  WHY:       Notion / Confluence template tell; reads as productivity-app default
  REWRITE:   Full thin border (1px var(--border)), background tint at 4–8% chroma, or no chrome — just a label heading

BAN 3 — Triple-feature-card grid
  PATTERN:   3-column grid of <h3>adjective + noun</h3> + one paragraph + one icon each
  INCLUDES:  4-column variants, "Why us" sections with identical card-icon-heading-blurb shape
  WHY:       AI-landing canonical pattern; the surest "AI generated this" tell on the visualize corpus
  REWRITE:   Asymmetric — one hero claim with two supporting facts, OR a numbered list with body prose, OR a single comparison table

BAN 4 — Hero-metric template
  PATTERN:   Centered <h1 class="…huge…">N×</h1> + <p class="…small…">supporting label</p> + 3 stat tiles below
  INCLUDES:  "10× faster", "99.9% uptime", "1M requests/day" hero blocks with the same shape
  WHY:       SaaS-landing cliché; the most-copied AI-marketing-page shape in 2024-2026
  REWRITE:   Specific claim in body prose with the number inline; data tiles only when the artifact is actually a dashboard

BAN 5 — Ornamental icon-tile section markers
  PATTERN:   Repeated icon tiles on section headings add chrome without identifying meaningful content distinctions
  INCLUDES:  Rounded-square, circle, coloured-pill, and gradient-tile variants serving only as decoration
  WHY:       Repeated chrome makes different sections look alike and competes with their content
  REWRITE:   Remove ornamental markers; retain useful recognition cues under reference/cognitive-load.md's Cognitive offloading guidance

BAN 6 — Imperative tricolon
  PATTERN:   Three short imperative sentences ending in periods, in the same paragraph or hero
  INCLUDES:  "Ship faster. Build smarter. Scale forever." / "Move fast. Stay safe. Be bold." (any topic)
  WHY:       AI-copywriting cliché — the structure is identical across thousands of generated landing pages
  REWRITE:   One specific claim with the verb in the right tense, OR a sentence that names the actor and the action

BAN 7 — Sycophant / AI-attribution footer
  PATTERN:   "I hope you find this useful", "Let me know if you have questions", "Best, Claude", "Generated by AI", "As an AI…"
  INCLUDES:  Footer-line variants, comment-line variants in the HTML source
  WHY:       The artifact is the work; the model is invisible. Sycophant footers contaminate the artifact register
  REWRITE:   No footer of this shape. A real footer carries metadata (date, version, source-of-truth link) or is absent

これらのパターンを作成しようとしている場合は、そこで止め、代替案を使って要素を書き直してください。このリストは、作成、すべての Refine 動詞、polish で共通して適用されます。

モデル固有の運用ルール

これらはブランドの美的表現ではなく、観察されたモデルの反射的な傾向と、それを修正するために必要な対応です。普遍的な禁止事項を適用した後、特にブランド指定のない新規作成時に適用してください。

Codex 固有のルール：

• 枠線と大きな影の組み合わせ： 同じカードやボタンに、1px の枠線と大きくぼやけたドロップシャドウを組み合わせないでください。くっきりした輪郭か、小さな浮き上がり表現のどちらかを選んでください。
• 角の丸めすぎたコンテナ： 通常のカード、セクション、入力欄、パネルは、通常 12-16px の角丸にしてください。より大きな角丸にするには、明確なブランド上の理由が必要です。
• 装飾的なストライプ背景： 本文やセクションの埋め草として repeating-linear-gradient(...) を使わないでください。意図的なテクスチャや罫線のシステムを使うか、背景を無地にしてください。
• 粗雑な SVG の代用： 実際のアセットがないからといって、粗い SVG の情景を描かないでください。生成したビットマップ画像、幾何学的な図、またはイラストなしを選んでください。
• 詰め込みすぎたディスプレイ書体： テンプレートがスライド／ポスター調で、より大きな文字を明示的に必要とする場合を除き、ディスプレイ見出しの letter-spacing は ≥ -0.04em、clamp の最大値は ≤ 6rem にしてください。
• メタな対比表現のコピー： 「X theater」「actually X」「not just X, it's Y」のような言い回しは避けてください。成果物が実際に何をするかを述べてください。
• 色の判断： reference/color.md を使って、特性、関係性、役割、配分、実際の組み合わせを評価してください。色相、色相の組み合わせ、ニュートラルカラーの色味、アクセントの数は、普遍的な好みの基準ではありません。承認済みのアイデンティティと、成果物に明示された例外を維持してください。
• 構成の代わりにパレットで補うこと： 形状の基準でセマンティックな色の役割を割り当て、一貫して使用してください。ただし、視覚的な興味を作るためだけにアクセントの帯を増やさないでください。構成、文字組み、密度、画像、インタラクションが方向性を示しているなら、ニュートラルな面にアクセントを一色加えるだけでも問題ありません。冒頭に表現の軸がないときに見直し、色相が少ないという理由では見直さないでください。

Gemini 固有の注意事項：

• ホバー時に <img> 要素をアニメーションさせないでください。カードにホバー時のフィードバックが必要な場合は、代わりにカードの枠線、背景、または操作 affordance をアニメーションさせてください。

メタデータ／目次に関する注意事項： 静的なドキュメントのコンテキストには、匿名の角丸チップではなく、明示的なラベルを付けてください。ドキュメントのコンテキストは create.md のドキュメントコンテキストに関するガイダンス に従って配置してください。右側のレール、表紙を分割した情報欄、独立したメタデータパネルは、通常、競合する装飾になります。目次レールは、本当に長いドキュメントであれば使用できますが、冒頭を支配するのではなく、ナビゲーションを補助するものにしてください。モバイルの目次は、ナビゲーション可能なリストか意図的なグリッドにし、単語が自由に折り返されるワードクラウドにはしないでください。作成するものにこれらの構造が含まれる場合は、patterns/metadata.md または patterns/toc.md を確認してください。

テーブルに関する注意事項： テーブルは読み取りのためのものであり、ヒーローセクションではありません。キャプション、ヘッダー、本文、行キー、数値の役割を明確に区別し、等幅フォントは固定幅の値に限定してください。成果物に密度の高い比較や根拠が含まれる場合は、patterns/table.md を確認してください。

インタラクティブ状態に関するルート： 作成するものに機能的なコントロールや、画面上で状態を変化させる機能が含まれる場合は、patterns/interactive-states.md を確認してください。

AI スロップ検査（二つの視点）

両方の検査を実施してください。

• 第一段階： トピックだけでテンプレートとパレットを予測できてしまうでしょうか。承認済みのアイデンティティではなく、根拠のないステレオタイプを確認してください。色相の名前自体は禁止事項ではありません。
• 第二段階： トピックと反参照だけで、美的な方向性を予測できてしまうでしょうか。ソースや文体が裏付けていないのに、クリーム色／Georgia／欄外注のエディトリアル調、等幅／グリッド／太い枠線のターミナル調、大文字／グロテスク体／グリッドのスイス風ポスター調など、別の単調なパターンに置き換えることも避けてください。

どちらの検査でも処理方法が予測されなくなるまで、根拠のないデフォルトを見直してください。承認済みのアイデンティティは維持してください。

ブランドプロフィール

レンダリングのたびに、利用可能なプロジェクトルートの DESIGN.md（ビジュアルアイデンティティ／トークン）、PRODUCT.md（ボイス／対象ユーザー／トーン）、tokens.css を読み込みます。teach は theme: <name> という参照先ではなく、Stitch 形式の DESIGN.md と CSS サイドカーに具体的なプロジェクトトークンを書き込みます。そのスキーマと導出手順は reference/teach.md に記載されています。

権限の優先順位： 保存済みの DESIGN.md と tokens.css がビジュアルトークンを管理し、PRODUCT.md がボイスと対象ユーザーを管理します。プロジェクトの指示は不足部分を補いますが、現在のリクエストでユーザーが明示的に指示しない限り、保存済みトークンを上書きしません。コンテキストを確定する前に、Artifact テーマの承認済み例外を適用してください。

ブランドの権限はアイデンティティごとに適用されます。リクエストで特定のアイデンティティが指定されているにもかかわらず、解決されたプロジェクトプロファイルが明らかに別の製品のものである場合、それを代用したり、ラベルを付け替えたり、近似させたりしないでください。シェイプゲートやアーティファクトの編集に進む前に停止し、一致する権限情報、またはアーティファクトのみへの上書きを明示的に許可するよう求めてください。

design-systems/ パッケージは、teach、System Explore、アーティファクトテーマ向けのガイダンス、トークン、プレビューを提供します。

インストール済みスキルには、カタログのインデックスと Clean のフォールバックが含まれています。選択した参照を解決するには node $SKILL_DIR/scripts/catalog.mjs <slug> を実行し、返されたファイルパスのファイルを読み込んでください。プレビューを確認する場合に限り、--previews を追加します。その他のパッケージは、design-systems/catalog-source.json に記載された公開リビジョンから取得され、ローカルにキャッシュされます。パッケージ内のリンクは、返されたソース URL を基準に解決されます。共有ワークフローは、このインストール済みスキルです。解決に失敗した場合は、利用できない参照として報告し、そのガイダンスを捏造したり、明示的な選択を黙って置き換えたりしないでください。VISUALIZE_CATALOG_CACHE_DIR でキャッシュの保存先を変更できます。

DESIGN.md が存在しない場合のフォールバック：

1. プロジェクトのガイダンスがない部分では、承認済みのアーティファクト参照をベースラインとして保持し、シードや Clean に置き換えないでください。
2. それ以外の場合は、利用可能なプロジェクト指示（AGENTS.md、CLAUDE.md、README、docs）を読み、ポジショニング、ビジュアルの方向性、アンチリファレンス、デザイン原則を確認してください。利用可能なガイダンスは、名前付きフォント、パレットの役割、ロゴ／マークのルール、密度／文体、アンチリファレンスなどを含む、必須のブランドコンテキストとして扱い、任意のムードとして扱わないでください。文章から近似する前に、参照されているトークン、スタイルシート、ロゴコンポーネント、ガイドラインに従ってください。名前付きフォントとパレットの役割は Clean の値より優先されます。アンチリファレンスは、該当するフォールバックの文体を除外します。Clean が提供するのはセマンティックなトークンの表層であり、そのフォント、モノクロパレット、暖色系／クリーム色のデフォルトではありません。
3. 利用可能なビジュアルの方向性がない場合に限り、node $SKILL_DIR/scripts/palette.mjs --from "<topic-or-project-name>" を実行してください。シードと概要をもとに、一時的な primary、background、foreground、accent、chart、state トークンを組み立てます。その際、シードの derived に含まれるコントラスト値、彩度の上限、ライト／ダークの段階を使用してください。これらの値を推定したり、Clean をそのままコピーしたりしないでください。シードが概要に合わない場合は、--not <zone,...> または --vary <n> を付けて再実行し、シェイプゲートに却下の理由を記録してください。組み立てたトークンを node $SKILL_DIR/scripts/palette.mjs --check <tokens-or-html> --strict で検証し、レンダリング前にエラー（終了コード 2）を修正してください。

フォールバックコンテキストを使用する場合、セッションごとに一度 /visualize teach を提案してください。

保存済みブランドファイルがない場合の洗練動詞： simplify／bolder／quieter／animate／polish は、作成時と同じフォールバック階層を使用します。プロジェクトの指示、README／docs、またはすでに読み込まれたその他のコンテキストは、定性的なブランドの基準として有効です。Clean のデフォルトを基準とするのは、利用可能なプロジェクトガイダンスがない場合に限ります。フォールバックの情報源を使用した場合は、その情報源を一度明示し、フォールバックを実際のブランドプロファイルにできるよう /visualize teach を提案してください。 Absolute ban が 3 つ以上あるアーティファクトに対する Refine の動詞： bolder／quieter／animate／polish は拒否して振り分けます。実行サマリーに次のように記載します："REFUSED — N Absolute bans present (listed). The artifact needs structural cleanup before <verb> applies. Recommend /visualize simplify <path> first (removes the ban patterns), then re-evaluate." Simplify は禁止パターンを含む入力を主要な対象として受け付けます。他の Refine の動詞はクリーンなベースラインを前提としており、禁止パターンの多いアーティファクトに対して実行してはいけません。

アーティファクトのテーマ

テーマとは、1 つのアーティファクトに適用する参照デザインシステムであり、新たに保存されるオブジェクトでも、プロジェクト全体への採用でもありません。まずプロジェクトのシステムを使い、参照デザインを借りる前に、拘束力のある選択、承認済みの例外、未確定の要素を解決してください。名前付きの参照や、より表現力を高めたいという要望があっても、拘束力のある選択が暗黙に上書きされることはありません。未解決の競合は確認し、明示的な置き換え許可は、指定されたアーティファクトと要素にのみ適用します。プロジェクトで定められていない制約を勝手に設けないでください。

Brand profile のカタログ手順に従って、選択したパッケージを解決してください。README.md がある場合はそれを読み、その後に DESIGN.md と tokens.css を読みます。DESIGN は適合性、アイデンティティ、適応方法を定めます。プレビューは処理の例を示すものであり、必須のレイアウトではありません。ユーザーが選択肢を求めている場合は、関連性の高い候補を少数提示してください。カタログ全体を読み込んではいけません。README がなくても、そのパッケージが利用できないことにはなりません。

作成または改訂を通じてデザインを適用し、未確定の処理案を比較する場合は explore artifact を使います。どちらの場合も、新しいレイアウトやプロジェクトプロファイルは不要です。ソースと読者のタスクから新しい構造を導き出してください。変更を依頼されていない限り、既存のコンテンツ、順序、アセット、動作を維持します。広範なスタイル変更には、その範囲を明示して reference/create.md を使い、Refine の動詞に設定された差分ガードを超えないようにします。既存の承認ゲートは引き続き適用されます。提案する変更を明示的に含む依頼がある場合、再確認は不要です。

パレットやタイポグラフィとともに、階層、間隔、サーフェス、コンポーネントの処理も反映してください。上書き対象でないプロジェクトの選択は維持します。解決済みのトークンは、ライト、明示的なダーク、OS のダークモードで動作するようアーティファクトに埋め込みます。プロジェクトのトークンソースは置き換えないでください。上書きされた値ではなく、解決済みのアーティファクトのコンテキストに照らして検証してください。一部のみを借用した場合や、維持した制約は正確に説明します。承認済みの例外と適用範囲は、既存のタスクノート、または後で改訂する際に参照できる短いアーティファクトコメントに記録してください。説明のない逸脱は承認とはみなされません。

プロジェクト全体の取り込みや導出には teach を使い、新しいシステムや明示的に依頼された置き換えシステムの比較には explore system を使います。アーティファクトのテーマを扱う際に、どちらも前提条件ではありません。

普遍的な原則

すべてのコマンド、すべてのテンプレート、すべてのプロンプトに適用します。これらは、文脈に依存しない正確性の制約ではなく、文脈に応じた好みの判断に優先します。

1. 解決済みのコンテキストと文体は、文脈に応じた好みのルールより優先されます。 承認済みの文体と単に相反するという指摘は、カテゴリの誤りです。コンテキストを理由に、除外されていない絶対的な禁止事項、成果物に残った化石やプレースホルダー、アクセシビリティ要件、誠実性やデータの真実性に関する問題を無視してはなりません。成果物を改善する許可があっても、プロジェクトのブランドプロファイルや共有トークンソースを変更してよいことにはなりません。必要な変更は、それらの権限元に対して別途提案してください。ただし、ユーザーがすでに変更を許可している場合は除きます。
2. コマンドは解釈し、再生成しません。 反復コマンドが返すのは対象を絞った差分であり、新しい草稿ではありません。差分が成果物の40％を超える場合、コマンドは意図どおりに動作していません。
3. リリースを妨げる問題と好みの判断は別物です。 A11y とコントラストの問題は修正する必要があります。好みの判断は交渉可能です。
4. 重大度は、集積した場合も含め、コンテキストに応じて判断します。 info ルールも、積み重なればリリースを妨げることがあります。error ルールが好みの判断にとどまるのは、文脈に依存し、ブランドが許容している場合に限ります。原則 1 の文脈に依存しない制約の重大度を引き下げてはなりません。
5. 目立たなくなるまで削り込んではなりません。 コマンド実行後も、成果物には解決済みのコンテキストに根差した印象が残っているべきです。
6. 判断するのは読者です。 すべての指摘について、読者の作業を難しくしているのか、それとも単にルールを満たしているだけなのかを見極めます。
7. 検出結果は欠陥の証拠であり、完成の証拠ではありません。 detect.mjs の結果が問題なしでも、成果物の品質が高い証明にはなりません。機械的な最低基準を満たしたことを示すだけです。検出ツールが見つけられるのは正規表現で識別できる問題だけです。それ以外は、文章そのものを吟味して対応します。検出結果に問題がないからといって、完了と判断してはなりません。
8. デスクトップでの見栄えより、モバイルでの表示を優先します。 デスクトップでは優れた構成でも、スマートフォンで単に縦積みになるだけなら、普通の文書より劣ることがあります。最初の2画面を、完成した読書体験として判断します。見出しの大きさ、メタデータの折り返し、目次の配置、カードの装飾、本文のリズムが、狭い画面でもすべて意図的に感じられる必要があります。
9. メタデータには説明を添えます。 display.dev strategy や Updated May 29, 2026 のようなラベルのない項目では、読者が項目の意味を推測しなければなりません。Memo type / display.dev strategy、Updated / May 29, 2026、Input / method, vision, competitor refresh のように、明示的なラベルを付けてください。ラベル付きのコンテキストは、create.md の文書コンテキストに関するガイダンスに従って配置します。すべてのメタデータ項目を冒頭に置く必要はありません。
10. 整っているだけでは不十分です。 機械的な正確さや視覚的な洗練だけでは、内容が理解されるとは限りません。視覚的な成果物には、読者が情報の出典を理解できるようにする、意図的な構成が必要です。冒頭だけでなく、最初の画面より後にある重要な説明も評価し、具体性と理解度の確認に従ってください。読者の役に立つなら、見慣れた構成でも問題ありません。よくあるレイアウトを避けるためだけではなく、実証された欠点を修正するために構成を変更してください。