harden について
harden は ui-craft の本番向け UI 強化サブスキルで、デザインや開発の作業に使います。共通のカバレッジ表と画面種別ごとの確認を行い、リスクを報告して安全に対応できる問題を修正します。
主な機能
- 01ローディング、空状態、エラーの確認
- 02部分データ、長文、i18n の確認
- 03オフライン、権限、初回利用状態の確認
- 04画面種別ごとのカバレッジ評価
- 05状態の報告と安全な問題の修正
活用シーン
- 01リリース前の UI の堅牢性とアクセシビリティ確認
- 02次の操作が示されないエラーの検出
- 03アクセス制限やデータ欠落時の表示確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/hardenを入力して読み込まれたか確認します。
詳細
コンテキスト： このサブスキルは、より広範な ui-craft スキルを構成する一つの視点です。ui-craft スキルもインストールされている場合は、まずその SKILL.md を読み、Discovery + Anti-Slop + Craft Test を確認してから、以下の特定の視点を適用してください。
$ARGUMENTS の UI を本番環境向けに堅牢化します。ui-craft スキルを読み込んでください。
対象範囲のマトリクス — すべての重要な画面領域を確認してください：
- 読み込み中 — スケルトンは最終的なレイアウトに合わせます（読み込み完了時に CLS が発生しないようにします）。高速な応答時のちらつきを避けるため、表示は約 200ms 後にします。スケルトンを表示できる場合、画面中央に汎用スピナーを表示してはいけません。
- 空の状態 — 意図的に設計します。空である理由を説明する 1 行のテキストと、明確な主アクションを 1 つ用意します。イラストは任意ですが、CTA は必須です。
- エラー — インラインで、次のアクションがわかるようにします。「保存に失敗しました。再試行／エラーをコピー／サポートに問い合わせ」のようにします。「問題が発生しました」だけで済ませてはいけません。何が起きたかと、次に何をすべきかを示します。
- 一部のデータのみ — 値が本当に不明な指標には
—（em ダッシュ）を使い、N/A、null、0は使いません。 - 長いコンテンツ —
titleツールチップとtext-overflow: ellipsisで省略し、制約のある領域にはコンテナークエリを使います。120 文字の名前でテストします。 - i18n — ハードコードされた文字列を使わず、ドイツ語でテキストが約 1.3 倍に増える余裕を持たせ、CJK の文字幅が狭いことを考慮し、方向に応じて反転するアイコンは RTL を考慮します。
- オフライン／低速 — 失敗時に整合性を取り直す楽観的 UI を使います。タイムアウト後もスケルトンを表示し、「まだ読み込み中…」といった案内を提示します。
- 権限 — ユーザーにアクセス権がない場合の挙動（無効化するか、非表示にするか）を確認します。無効化する場合は必ず理由（ツールチップ、インラインの補足説明）を示します。
- ゼロ状態 → 初回利用 — 5 ステップのツアーより、インラインのヒントを優先します。画面の上に重ねて案内するのではなく、画面内で案内します。
ノブに依存しない項目 — 正しさは調整可能なものではありません。CRAFT_LEVEL／MOTION_INTENSITY／VISUAL_DENSITY にかかわらず、マトリクス全体を確認してください。
続いて、アーキタイプの対象範囲を確認してください。 上記 9 項目は画面全般に関わるもので、この画面がどの種類なのかは考慮しません。アーキタイプ（データテーブル、設定、検索、詳細ビュー、初回利用、請求、料金、ドキュメントページ、チェックアウト、オンボーディング、破壊的操作の確認、招待／共有）を特定し、該当する項目を確認してください。
- MCP 接続あり → アーキタイプを指定して
ux_coverageを呼び出します。該当アーキタイプの項目と報告形式が返されます。 - MCP なし →
references/coverage.mdの該当セクションを読みます。 - 該当するアーキタイプなし → この手順を省略し、その旨を 1 行で記載します。対象範囲は意図的に部分的なものです。リストにない画面は不備ではありません。
各項目には、実装されている状態、構築時に適用する ui-craft のルール、それがない場合にユーザーが失うものが記載されています。不足していることだけでなく、その影響も報告してください。「エクスポート機能なし」は状態の説明です。「ユーザーは画面上の 24 行を期待しているのに、10,000 行を受け取る」は、それが重要な理由です。
読むべき参考資料：references/accessibility.md（キーボード操作とスクリーンリーダーでの操作経路）、references/copy.md（エラーと空の状態で使う文体）、references/motion.md の Rendering Performance セクション（スケルトンの動きと動きを抑える設定）。
出力：2 つのセクションを並べて報告し、決して統合しないでください。
- 堅牢化マトリクス — 上記 9 項目それぞれに「あり／一部あり／なし」のいずれかを付けます。
- 対象範囲 — アーキタイプの項目それぞれに あり／一部あり／なし／対象外／不明 のいずれかを付けます。「対象外」とする場合は理由を明記してください。ここで適用されない理由を説明できない場合は、「なし」とします。「不明」とする場合は、追加情報によって判断できるかどうかを示します。
どちらのセクションにも、スコア、件数、パーセンテージを記載しないでください。「9 項目中 7 項目」のような表現は、「対象外」を不備のように見せ、堅牢化作業を採点に変えてしまいます。対象範囲の確認はリリースを妨げるものではありません。結果を報告し、ビルドはそのままリリースします。
続いて、不足している箇所を修正するため、コードを編集してください。修正内容を示す Review Format テーブルを出力してください。安全に自動修正できなかった項目（バックエンドが必要、設計上の判断が必要、翻訳ファイルが必要）について、「引き続きリスクあり」のリストで締めくくってください。
次のステップ： /finalize — 出荷前のゲート（第 3 段階）。