reviewing-hi-fi

reviewing-hi-fi — SKILL.md

バリアント： standard · 使用する場面： 完成済み（または修正済み）のハイファイなデザイン・アズ・コードを受け入れゲートとして評価するとき。再レンダリングし、基準に照らして結果を視覚的にレビューしたうえで、対応可能な指摘とともに VERDICT: approve|revise を出力します。

概要

このスキルは、ハイファイを作成・評価するペアのうち、レビューを担います。完成済みのハイファイ（コードとその画面）を手元に持つレビュアーが読み込み、次の1点を評価します。レンダリングされたハイファイは、妥当なビルドの種になっているか。ワイヤーフレームで名前が付けられたすべての画面を網羅し、基準を満たす視覚表現が実現され、レンダリング上でアクセシブルであり、デザインシステムに準拠しているか。 authoring-hi-fi が生成するときと同じ基準である、単一ソースの固定チェックリストを適用し、機械で解析可能な単一の判定と、作成者が一度の作業で対応できる指摘を出力します。これは受け入れゲートです。作成、修正、改善を目的とした再レンダリングは行いません。評価して指摘を返します。

成果物は、ピクセルにレンダリングされるコードです。レビュアーならではの手順は、コード自体を再レンダリングすること（ヘッドレスブラウザー、agent-browser／Playwright）、ビューポート × 状態ごとに新しいスクリーンショットを取得すること、そしてその新しいレンダリング結果を視覚的にレビューすることです。提出されたスクリーンショット（古い可能性や、都合のよいものだけを選んだ可能性があります）を信頼したり、コードを読むだけで採点したりすることはありません。これには視覚機能を備えたランタイムが必要です。テキストのみのレビュアーでは機能が低下します（コードは読めても、レンダリング結果は確認できません）。その旨を伝え、成果物自体が視覚的な確認なしに作成されていた場合は指摘してください。

境界は2つあります。ハイファイが担うのは、レンダリングされたビジュアルと数値によるピクセル単位のWCAG評価です（ワイヤーフレームではその枠だけが確保されています）。デザインシステムが担うのは、コンポーネントごとのアクセシビリティ契約仕様です。このゲートでは、レンダリングされた合成結果がその仕様を満たすかを評価します（仕様と実現結果の比較であり、二重評価はしません）。デザインシステムとワイヤーフレームへの準拠を評価しますが、それら自体を採点することはありません。また、評価するのはビルドの種であり、本番コードではありません（テストや実際のバックエンドがないことを理由に修正を求めないでください）。

有効にする場面

• 完成済みのハイファイなデザイン・アズ・コードについて、人間によるビジュアルゲート／ビルドのマイルストーンの前に、承認または修正の判断が必要な場合。
• 作成者がレンダリングしたばかりのハイファイを、独立したレビュアー／ゲートとして評価する場合。
• 以前の revise 判定を受けて修正されたハイファイを再評価する場合、または修正済みのハイファイを範囲を限定して差分レビューする場合（条件13を参照）。

次の場合は有効にしないでください：

• ハイファイを作成または修復する場合 → authoring-hi-fi を使用してください。このスキルは、改善のための作成や再レンダリングは行いません。
• 画面の構造（レイアウト領域、コンポーネントの選定、構造としての状態）を評価する場合 → それは上流工程のワイヤーフレーム（reviewing-wireframes）の役割です。
• トークンシステム／コンポーネントカタログ／コンポーネントごとのアクセシビリティ契約を評価する場合 → それはデザインシステム（reviewing-design-system）の役割です。このゲートではレンダリング結果がそれに準拠しているかを確認します。
• どの画面や遷移を設けるかを再検討する場合 → それはユーザーフローの役割です。
• 最終的な本番コード（テスト、実際のバックエンド、パフォーマンス）を評価する場合 → これはビルドの種であり、それらはビルド工程の担当です。

ワークフロー

Step 1: コードを再レンダリングし、ハイファイ全体を新鮮な視点で独立して読む

対象のビューポートでハイファイのコードを自分でレンダリングし、状態ごとに新しいスクリーンショットを取得してください。提出されたスクリーンショットを信頼しないでください。レンダリングできない場合（ヘッドレスブラウザーがない）、またはレンダリング結果を確認できない場合（テキストのみのランタイム）は、その旨を伝えてください。レビューの精度は低下し、コードを静的に見てわかる範囲だけで評価することになります（その点を指摘してください）。コードと画面を最初から最後まで確認してください。上流工程のワイヤーフレームやデザインシステムが提供されている場合は、Step 2で網羅性と準拠性を照合できるよう、目を通してください。

Step 2: チェックリストを実行する — レンダリング結果を基準に各条件を評価する

各条件について、コードの記述だけではなく、最新のレンダリング結果を基準に、合格またはギャップと判定してください。条件が不合格となるのは、具体的に特定できる実際の欠陥がある場合に限ります。「別の色相やレイアウトにしたかった」はギャップではありません（対象外の主観的な好みは除外します）。正確な箇所（画面、状態、ビューポート）を記録してください。各条件は画面のアーキタイプに応じたものです。簡素な画面や静的な画面では、インタラクション、状態、レスポンシブに関するサブチェックが妥当に省略される場合があります。簡潔さを理由にギャップを捏造しないでください。

以下のケイパビリティ境界チェック項目が適用されるのは、capability_record が作成時の呼び出しに注入され、レビューコンテキストとして利用可能な場合のみです。存在しない場合は該当なしとして扱ってください。境界が定義されていないのに、境界マーカーがないことを理由にドキュメントを不合格にしないでください。

1. ワイヤーフレームとの完全な網羅性。 ワイヤーフレームに名前がある画面と、フローで訪れる状態がすべてレンダリングされています。レンダリングされていないものがある場合は Gap とします（ワイヤーフレームと照合し、該当するものがない場合は、ドキュメント独自の一覧を確認し、不足している入力を記録します）。省略できないベースライン。（改訂では、既存の一覧で成果物全体の網羅性が満たされているものとします。変更されていない画面を再度審査する必要はありません。差分によって新たに生じた網羅性の後退は cond-13 で扱います。）
2. 忠実度とスコープ。 高忠実度のビジュアルが実現されています（ワイヤーフレームのグレー表示／ブラウザーのデフォルトスタイルではありません）。ワイヤーフレームにない構造／ナビゲーション／画面を追加していません。また、シードとして評価されています。テスト／実際のバックエンド／ルーティングがないことを理由に修正を求めてはならず、実際には本番対応でないのに本番対応を主張している場合は承認してはなりません。省略できないベースライン。
3. ビジュアルの実装と階層。 デザインシステムのビジュアル言語がレンダリングに反映されています（色／書体／間隔／エレベーション／角丸／アイコン／画像）。主要な要素が視覚的に際立ち、階層が明確です。平坦で差別化されていない、またはスタイルが適用されていない画面は Gap とします。省略可： 要素が1つだけの画面では、階層はほとんど必要ありません。
4. 仕上がり — 客観的基準と明示されたヒューリスティック。 客観的基準：グリッドに沿っている、スケールに一貫性がある、要素の切れ／重なり／孤立がない、トークンを使用している、同種の要素間で一貫性がある。明示されたヒューリスティック（それぞれ説明できるもの）：バランス、余白と抑制、間隔のリズム、焦点の明確さ、美的な一貫性。客観的な不備、または明示されたヒューリスティックの不備（どのヒューリスティックに、なぜ該当するかを明記）がある場合に限り Gap とします。「もっと良い色合い／レイアウトがある」という主観的で評価基準外の好みは、Gap ではありません。省略可： ごく単純な画面は、当然ながら基準を満たします。
5. トークンに基づく実装／デザインシステムからの逸脱なし。 すべてのビジュアル値がデザインシステムのトークン（Tailwind のトークンユーティリティ／CSS 変数／shadcn トークン）に由来しています。トークンを迂回する生の #hex／px／bg-blue-500 はありません。デザインシステムのトークン／コンポーネントをローカルで上書きしていません。不足しているトークン／コンポーネントはインラインで追加せず、明示します。トークンに基づかない値や逸脱が1つでもあれば Gap とします。省略できないベースライン。
6. レンダリング済みで、あなた自身がビジョンレビュー済み。 コードを再レンダリングし、新しいスクリーンショットを取得しています。問題なくレンダリングされ、ワイヤーフレームの構造とデザインシステムに一致しています。画面のレンダリングに失敗する、表示が崩れる、またはワイヤーフレームと異なる場合は Gap とします。提出された画像だけを使ったレビューや、コードを読むだけのレビューは不完全です。省略できないベースライン（この手順自体がゲートです）。
7. コンテンツの現実性。 実際に近い、代表的なコンテンツを使っています。lorem／プレースホルダーの埋め草はありません。 現実的なデータとエッジケースのデータ（長い文字列、オーバーフロー）を使って検証しています。lorem を使っている場合、または整ったデータしか使っていない場合は Gap とします。省略できないベースライン。
8. レンダリングされた状態と品質。 フローで訪れる各状態がレンダリングされています（注記ではなく、スクリーンショット）。空（理由と行動への案内）、読み込み（単なるスピナーではなく、レイアウトを反映したスケルトン）、データ表示、エラー（平易な原因の説明と復旧方法）、成功、一部表示。該当する状態がレンダリングされていない場合、または中身のない状態の場合は Gap とします。省略可： 静的な画面に必要なのはデータ表示状態のみです。
9. レスポンシブなリフロー。 対象のビューポートでレンダリングされ、正しく表示されます。フォームファクターに応じて、モバイルではコンテンツの優先順位を調整し、ナビゲーションを適応させています。タッチターゲットのサイズも適切です。レスポンシブな画面を1つの幅でしか示していない場合、またはリフローが崩れている場合は Gap とします。省略可： 単一のフォームファクターを対象とする画面（理由が明記されている場合）。
10. レンダリング上で WCAG 2.2 AA の数値基準を満たすこと。 axe-core で違反がなく、ルールを無効化していません（これは必要条件であり、十分条件ではありません。axe ではフォーカスの見た目、キーボード／フォーカスの順序、画像上のコントラスト、動きの抑制設定は確認できないため、レンダリング上で評価し、手動／支援技術によるスポットチェックを行います）。さらに、レンダリング上で以下を満たしていること：テキストのコントラスト比 ≥4.5:1／大きな文字と UI ≥3:1（SC 1.4.3／1.4.11）、フォーカスが視認可能（2.4.7）で、隠されず（2.4.11）、表示領域が ≥2px／コントラスト比 ≥3:1（2.4.13、組織内ルール）、ターゲット ≥24px（2.5.8）、キーボードで操作可能でフォーカス順序が論理的、動きの抑制設定に対応していること。測定可能な不備、または無効化されたルールがある場合は Gap とします。修正はトークンレイヤーで行います。ベースライン： コントラスト、ランドマーク、名前は常に対象とし、フォーカス／ターゲット／動きは、操作要素やアニメーションがある場合に対象とします。仕様と実現結果の区別： デザインシステムのドキュメントに基準が記載されているかではなく、レンダリングが基準を達成しているかを評価します（前者はデザインシステムのゲートで扱います）。
11. デザインシステムへの準拠。 レンダリング結果がデザインシステムに準拠しています（コンポーネントはデザインシステムのもの、またはその契約に忠実であり、矛盾がありません）。デザインシステム自体の品質に関する指摘は、このレビューの範囲外です。明示して、デザインシステムのゲートに引き継ぎます。省略できないベースライン。
12. 不足事項は明示し、創作しない。 未定義の画面／コンテンツ、不足しているデザインシステムのトークン／コンポーネント、劣化した（レンダリングされていない）本番環境について、前提／未解決事項として明示します。不足事項を、創作したトークン／コンポーネントや偽造スクリーンショットで取り繕っている場合は Gap とします。前提であることを正直に明記していれば、Gap ではありません。
13. 差分に限定したレビュー（改訂された高忠実度版のみ）。 成果物全体ではなく、差分と、変更した画面の再レンダリング結果をレビューします。対象範囲が限定されていること（未変更の画面のコードがバイト単位で変更されておらず、それらのスクリーンショットも再取得されていないこと）。影響範囲に問題がないこと（変更したトークンがそれを使用するすべての画面に反映され、トークンに基づかない手編集がなく、古いままの使用箇所がなく、ワイヤーフレームに名前がある画面が新たに未レンダリングになっておらず、コンポーネント名が変わっておらず、変更した画面のスクリーンショットがすべて再取得され、古いレンダリング結果がないこと）。変更した画面を新しいレンダリング結果で再度ビジョンレビューし、仕上がり、WCAG、デザインシステムへの準拠を引き続き満たしていること。変更クラスに応じて、ドキュメント独自のバージョン更新が適切であること。破壊的な削除に非推奨化の案内があること。変更履歴が差分と一致していること。これらのいずれかを満たさない場合は Gap とします。新規に初回構築する場合は N/A です。
14. 機能境界（capability_record がない場合は該当なし）： 全体でデザインシステムのトークンを使用していること、デザインシステム以外の新しいコンポーネントがないこと、境界がワイヤーフレームの範囲と一致していること（機能ごとの範囲では画面内部のみ、システム全体の範囲ではシェルのみ）。

ステップ 3：判定を決める

• approve — 適用されるすべての条件がレンダリング上で満たされています。ハイファイは、十分に網羅され、求められる基準で視覚的に実現され、アクセシブルで、デザインシステムに準拠した、適切な実装の出発点です。視覚的に改善できると思っても承認してください。基準となるのは条件であり、完璧さではありません。画面が簡素でも、条件が画面に応じて相応に絞られていれば承認します。
• revise — 1 つ以上の条件に、実際に特定できる不備があります（画面がレンダリングされていない、ワイヤーフレームのようなグレーの忠実度、トークン外の生の値、レンダリング上のコントラスト不良、Lorem ipsum のコンテンツ、レンダリングされた状態の欠落、特定可能なヒューリスティック違反、不適切な差分）。

労力を示したり、あればうれしい改善を求めたりするために「revise」にしないでください。評価対象外の主観的な好み（条件 4）、デザインシステム自体の品質（条件 11）、テストの欠落など実装の出発点に限られる不備（条件 2）を理由に「revise」にしないでください。条件は満たされているか、満たされていないかのいずれかです。

ステップ 4：判定と実行可能な指摘を出力する

判定は 1 行で出力します。リテラルテキスト VERDICT: approve または VERDICT: revise を、単独の行に記載し、前後にフェンス、引用符、その他の語を付けないでください（ここにあるフェンスは説明用です）。

VERDICT: approve

続けて指摘事項を列挙します。「revise」の場合、すべての指摘は実行可能でなければなりません。失敗した条件、正確な場所（画面／状態／ビューポート）、および修正方法（コントラスト／トークンに関する問題の場合は、トークン層での修正）を示し、制作者が 1 回の修正で解消できるようにしてください。「approve」の場合、指摘は任意であり、ブロック要因とならないメモを記載できます。

良い指摘では、不備と修正方法を具体的に示します。

revise — WCAG の数値基準（条件 10）：レンダリングされた Projects の空状態画面で、「New project」ボタンは白地に --muted が適用され、コントラスト比は 2.9:1 です（4.5:1 未満、SC 1.4.3）。修正：ボタンを --primary トークンに紐付けてください（ボタン単体の色をトークン外で変更しないでください）。4.5:1 以上であることを確認するため、再レンダリングしてください。

悪い指摘は曖昧です。「どこかのコントラストを改善できそうです。」

ルール

厳守事項（決して違反しないこと）：

• 判定行は VERDICT: approve または VERDICT: revise の1行だけを出力してください — そのリテラルトークンを単独の行に記載します。後続のツールが解析します。
• 再レンダリングし、渡されたスクリーンショットを信用しないでください。 コードを自分でレンダリングし、新しい結果を視覚的にレビューしてください（条件6）。コードを読むだけのレビューや画像を信用するレビューは不完全です。劣化した実行（レンダリングなし／テキストのみ）は明記してください。
• 評価に徹し、作成しないでください。 指摘事項を返し、書き直しや改善のための再レンダリングは行わないでください。修正するのは制作者です。
• 単一の基準に従ってください。 Step-2 の条件、つまり制作者が成果物を作る際の基準と同じ基準で評価してください。独自のより厳しい基準を設けたり、条件を追加したりしないでください。
• 誤った revise を避けてください。 適用されるすべての条件を満たしている seed は、内容が薄くても承認します。範囲外の主観的な好みは不足事項ではありません。seed のみを対象とした不足（テスト／バックエンドがないこと）も不足事項ではありません。
• 誤った approve を避けてください。 未レンダリングの画面、トークンに準拠しない生の値、レンダリング上のコントラスト不備、lorem コンテンツ、または独自に作られたトークン／コンポーネントがある場合は revise とします。
• レンダリング上の数値に基づいてアクセシビリティを評価し、無効化されたルールを決して容認しないでください。 レンダリングされたピクセル上でコントラスト、フォーカス、ターゲットサイズを評価します。合格させる目的で axe のルールを抑制している場合、それ自体を指摘事項とします。
• 仕様と実現結果の範囲を守ってください。 レンダリングが WCAG のしきい値を達成し、DS に準拠しているかを評価してください。DS 自体の契約や品質（これは reviewing-design-system の対象）や、画面構成（これは reviewing-wireframes の対象）は評価しないでください。
• 本番環境ではなく seed として評価してください。 テスト／実際のバックエンド／ルーティングがないことを理由に revise としないでください。これらはビルドフェーズの対象です。
• 提示された上流成果物に基づいて評価してください。 作成されていない上流成果物は revise の理由になりません。一方、作成済みの上流成果物を無視している場合（ワイヤーフレームの画面をレンダリングしていない、DS トークンを迂回しているなど）は正当な指摘事項です。
• Amend は差分レビューです。 修正時は差分とその波及範囲を確認し、差分を再度視覚的にレビューしてください（条件13）。変更されていない画面を再審議しないでください。
• revise の指摘はすべて実行可能な内容にしてください — 未達の条件、該当箇所、具体的な修正方法を示します。

優先事項（上書き可能）：

• 指摘事項は重大度順に並べてください。最初に重大な不足（未レンダリングの画面、コントラスト不備、トークンからの逸脱、lorem）、次に軽微な事項（単一のヒューリスティック上の指摘）を記載します。
• 各指摘事項で条件番号／名称を参照してください。
• approve の補足は少数にし、ブロッキングではないことを明確にしてください。
• クロスチェックの入力（ワイヤーフレームまたはデザインシステム）がない場合、またはレンダリングが劣化している場合は、暗黙に想定せず、その旨を一度だけ記載してください。

注意点

• 提出されたスクリーンショットを信頼すること。 提供された画像は古かったり、都合のよい部分だけ選ばれていたりする可能性があります。自分でコードを再レンダリングしてください（条件 6）。それがゲートの要です。
• コードを読んでレビューすること。 問題なく見えるコードでも、レンダリングすると壊れている場合があります。必ずレンダリングして確認してください（条件 6）。
• デザインシステムを採点すること。 DS のトークン値やコンポーネントの契約に問題があるように思えても、修正を求めるのは担当範囲外です。レンダリング結果が準拠しているかを評価し（条件 11）、DS の品質に関する指摘は DS ゲートに回してください。
• WCAG を二重に評価すること。 DS はコンポーネントごとのしきい値を示します。このゲートでは、レンダリング結果がそのしきい値を実現しているか（仕様と実際の実現との比較）を評価します。DS が示す数値を再評価するのではありません。
• 本番向けの不足を理由にシードを修正させること。 テストなし／モックデータ／単一ファイル／CDN はシードで許容されているものであり、不足ではありません（条件 2）。
• 好みを理由に修正させること。 「もっとよい色合いやレイアウトがある」は、評価対象外の主観的な好みです。条件 4 では、客観的な評価対象と明示されたヒューリスティクスを評価します（どれに違反しているかを示してください）。好みを不足としてでっち上げるのは、誤った修正要求です。
• ダミーテキストを見逃すこと。 プレースホルダーの埋め草は、はみ出し／トーン／アクセシビリティの問題を隠します。これは revise にしてください（条件 7）。
• トークンから外れた値を見逃すこと。 トークンマップを迂回する生の #hex／px は逸脱です（条件 5）。トークン層で修正してください。
• 修正時に成果物全体を再レビューすること。 差分とその波及箇所をレビューし、変更部分を再確認してください（条件 13）。手を加えていない画面を再び議論してもノイズになります。
• 判定トークンの揺れ。 「Approved」、「LGTM」、「要修正」、または段落の途中に埋め込まれた判定は解析できません。VERDICT: approve|revise を、そのまま単独の行に出力してください。

アンチパターン

• 形式だけの approve。 コード／画面をざっと見ただけで承認すること。このゲートは、ビルドのシードになる前に、未レンダリングの画面、コントラストの不備、DS の逸脱を見つけるためにあります。
• 些細な点で revise。 見た目の好み、DS のトークン値、またはシードでのみ許容される不足を不具合として装い、作業を止めること。revise の対象は、実際の網羅性／忠実度／アクセシビリティ／準拠性を阻む問題に限ります。
• 画像を信頼したレビュー。 提出されたスクリーンショットを再レンダリングせずに評価すること。ゲートの目的そのものを損ないます。
• 黙って再レンダリングして修正すること。 「コードを少し調整するほうが簡単だ」という理由で、レビュー中に制作まで行うと、制作と評価の分離が崩れます。
• 条件を勝手に追加すること。 「AAA にも合格すべき／アニメーションを追加すべき／別のレイアウトにすべき」という要求は、単一の情報源に定められた条件を超えて基準を逸脱させます。
• 別の成果物を評価すること。 レンダリングされたハイファイではなく、構造（ワイヤーフレーム）やトークンカタログ（デザインシステム）を評価すること。担当範囲を守ってください。
• 曖昧な判定。 「ほぼ approve だが……」や、判定を二行出すことは避けてください。判定は一つ、トークンは一つだけです。

出力

1 つのハイファイデザインに対するレビュー結果を 1 件出力します。

• 判定行を 1 行 — VERDICT: approve または VERDICT: revise を、そのまま単独の行に出力します。
• 指摘事項 — revise の場合、ブロック要因となる不足ごとに、対応可能な指摘を 1 件（違反した条件＋場所＋具体的な修正方法）記載します。approve の場合、ブロック要因にならない注記は任意です。

抽象的な利用者は、制作→レビューのループを統括するものです。approve は、人によるビジュアルゲート／ビルドのマイルストーンに向けてハイファイを承認します。revise は、範囲を限定した修正のために、指摘事項を制作者へ返します。

指摘の例（実際の revise）。 引き継ぎ内容：ハイファイの「Settings」画面、コードのみ、スクリーンショット 1 枚を提供。レビュー担当者が 360／768／1280 で再レンダリングしたところ、360 ではフォームフィールドがビューポートからはみ出し（リフローなし）、セクション見出しに生の #1a1a1a が使われ（トークン外）、axe がトグルのラベルを検出しました。判定：revise — 条件 9（360 で Settings のリフローが壊れており、フィールドがはみ出す。修正：フィールドグループを縦に並べ、768 未満では 1 列にする）、条件 5（見出しに生の #1a1a1a を使用。修正：--foreground に紐付ける）、条件 10（トグルにアクセシブルな名前がなく、axe の label が指摘。修正：aria-label を追加する）。提供されたスクリーンショット（デスクトップ、内容あり）では問題なく見えましたが、すべてのビューポートで再レンダリングしたことで、ゲートが問題を検出しました。

関連項目

• authoring-hi-fi — 制作側を担い、このスキルが評価するものと同じ基準で制作します。組み合わせることで基準を一元化し、制作とレビューのずれを防ぎます。
• reviewing-wireframes — 画面構成を審査する兄弟ゲートです。ワイヤーフレームはここでは（網羅性を確認するための）照合用入力であり、このスキルの評価対象ではありません。
• reviewing-design-system — トークンシステムと、コンポーネントごとの a11y 契約を審査する兄弟ゲートです。デザインシステムはここでは（適合性を確認するための）照合用入力であり、このゲートではそれに照らして実際にレンダリングされた結果を評価します（仕様と実現結果の比較）。
• agent-browser（および playwright-best-practices） — コードをレンダリングしてスクリーンショットを撮影し、レビュアーが視覚的にレビューできるようにします。このスキルが操作します。
• hi-fi テンプレート／コンテンツテンプレートツール — セクションの構成を管理します。このスキルは構造への準拠ではなく、基準に照らした品質を評価します。

段階的な情報開示

• references/buildability-bar.md — 14 の条件を、条件ごとの合格／不足のシグナルと具体的な評価例とともに詳しく説明します（仕様と実現結果の比較における WCAG の境界、名前付きヒューリスティックによる仕上がりの判断、シードと本番環境の線引き、差分レビューを含む）。判断が難しい条件をより明確に評価する必要がある場合に読み込みます。
• references/sources.md — 手法と基準（authoring-hi-fi の兄弟スキルと共有）の調査出典情報です。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限）。description と when_to_use の合計は、一覧表示で 1,536 文字に切り詰められます。
• 本文は約 500 行／5,000 トークンを目安とします（厳密な上限ではありません。品質を優先し、700 行／7,000 トークンを継続的に超える場合は警告してください）。毎回のターンでコンテキストに保持されます。
• 参照ファイルごとに、10k トークン超で警告、25k 超でエラー。参照ファイルの合計は、25k トークン超で警告、50k 超でエラー。