mobile-redesign-app について
mobile-redesign-appは、モバイルアプリ全体を段階的に再設計する開発者向けのスキルです。全画面の監査とベースライン比較を行い、ナビゲーション変更は明示的な承認後にのみ適用します。
主な機能
- 01画面とナビゲーションの監査
- 02トークンとプラットフォーム方針の確認
- 03段階的な再設計の計画と実行
- 04ナビゲーション変更の承認必須化
- 05ベースラインとの回帰検証
活用シーン
- 01既存のモバイルアプリの評価
- 02段階的なデザインシステム統一
- 03再設計時のナビゲーション変更管理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ draftbit/ mobile-taste-skill --skill mobile-redesign-appインストール後、Claude Code で/mobile-redesign-appを入力して読み込まれたか確認します。
詳細
mobile-redesign-app: アプリ全体をフェーズごとに
手法ファイル。まずすべて読み込んでください:../_shared/references/redesign-protocol.md、
../_shared/references/review-rubric.md、../_shared/references/tells.md、および
../_shared/references/navigation.md(ナビゲーション監査用)。
フロー
1. 全体監査
スタックを確認してから、ルートツリー内のすべての画面を対象に、レビュー基準に沿った完全なチェック(静的+可能な場合は実機)を実施します。さらに、以下も行います。
- ナビゲーション監査: 現在のルートツリーを navigation.md の機械的チェック(タブ数/ロジック、コンテナの選択、戻る動作、ディープリンク)と照合します。問題が同じ形式で見えるよう、修正時に使う形式で現在のツリーを Nav Read として出力します。
- トークン監査: デザインシステムの所在、または存在しないという指摘。
- アプリの実装時点でのダイヤル評価と、プラットフォーム姿勢の一貫性。
design-baseline.jsonを作成します。以降、この基準と比較して再設計の効果を測定します。
2. モードとスコープの合意
維持するか刷新するかを一度だけ確認します。その後、各フェーズで redesign-protocol.md のレバーを1つずつアプリ全体に適用する計画を提示します。
Phase 1 Tokens + type/spacing (touches theme files + every screen mechanically)
Phase 2 Color onto semantic tokens; dark mode
Phase 3 States (skeleton/empty/error/offline/refresh) per data screen
Phase 4 Press feedback + motion layer
Phase 5 Screen recomposition (worst screens first, from the findings)
Phase 6 Navigation restructure (ONLY if the nav audit demands it - see below)
各フェーズについて、解消する指摘、変更するファイル、変更しない内容を示します。計画全体の承認を一度得たら、再確認を求めるのではなく、各フェーズの区切りでチェックポイント(短い要約+変更前/変更後)を設けます。
3. ナビゲーションの再構成(承認必須のフェーズ)
このスキルでは、現在と変更案の Nav Read の差分としてナビゲーションの変更を提案できます。その際、暗黙に変更してはならない項目(ルート名、ディープリンク、タブ順、習得済みのジェスチャー)をすべて明示し、移行に関する注記(名前を変更したディープリンクのリダイレクト、状態の移行)を添えます。この変更案は、差分について明示的な承認を得てから適用します。ナビゲーションに問題がなければ、その旨を伝えてこのフェーズを省略します。多くの再設計では、このフェーズは不要です。
4. 実行
各フェーズで redesign-protocol の修正ループを実施します。変更を独立したコミットにまとめ、変更前/変更後のペアを記録し、ベースライン上の指摘を解消します。アプリ規模に応じたリスク制御も行います(20%を超えたら停止し、1回あたりの修正は最大40件まで。大規模なアプリには複数回の実行が必要です。これは制限ではなく、設計上の仕様です)。実行中にフェーズの順序を変更することはできません。フェーズ2でフェーズ5の再構成を思いついても、寄り道せず、指摘として記録します。
5. 完了処理
レビュー基準で回帰テストを実施し、開始時のベースラインと比較した差分表を作成します(これが再設計の効果を示す証拠です)。残りの指摘も記録し、MOBILE-DESIGN.md(評価、ダイヤル、トークンの所在、Nav Read)を更新して、今後のセッションでも新しいシステムを引き継げるようにします。
厳守事項
- 刷新モードではビジュアル言語を変更しますが、承認必須の差分なしにコンテンツや IA を変更することはありません。
- 監査で得られたアクセシビリティ上の改善は、当然できているものと見なさず、回帰テストで確認します。
- 各フェーズの画面は、モバイルデザインセクション14の事前チェックに合格して初めて、そのフェーズのチェックポイントを完了したものと見なします。