Claude-skill-registry ios-ia-navigation
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/ios-ia-navigation" ~/.claude/skills/majiayu000-claude-skill-registry-ios-ia-navigation && rm -rf "$T"
manifest:
skills/data/ios-ia-navigation/SKILL.mdsource content
iOS Information Architecture & Navigation Design
iOSアプリの情報設計(IA)と画面遷移を、Apple HIGの原則に基づいて設計するスキル。
ミッション
ユーザー提供のドキュメント(PRD、要件、ブランド、既存仕様)を根拠に:
- 情報階層(トップレベル〜詳細の粒度)
- 画面構成(スクリーン一覧と役割)
- 画面遷移(push/modal/tab/splitのルール)
- 例外系(ログイン、ディープリンク、復帰、空状態)
をiOSのナビゲーション原則に一致する形で設計し、未確定情報は質問で埋めて設計を前進させる。
ワークフロー
Phase 0: 事前確認(必須)
以下をユーザーに確認してから設計を開始:
1. 入力ドキュメントの確認
- 要件ドキュメント(PRD、ユーザーストーリー、機能一覧)
- コンテンツ定義(扱う情報の種類、属性、関係)
- 運用制約(権限、課金、規約、オフライン要否)
- 既存資産(現行アプリ/サイト、分析データ)
- プラットフォーム条件(iPhone/iPad、最小iOS)
2. 初期質問(Blocker解消)
最低限以下を確認:
| # | 質問 | 影響範囲 |
|---|---|---|
| 1 | 主要ユーザーは誰? | ペルソナ、タスク優先度 |
| 2 | アプリを開いてやるTop3タスクは? | トップレベル構造 |
| 3 | 扱う主役の情報(エンティティ)は? | コンテンツモデル |
| 4 | 一覧→詳細で見る?作業(編集/作成)が主? | 遷移パターン |
| 5 | トップレベルに分けるべき領域は? | タブ/サイドバー設計 |
| 6 | ログイン必須?匿名でどこまで? | 認証フロー |
| 7 | iPadを主要ターゲットにする? | Split View設計 |
| 8 | 通知・外部リンクで特定画面に直接入る? | ディープリンク |
Phase 1-7: 設計モジュール実行
各モジュールを順次実行し、成果物を生成:
| Module | 目的 | 主要成果物 |
|---|---|---|
| 0 | ドキュメント根拠化 | Evidence Map、用語集 |
| 1 | タスクモデル化 | 主要タスクTop3-7、タスク分解 |
| 2 | コンテンツモデル | エンティティ、関係、階層候補 |
| 3 | トップレベル設計 | タブ/サイドバー構成、責務定義 |
| 4 | 遷移設計 | 遷移種別ルール(push/modal) |
| 5 | 状態保持設計 | タブごとの状態保持ポリシー |
| 6 | iPad適応 | カラム割り当て、並列表示方針 |
| 7 | ディープリンク | ルーティング表、状態復元規則 |
詳細は references/modules-detail.md を参照。
Phase 8: 成果物統合
すべてのモジュール成果物を統合し、最終ドキュメントを生成。
最終成果物
A. IA成果物
- A1. コンテンツモデル - エンティティ、属性、関係(YAML形式)
- A2. 情報階層マップ - サイトマップ(Mermaid図)
- A3. 命名規則 - タブ名・画面タイトルの語彙(表形式)
B. 画面&遷移成果物
- B1. 画面インベントリ - 画面ID、目的、主要要素、入口/出口(表形式)
- B2. 遷移ルール表 - from→to、トリガ、遷移種別、戻り方(表形式)
- B3. ユーザーフロー - 主要タスク別(Mermaid sequence図)
- B4. iPhone/iPad適応方針 - カラム構成、縮退時挙動(表形式)
C. 不確定管理
- Open Questions - 優先度、仮定、影響範囲(表形式)
テンプレート詳細は references/output-templates.md を参照。
規範資料(設計根拠)
| 資料 | 用途 |
|---|---|
| Apple HIG - Navigation | 遷移原則 |
| WWDC22「Explore navigation design for iOS」 | タブ設計、push/modal使い分け |
| WWDC22「The SwiftUI cookbook for navigation」 | NavigationStack/SplitView実装 |
主要原則は references/hig-navigation-principles.md を参照。
質問プロトコル
不足情報の分類
| 分類 | 定義 | 対応 |
|---|---|---|
| Blocker | 未回答だと構造が決まらない | 即時質問 |
| High-impact | 後で直せるが手戻り大 | 早期質問 |
| Detail | 後回し可能 | 暫定仮定で進行 |
質問形式
質問は「選択肢+影響」を添える:
Q: トップレベルはA/Bどちらが自然ですか? - A案: タブ3つ(Home/Search/Profile)→ シンプル、検索が独立 - B案: タブ5つ(上記+Notifications/Settings)→ 直接アクセス可、タブ多め 影響: 検索導線の置き場所、タブバーの密度
暫定仮定
返答がない場合は仮定で進め、ログに残す:
assumption: id: A001 content: "iPadはセカンダリターゲットとしてSplit View対応" impact: "変更時はModule 6再設計が必要" status: unconfirmed
設計品質ゲート
トップレベル設計チェック
- タブが情報階層を反映している
- 機能重複がない
- タブ強制移動を前提にしていない
- 各タブの責務が明確
遷移設計チェック
- push/modalの使い分けが一貫
- すべての画面に「出口」が定義
- 親状態の保持方法が明確
- modalの積み重ねを抑制
iPad適応チェック
- Split View対応が構造として成立
- Compact時の縮退が自然
- カラム間の関係が明確
ディープリンクチェック
- 全ルートが定義済み
- 直リンクでも現在地が説明可能
- 戻り方が破綻しない