superior-ui-audit

優れた UI 監査

実際に適用されているシステムに照らして、一貫性のある製品サーフェスを 1 つ監査します。スタイルに関する意見を長々と並べるより、十分な根拠のある指摘を少数に絞ってください。

範囲

• 製品のソースは読み取り専用として扱ってください。
• 監査中に依存関係をインストールしたり、ファイルをフォーマットしたり、生成されたアーティファクトを変更したりしないでください。
• UI のレンダリングや操作は、依頼された場合、または視覚的な主張を証明するために読み取り専用のツールが必要な場合に限って行ってください。
• ユーザーが対象に含めない限り、機能上のバグ、アクセシビリティの欠陥、パフォーマンスの問題、コード品質は報告対象外としてください。
• ユーザーが UI の修正を依頼した場合、この監査スキルはその依頼に優先しません。代わりに実装ワークフローを使用してください。

サーフェスを追跡する

対象範囲のルート、画面、コンポーネント群、またはユーザージャーニーから始めます。レイアウト、構成、コンポーネント、バリアント、トークン、解決済みスタイルを通る実際の経路をたどってください。名前が似ているファイルや近くにあるファイルは候補にすぎず、そのオーナーが対象サーフェスに影響する証拠にはなりません。

利用可能な場合は、サーフェス、関連するオーナー、デザインの情報源、明示的な例外、現在のリビジョンを記録してください。

ローカルの契約を再構築する

現在有効な根拠のみを使用してください。

• 承認済みのデザインまたはブランドのドキュメント；
• リリース済みのトークンとコンポーネントの契約；
• オーナーが同じであることが証明された代表的なサーフェス；
• 1 つのユーザージャーニー内にある直接的な矛盾；
• この監査のために提供または調査したレンダリング結果。

リポジトリで承認済みと示されていない限り、草案や提案が示すのは将来の意図です。ドキュメントがないこと自体は UI の欠陥ではありません。

各指摘を立証する

指摘として残すには、次のすべてが必要です。

1. 観察事項： 対象サーフェスで生じている具体的なインターフェース上の影響；
2. 契約： そのプロパティに適用されるべきものを示す根拠；
3. 関連性： 引用したオーナーが影響を受けるサーフェスに到達する証明；
4. 修正： 製品の意図を創作しない、明確に定まった変更。

根拠が複数の相容れない修正案を支持する場合、その違いが意図的な例外である場合、または提案された修正が主にビジネス上の動作を変更する場合は、その候補を却下してください。

報告する前に、引用した情報源を再度開き、反証となる証拠がないか積極的に探してください。

報告

ユーザーへの影響、確信度、適用範囲、修正コストの順に、指摘を 5 件以内で返してください。

## Audit scope
- Surface:
- Governing evidence:
- Runtime owners:
- Explicit exceptions:

## Findings
| # | Observed problem | Evidence and connection | Required correction | Reach | Confidence |
|---|---|---|---|---|---|

## Highest-leverage change
<One finding, or “No supported recommendation.”>

立証の基準を満たすものがなければ、その旨を明確に伝えてください。報告を水増ししないでください。

選択された作業を計画する

ユーザーが指摘を選択した場合、または明示的に計画を依頼した場合は、references/change-plan.md を読んでください。根本原因ごとに、自己完結した計画を 1 つ作成してください。実行者が、オーナー、範囲、保持要件、検証方法を把握するために監査時の会話を参照する必要がないようにしてください。