swift-diagnostics について
iOS・macOS 開発者向けのデバッグスキルです。診断ツリーに沿って、ナビゲーション、ビルド、メモリ、パフォーマンスの問題を体系的に調べます。
主な機能
- 01症状別の診断ワークフロー
- 02診断ツリー付きの参照ガイド
- 03必須の初期チェック
- 04一つずつ変更して検証
- 05最小再現例の作成ガイド
活用シーン
- 01NavigationStack やディープリンクの不具合調査
- 02Swift パッケージのビルドや依存関係の問題調査
- 03循環参照やメモリ増加の確認
- 04ビルド遅延や Xcode の停止の診断
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/swift-diagnosticsを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/build-issues.mdbuild-performance.mdmemory.mdnavigation.mdxcode-debugging.md詳細
Swift Diagnostics
iOS/macOS 開発のための体系的なデバッグワークフローです。これらのパターンに沿って構造化された診断アプローチを実践することで、数時間ではなく数分で根本原因を特定できます。
リファレンスの読み込みガイド
内容が必要になる可能性が少しでもある場合は、必ずリファレンスファイルを読み込んでください。 パターンを見落としたり、間違えたりするより、事前にコンテキストを把握しておくほうが適切です。
| リファレンス | 読み込むタイミング |
|---|---|
| ナビゲーション | NavigationStack が応答しない、予期しないポップが発生する、ディープリンクに失敗する場合 |
| ビルドの問題 | SPM の解決、"No such module"、依存関係の競合 |
| メモリ | 循環参照、メモリ使用量の増加、deinit が呼び出されない場合 |
| ビルドパフォーマンス | ビルドが遅い、Derived Data の問題、Xcode がハングする場合 |
| Xcode のデバッグ | LLDB コマンド、ブレークポイント、ビューのデバッグ |
基本的なワークフロー
- 症状のカテゴリを特定する - ナビゲーション、ビルド、メモリ、またはパフォーマンス
- 関連するリファレンスを読み込む - 各リファレンスには診断用の決定木があります
- 必須の初期チェックを実行する - コードを変更する前に行います
- 決定木に沿って進める - 2～5 分で診断にたどり着きます
- 修正を適用して検証する - 一度に 1 つの修正を行い、そのつどテストします
重要な原則
「不可解な」問題の 80% は、予測可能なパターンに起因します。
- ナビゲーション：Path の状態管理または遷移先の配置
- ビルド：古いキャッシュまたは依存関係の解決
- メモリ：タイマー／オブザーバーのリークまたはクロージャのキャプチャ
- パフォーマンス：コードのバグではなく、環境の問題
体系的に診断してください。決して推測しないでください。
よくある間違い
-
必須の初期チェックを省略する — 診断を行う前にコードの変更（クリーンビルド、シミュレーターの再起動、Xcode の再起動）に取りかかると、存在しない問題を追いかけることになります。必ず必須チェックから始めてください。
-
複数の変更を一度に行う — 「DerivedData を削除して、シミュレーターを再起動して、Xcode を強制終了しよう」では、実際にどの修正が効果を発揮したのか特定できません。変数は一度に 1 つずつ変更してください。
-
原因が分かっていると思い込む — 「NavigationStack が動かなくなった。原因は自分の reducer に違いない」——実際には DerivedData が古かっただけかもしれません。診断用の決定木を使えば、思い込みを防げます。推測せず、決定木に従ってください。
-
メモリに関する基本事項を見落とす —
deinitが呼び出されないのは循環参照が原因ですが、初心者はアーキテクチャのせいにしがちです。リファクタリングする前に、Instruments を使ってリークを検証してください。直感ではなく、データに基づいて判断してください。 -
問題を切り分けない — アプリ全体でテストすると診断が複雑になります。問題の機能だけを含む最小限の再現例を作成してください。切り分けることで根本原因が明らかになります。