🧭 本記事は Claude Code実務運用シリーズ の STEP 4「カスタムコマンド化する」です。
自作の前に、公式が用意した標準Skillの使い所を整理します。
シリーズ全体の地図と読む順は 親記事 にまとめています。
※ Android開発者は Android版 へ。
はじめに
この記事は、以前公開した Claude Code標準SkillをiOSアプリ開発でどう使うか という記事を、Claude Codeの最新changelogに合わせてアップデートしたものです。
公開当初は、Claude Codeのbundled skillsとして /simplify、/batch、/debug を中心に整理していました。
しかし、Claude Codeのchangelogを確認すると、/simplify は現在 /code-review に改名されています。また、以前のようなcleanup-and-fix寄りの挙動ではなく、現在は correctness bugを見つける差分レビュー用Skill として説明されています。
そのため、この記事では、以前の /simplify 中心の説明を、現在の推奨表記である /code-review 中心に更新します。
この記事で扱う主なSkillは以下です。
/code-review
/batch
/debug
加えて、実行確認に関係する補足として、以下も扱います。
/run
/verify
/run-skill-generator
iOSエンジニアが最初に使うなら、まずは以下の2つが実用的です。
/code-review
/batch
/code-review は実装後の差分レビューやバグ検出に、/batch は大きな変更を安全に分割する用途に向いています。
この記事でアップデートした内容
今回の主な更新点は以下です。
1. /simplify を /code-review に置き換えた
2. /code-review を「コード整理」ではなく「correctness bugを見つける差分レビュー」として説明した
3. /batch の説明を、worktreeとbackground subagentを使った大規模変更の分割という位置づけに更新した
4. /debug を、Claude Code側のセッション・設定・MCP・ログ調査用として整理した
5. /run /verify /run-skill-generator を、実行確認の補足として追加した
特に重要なのは、/simplify の扱いです。
古い記事や過去の説明では /simplify と書かれている場合がありますが、現在は /code-review を使う方が正確です。
旧表記:
/simplify
現在の推奨表記:
/code-review
/simplify がaliasとして動く環境もありますが、記事としては /code-review に統一した方が読み手に誤解を与えにくいです。
公式ドキュメント上の根拠
Claude CodeのSkillsドキュメントでは、Skillは SKILL.md に書かれた指示をClaudeのツールキットに追加する仕組みとして説明されています。
Claudeは必要に応じてSkillを使うことも、ユーザーが /skill-name の形で直接呼び出すこともできます。
また、Claude Codeにはbundled skillsが用意されており、/code-review、/batch、/debug、/loop、/claude-api などが含まれます。
重要なのは、bundled skillsは、多くの組み込みコマンドのように固定ロジックを直接実行するものではないという点です。
bundled skillsは prompt-based であり、Claudeに詳細なplaybookを渡し、Claudeがツールを使いながら作業を進めるものとして説明されています。
つまり、Claude CodeのSkillは「固定された処理を機械的に実行するコマンド」というより、Claudeに作業手順を渡して、Claude Code上のツール操作を含めて実行させるための標準ワークフロー と理解すると実務で使いやすくなります。
また、Claude CodeのCommandsドキュメントでは、/code-review は現在の差分をcorrectness bugsの観点でレビューし、ファイルを編集せずに結果を報告するSkillとして説明されています。
Claude Codeのchangelogでは、/simplify は /code-review に改名され、旧来のcleanup-and-fix挙動は削除されたと説明されています。
そのため、iOSアプリ開発の記事としては、/simplify を中心に説明するよりも、/code-review を中心に説明する方が現在の仕様に合っています。
iOSアプリ開発での基本方針
iOSアプリ開発でClaude Code標準Skillを使う場合、重要なのはSkill名そのものよりも、渡す前提条件の具体性です。
iOSアプリには、WebやAndroidとは異なる固有の確認観点があります。
- Deployment Target
- UIKit / SwiftUI のどちらが中心か
- Swift / Objective-C混在か
- Storyboard / Xib / Programmatic UI のどれを使っているか
- WKWebViewを使っているか
- Firebase Analytics / Crashlyticsを使っているか
- Push通知、Deep Link、Universal Linksがあるか
- 認証、課金、購入、会員登録など副作用の大きい導線があるか
- App Store審査やPrivacy Manifestに影響する変更か
たとえば、単に次のように入力するだけでは、Claudeは一般的な差分レビューとして判断します。
/code-review
iOSアプリ開発では、以下のように前提条件を付けた方が実用的です。
/code-review high 最近変更したSwift/Objective-Cコードを、iOS 15以上・UIKitベース・既存挙動維持の前提でレビューしてください。
確認観点:
- correctness bug
- 既存画面遷移への影響
- WKWebViewへの影響
- ログイン状態への影響
- Firebase Analytics / Crashlyticsへの影響
- Main Thread / MainActorでのUI更新
- Optional unwrapの安全性
- delegate / closureの循環参照
- テストで担保すべき観点
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
1. /code-review：実装後の差分レビューに使う
/code-review の位置づけ
/code-review は、現在の差分や指定した対象に対して、正しさに関係する問題を見つけるためのSkillです。
以前は /simplify という名称で説明されていましたが、現在は /code-review に改名されています。
/code-review には、次のような使い方があります。
/code-review
/code-review high
/code-review max
/code-review high --comment
/code-review high path/to/file.swift
low、medium、high、xhigh、max などのeffort levelを指定できます。
通常の業務では、まず high を使うとバランスが取りやすいです。
--comment を付けると、GitHub PR上にinline commentとして指摘を投稿できます。PRレビューの文脈では便利ですが、まずは通常の /code-review high でレビュー結果だけを確認する使い方が安全です。
iOS開発で使う場面
/code-review は、以下のような場面で有効です。
- ViewControllerの修正後に副作用を確認したい
- SwiftUI Viewの状態管理に問題がないか確認したい
- Optional unwrapによるクラッシュリスクを確認したい
- Objective-CとSwiftの橋渡し部分を確認したい
- Firebase Analyticsイベント送信処理の重複や揺れを確認したい
- WKWebViewやログイン処理を修正した後に副作用を確認したい
- 非同期処理やMainActorまわりの安全性を確認したい
- PR前に差分のcorrectness bugを洗い出したい
以前の /simplify という名前からは「コードをきれいに整理する」「自動でリファクタリングする」という印象を受けやすいですが、現在の /code-review は、あくまで 差分の正しさを確認するレビュー用途 として使う方が実務向きです。
そのまま使えるプロンプト例
/code-review high 最近変更したSwift/Objective-Cファイルをレビューしてください。
前提:
- iOS 15以上を対象にする
- UIKitベースの既存アプリ
- Swift / Objective-Cが混在している
- 既存挙動は変えない
- public interfaceは不用意に変更しない
- まだコードは変更しない
確認観点:
- correctness bug
- 既存挙動の破壊
- Optional unwrapによるクラッシュリスク
- Main Thread / MainActorでのUI更新
- 非同期処理のキャンセル漏れ
- delegate / closureの循環参照
- ログイン状態への影響
- WKWebViewへの影響
- Firebase Analytics / Crashlyticsへの影響
- テストで担保すべき観点
出力形式:
- 対象ファイル
- 問題箇所
- 問題の理由
- 影響範囲
- 修正方針
- 優先度: High / Medium / Low
- 事実 / 仮説 / 不明点
ViewController向けの例
/code-review high UserProfileViewController.swiftを中心に、最近変更したコードをレビューしてください。
目的:
- ViewControllerの修正によって既存挙動が壊れていないか確認する
- 表示ロジック、API呼び出し、画面遷移処理の副作用を確認する
- 既存のログイン状態や画面遷移に影響がないか確認する
制約:
- まだコードは変更しない
- UIKit前提
- iOS 15以上前提
- 大規模なアーキテクチャ変更は提案だけにする
- 事実、仮説、不明点を分けて出す
SwiftUI向けの例
/code-review high ProductListView.swiftを確認してください。
目的:
- SwiftUIの状態管理に問題がないか確認する
- 非同期処理とView更新の関係を確認する
- 既存UIの見た目や画面遷移が壊れていないか確認する
確認観点:
- State / Binding / ObservableObjectの責務
- 非同期処理の扱い
- MainActorでのUI更新
- 再描画が増えそうな箇所
- Previewしやすい構造か
- UI Testで確認しやすい構造か
制約:
- 既存UIの見た目は変えない
- 既存の画面遷移は変えない
- まずレビュー結果だけを出す
- 修正案は小さな単位に分ける
Analyticsイベント追加後の例
/code-review high 最近追加したAnalyticsイベント送信処理をレビューしてください。
確認観点:
- 同じイベント送信処理が重複していないか
- イベント名やパラメータ名に揺れがないか
- 個人情報に該当しうる値を送っていないか
- 画面表示時とタップ時の送信タイミングが混ざっていないか
- 既存の計測仕様と矛盾していないか
- テストしやすい設計になっているか
制約:
- 既存の計測仕様を変えない
- 不明点は推測で断定せず、確認事項として出す
ポイント
既存アプリでは、いきなり修正させるよりも、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
/code-review は、コードを勝手に整理させるためのものではなく、差分の問題を見つけるためのレビュー用途として使うのが実務向きです。
2. /batch：大規模変更を安全に分割する
/batch の位置づけ
/batch は、複数ファイル・複数画面・複数導線にまたがる大きな変更を、独立した作業単位へ分割するためのSkillです。
Claude CodeのCommandsドキュメントでは、/batch はコードベースを調査し、5〜30個程度の独立した作業単位に分解し、承認後に各作業を個別のgit worktreeとbackground subagentで進めるものとして説明されています。
そのため、/batch は1ファイルだけの軽微な修正には向きません。
影響範囲が広い変更を、安全に分けて進めたいときに使うのが適切です。
iOS開発で使う場面
- ダークモード対応
- deprecated APIの置換
- Objective-CからSwiftへの段階移行
- UIKit画面の一部SwiftUI化
- WKWebView処理の共通化
- Analyticsイベント設計の整理
- Firebase Crashlyticsログ方針の整理
- App Store審査やPrivacy Manifestに関係する修正
- 複数画面にまたがるUI改修
ダークモード対応の例
/batch iOSアプリのダークモード対応を安全に進めるため、影響範囲を調査して作業単位に分割してください。
前提:
- iOS 15以上
- UIKitベースの既存アプリ
- Swift / Objective-Cが混在している
- 既存の画面遷移や表示仕様は変えない
- まず調査と分割計画だけを出す
- まだコード変更はしない
確認観点:
- ハードコードされた色
- UIColorの直接指定
- Asset CatalogのColor Set化候補
- Storyboard / Xib内の色指定
- NavigationBar / TabBar / Toolbarの見え方
- WKWebViewを含む画面の背景色
- 画像アセットの視認性
- Dynamic Typeやアクセシビリティへの影響
出力形式:
## 作業分割案
1. 対象領域
2. 対象ファイル
3. 修正方針
4. リスク
5. テスト観点
6. 推奨する実施順序
Objective-CからSwiftへの段階移行の例
/batch Objective-Cで実装されている一部のユーティリティ処理をSwiftへ段階移行する計画を作ってください。
前提:
- 既存アプリはObjective-CとSwiftが混在している
- 一度に大きく移行しない
- 既存のpublic APIをできるだけ維持する
- まず調査と分割計画だけを出す
- まだコード変更はしない
確認観点:
- Swift化しやすいクラス
- 依存関係が少ないファイル
- Objective-Cから参照されている箇所
- Bridging Headerへの影響
- Unit Testを先に用意すべき箇所
- 移行後のリグレッションリスク
WKWebView処理の共通化の例
/batch アプリ内のWKWebView関連処理を調査し、共通化できる箇所を作業単位に分割してください。
前提:
- 既存挙動を変えない
- ログイン、外部ブラウザ遷移、Cookie、JavaScript連携への影響を重視する
- まず調査結果と作業分割だけを出す
- まだコード変更はしない
確認観点:
- navigationDelegateの重複
- target="_blank" 相当の処理
- 外部ブラウザへ逃がすURL判定
- Cookieやセッションの扱い
- JavaScript bridgeの安全性
- エラー画面表示
- ローディング表示
- テスト観点
Privacy Manifest対応の例
/batch Privacy ManifestやRequired Reason APIに影響しそうな変更を調査し、確認作業を分割してください。
前提:
- iOSアプリのリリース前確認
- 追加SDKや新規API利用がある可能性がある
- まず調査と確認項目の整理だけを行う
- まだ設定ファイルは変更しない
確認観点:
- Required Reason APIに該当するAPI利用
- PrivacyInfo.xcprivacyの更新要否
- 追加SDKのPrivacy Manifest対応状況
- Firebaseなど外部SDKの影響
- App Store審査で説明が必要になりそうな変更
- リリース前に確認すべき項目
ポイント
/batch は小さな修正よりも、影響範囲が広い変更を分解する用途に向いています。
特にiOSアプリでは、1つの変更が以下に波及することがあります。
- ログイン状態
- 課金・購入導線
- WebView
- Push通知
- Deep Link / Universal Links
- Firebase Analytics / Crashlytics
- App Store審査
1ファイルだけの軽微な修正であれば、通常のプロンプトや /code-review の方が扱いやすいです。
一方で、複数画面・複数ファイル・複数導線にまたがる変更では、いきなり実装させるよりも、まず /batch で影響範囲と作業分割を整理する方が安全です。
3. /debug：iOSアプリのデバッグではなく、Claude Code側の不調調査に使う
/debug の位置づけ
/debug は、Claude Codeのセッション、設定、MCP、ツール実行、ログまわりを調査するためのSkillです。
名前だけを見ると、iOSアプリのクラッシュ調査に使うものだと思うかもしれません。
ただし、実務上は、/debug はiOSアプリのクラッシュ解析そのものというより、Claude Codeのセッション、設定、MCP、ツール実行がうまく動かないときの調査 に使うものと考える方が自然です。
Claude CodeのCommandsドキュメントでは、/debug は現在のセッションでdebug loggingを有効にし、session debug logを読んで問題を調査するSkillとして説明されています。
そのため、/debug はiOSアプリそのもののバグ解析というより、Claude Codeの実行環境、設定、MCP、permission、ツール実行、ログまわりの調査に向いています。
iOS開発で使う場面
- Claude CodeがXcodeプロジェクトを正しく認識しない
- xcodebuildの実行結果を正しく読めていない
- MCPツールが動かない
- .claude/skills 配下のSkillが認識されない
- permission promptが多すぎる
- ファイルアクセスやパス解決がおかしい
- Claude Codeから実行したコマンドと手元のターミナル実行結果が違う
xcodebuild実行失敗の例
/debug Claude Codeからxcodebuild testを実行したときに失敗します。
状況:
- ターミナルで手動実行すると成功する
- Claude Codeから実行するとschemeが見つからないと言われる
- workspaceまたはschemeの指定に問題がある可能性があります
確認してほしいこと:
- Claude Codeの現在の作業ディレクトリ
- 利用しているworkspace / project
- scheme指定
- 実行コマンド
- 権限やパスの問題
- Claude Codeのログ上でどこから失敗しているか
Skillが認識されない場合の例
/debug .claude/skills 配下に追加したSkillがClaude Codeで認識されません。
確認してほしいこと:
- .claude/skills の配置場所
- SKILL.md の有無
- frontmatterの形式
- Claude Codeの現在のproject root
- commands一覧に出ているか
- ログ上の読み込みエラー
MCPが動かない場合の例
/debug Claude CodeからMCPツールを呼び出したときに失敗します。
確認してほしいこと:
- MCPサーバーが認識されているか
- 設定ファイルが正しいか
- 権限エラーが出ていないか
- Claude Codeのログ上でどこで失敗しているか
- 再設定が必要か
iOSアプリのクラッシュ調査は通常プロンプトで行う
iOSアプリのクラッシュログを調査したい場合は、/debug ではなく、通常のプロンプトで依頼した方が明確です。
以下のiOSクラッシュログと関連コードを調査してください。
目的:
- クラッシュ原因の仮説を出す
- 再現条件を整理する
- 修正候補を出す
- 影響範囲を確認する
- 必要なテスト観点を作る
制約:
- 推測は「仮説」と明記する
- 断定できない場合は「不明」と書く
- 既存挙動を変えない修正を優先する
- まず原因分析だけを出し、コード変更はしない
確認観点:
- Optional unwrap
- delegate / dataSource
- async / await
- MainActor
- UIViewController lifecycle
- WKWebView
- Firebase Crashlytics
- release build特有の挙動
4. /run・/verify・/run-skill-generator：実行確認の補助として使う
位置づけ
Claude CodeのSkillsドキュメントでは、アプリを起動して変更を確認するためのbundled skillsとして、/run、/verify、/run-skill-generator も紹介されています。
/run
/verify
/run-skill-generator
これらは、テストや型チェックだけでなく、実際にアプリを起動して変更を確認するためのSkillです。
/run はアプリを起動して変更が動いているか確認するために使います。
/verify は、コード変更が意図どおりに動くかを、ビルド・起動・観察によって確認するために使います。
/run-skill-generator は、/run や /verify がプロジェクトをビルド・起動するための手順を学習・記録するために使います。
iOS開発で注意すべき点
iOSアプリの場合、ビルド・起動・Simulator・scheme・workspace・証明書・環境変数など、プロジェクト固有の前提が多くなりがちです。
そのため、iOS開発では、いきなり /run や /verify に任せるよりも、以下の情報を整えてから使う方が現実的です。
- 使用する .xcworkspace / .xcodeproj
- scheme
- configuration
- destination
- xcodebuild test の実行コマンド
- Simulatorでの起動手順
- 必要な環境変数
- Firebase設定ファイルの扱い
- 社内環境でのみ必要な設定
iOS向けの使い方例
/run-skill-generator このiOSプロジェクトをビルド・起動・確認するための手順を記録してください。
前提:
- Xcodeプロジェクトです
- workspaceは BookLive.xcworkspace を使います
- schemeは BookLive を使います
- iOS Simulatorでの確認を前提にします
- テスト実行には xcodebuild test を使います
記録してほしいこと:
- clean buildの手順
- test実行コマンド
- Simulator起動手順
- よく失敗するポイント
- Claude Codeが次回以降に参照できる確認手順
変更後の確認では、次のように使えます。
/verify 今回の変更で、ログイン済みユーザーの購入導線に影響がないか確認してください。
確認観点:
- アプリがビルドできること
- 対象画面まで遷移できること
- 既存の購入導線が壊れていないこと
- エラーやクラッシュが発生しないこと
ポイント
/run や /verify は便利ですが、iOSアプリではプロジェクト固有の起動条件が多いため、最初に実行手順を明文化しておくことが重要です。
README、Makefile、ビルドスクリプト、.claude/skills などにプロジェクト固有の手順を残しておくと、Claude Codeの再現性が上がります。
実務で使いやすい組み合わせ
実装前：影響範囲を整理する
今回の変更について、iOSアプリ開発の観点で影響範囲を整理してください。
前提:
- iOS 15以上
- UIKitベース
- Swift / Objective-C混在
- 既存挙動を変えない
- public APIや画面遷移仕様を不用意に変更しない
確認観点:
- 対象画面
- 対象ファイル
- 画面遷移への影響
- ログイン状態への影響
- 課金・購入導線への影響
- WKWebViewへの影響
- Firebase Analytics / Crashlyticsへの影響
- App Store審査やPrivacy Manifestへの影響
- Unit Test / UI Testで確認すべきこと
まだコードは変更しないでください。
大きい変更：/batch で分割する
/batch 今回の変更を安全に進めるため、作業を独立した単位に分割してください。
前提:
- iOS 15以上
- UIKitベース
- Swift / Objective-C混在
- 既存挙動を変えない
- まず調査と計画だけを出す
- すぐにコード変更しない
出力:
- 作業単位
- 対象画面
- 対象ファイル
- 依存関係
- リスク
- テスト観点
- 推奨順序
実装後：/code-review でレビューする
/code-review high 最近変更したSwift/Objective-Cファイルを確認してください。
目的:
- 既存挙動を壊す可能性がある問題を見つける
- correctness bugを検出する
- iOSアプリとしての副作用を確認する
確認観点:
- Main Thread / MainActorでのUI更新
- Optionalの安全性
- delegate / closureの循環参照
- 非同期処理
- ViewControllerの責務
- Analyticsイベントの重複
- WKWebViewやログイン導線への影響
- テスト観点
まずレビューだけを出し、コード変更はしないでください。
起動確認：/verify を使う
/verify 今回の変更が対象画面で正しく動作するか確認してください。
前提:
- iOS Simulatorで確認する
- 既存のログイン済み状態を前提にする
- 購入導線やWKWebViewに副作用がないか確認する
確認観点:
- ビルド成功
- アプリ起動
- 対象画面への遷移
- クラッシュなし
- 既存導線への副作用なし
Claude Codeが不調：/debug で調査する
/debug Claude CodeがiOSプロジェクト内のファイルを正しく認識していないようです。
確認してほしいこと:
- 現在の作業ディレクトリ
- .xcodeproj / .xcworkspace の場所
- scheme一覧
- .claude 配下の設定
- permission関連の問題
- xcodebuild実行時のパス
- 実行ログ上のエラー
iOS開発で使うときの注意点
1. /simplify ではなく /code-review を使う
古い記事や過去の説明では /simplify と書かれている場合があります。
現在は /code-review を中心に書く方が正確です。
古い表記:
/simplify
現在の推奨表記:
/code-review
/simplify がaliasとして動く環境もありますが、記事としては /code-review に統一した方が読み手に誤解を与えにくいです。
2. いきなり修正させない
既存アプリでは、まずレビューだけにするのが安全です。
まだコードは変更しないでください。
まずレビュー結果だけを出してください。
特に、ログイン、課金、WebView、Push通知、Deep Link、Analyticsなどに関係する変更では、レビューと修正を分けた方が安全です。
3. iOSの前提条件を明記する
前提:
- iOS 15以上
- UIKit / SwiftUI
- Swift / Objective-C混在
- Storyboard / Xib / Programmatic UI
- 既存挙動を変えない
- public APIは不用意に変更しない
iOSアプリはプロジェクト構成の差が大きいため、Deployment Target、UI実装方式、Swift / Objective-C混在の有無、テスト構成を明記した方が精度が上がります。
4. WebView・認証・課金導線は重点確認する
以下の導線に影響がないか重点的に確認してください。
- WKWebView
- ログイン
- 会員登録
- 課金・購入
- Push通知
- Deep Link / Universal Links
- Firebase Analytics / Crashlytics
これらは、1ファイルの修正でもユーザー体験、売上、ログイン状態、計測、審査に影響する可能性があります。
5. Privacy ManifestやRequired Reason APIも確認する
App Store審査やPrivacy Manifestに影響する変更がないか確認してください。
確認観点:
- Required Reason API
- Privacy Manifest
- 追加SDK
- トラッキング関連
- Firebaseなど外部SDKの利用
- App Store審査で説明が必要になりそうな変更
6. テスト観点まで出させる
最後に、確認すべきUnit Test / UI Test / 手動確認観点を出してください。
iOSアプリの場合、特に以下の観点が重要です。
- ログイン済み / 未ログイン
- 通信成功 / 通信失敗
- 初回起動 / 通常起動
- ライトモード / ダークモード
- Dynamic Type
- 端末回転
- Push通知経由の起動
- Deep Link経由の起動
- WKWebView内リンクタップ
- 課金・購入導線
7. 事実・仮説・不明点を分けさせる
事実、仮説、不明点を分けて出してください。
推測は「仮説」と明記してください。
ログやコードから確認できないことは断定しないでください。
AIの出力では、事実と推測が混ざることがあります。
チーム共有やPRレビューに使う場合も、この指定は有効です。
まとめ
Claude Codeの標準Skillは、単なる固定処理を実行するコマンドではありません。
Claudeに標準化された作業手順を渡し、Claude Code上のツール操作を含めて作業を進めるための仕組みです。
最新の状況を踏まえると、iOSアプリ開発では以下の使い分けが実用的です。
/code-review
- 実装後の差分レビュー
- correctness bugの検出
- PR前の確認
/batch
- 大規模変更の分割
- 影響範囲調査
- 作業単位と実施順序の整理
/debug
- Claude Code側の不調調査
- MCP、設定、ログ、permission、xcodebuild実行まわりの確認
/run / verify / run-skill-generator
- アプリ起動や変更確認の補助
- iOSではプロジェクト固有の起動手順を先に整えると効果的
iOSエンジニアが最初に使うなら、まずは以下の2つから始めるのが実用的です。
/code-review
/batch
/code-review は実装後のバグ検出や差分レビューに、/batch は大きな変更を安全に分割する用途に向いています。
そして、Claude Code自体の挙動が不安定なときは /debug を使い、ビルドや起動確認までClaude Codeに任せたい場合は /run、/verify、/run-skill-generator を検討するとよいです。
重要なのは、単にSkill名を入力することではありません。
以下のような iOS開発固有の前提条件 を明示することです。
- iOS 15以上
- UIKit / SwiftUI
- Swift / Objective-C混在
- Storyboard / Xib / Programmatic UI
- WKWebView
- Firebase Analytics / Crashlytics
- Push通知
- Deep Link / Universal Links
- App Store審査
- Privacy Manifest
- 既存挙動を変えない
- まずレビューだけ
- 事実・仮説・不明点を分ける
- テスト観点まで出す
Claude Code標準Skillは、うまく使えば単なるコード生成ツールではなく、設計レビュー、影響範囲調査、差分レビュー、実行確認、Claude Code自体の不調調査まで支援する開発パートナーとして活用できます。
参考リンク
このシリーズの歩き方
Claude Code実務運用シリーズ ― 暴走させない、から仕組みにするまで。
- ◀ 前の記事: 電子書籍アプリ開発で考える Claude Code の
/goalコマンド入門：AI に「完了条件」まで進めてもらう - ▶ 次の記事: Appleのデザイン原則をAIコーディングへ。apple-design SkillをCodex／Claude Codeに導入する
- 🔍 あわせて読む: Claude Codeは「コードを書くAI」で終わらせるな：公式 document-skills でPDF・Excel・Word・PowerPointまで自動化する ― 標準Skillの次は公式document-skills
- 🗺 シリーズ全記事の地図(親記事)