The Ultimate Claude Code Command Dictionary: A Complete Guide for Power Users

Codeタブで使えるコマンド・公式Skills・実践ワークフローを徹底解説

この記事で扱う「コマンド」の範囲

この記事で扱うのは、Claude DesktopのCodeタブにある入力欄で実行するコマンドです。

具体的には、入力欄の先頭に「/」を入力するか、入力欄の横にある「＋」ボタンから「Slash commands」を選んで呼び出します。

対象になるのは、次の3種類です。

• Claude Code本体に組み込まれたコマンド
• Anthropicが同梱している公式Skills
• ProjectやPluginから追加されたSkills

逆に、ターミナルからClaude Codeを起動する方法、起動フラグ、非対話実行、外部Scriptからの操作なんかは、この記事では扱いません。

Claude Desktopでは、モデル、Permission mode、Plugin、Connector、Diff、Taskといった多くの操作を、GUIからできるようになっています。

だから、ターミナル版で使うコマンドの一部は、Desktopでは表示されなかったり、GUI操作へ置き換えられていたりするんです。

自分の環境で実際に使えるコマンドを確かめる、いちばん確実な方法。

それは、Codeタブの入力欄で「/」を入力してみることです。

表示される中身は、OS、契約プラン、実行環境、導入済みPlugin、Project Skillsによって変わります。

第1章　Claude Desktopでコマンドを呼び出す方法

Claude DesktopのCodeタブでは、コマンドを2つの方法で呼び出せます。

1つ目は、入力欄の先頭に「/」を入力する方法です。

/

候補の一覧が出てくるので、そのまま文字を続けて入力すると、絞り込めます。

/ver

こうすると、「/verify」みたいに「ver」を含む候補が表示されます。

2つ目は、入力欄の横の「＋」ボタンから「Slash commands」を選ぶ方法です。

一覧には、次のものがまとめて表示されます。

• Built-in Commands
• Anthropic公式のBundled Skills
• ユーザーが作成したSkills
• Project内のSkills
• 導入済みPluginのSkills

選ぶと、コマンド名が入力欄に強調表示された状態で挿入されます。

その後ろに依頼内容を書いて、送信すればOKです。

コマンドは入力の先頭に置く

コマンドとして認識させるには、原則としてメッセージの先頭に置きます。

正しい例。

/plan 認証機能をSession Cookie方式へ移行する計画を作って

次の書き方だと、ふつうの自然言語として解釈されることがあります。

最初に /plan を使って認証機能を調べて

コマンド名の後ろに書いた文章は、そのコマンドへ渡す引数、または依頼内容として扱われます。

複数のSkillを一度に組み合わせる

Claude Code v2.1.199以降では、入力の先頭に最大6個のSkillを並べられます。

/security-context /api-rules /test-policy 認証APIを実装して

こうすると、指定したすべてのSkillが読み込まれて、後ろの依頼が各Skillへ渡されます。

ただし、数を増やせばいつも良くなる、というわけじゃないんですよね。

似たSkillを重ねすぎると、こんな問題が起きます。

• 指示同士が競合する
• コンテキスト消費が増える
• 優先順位が曖昧になる
• 不要な手順まで実行する
• 完了条件が複雑になる

Skillは、いまの仕事に直接関係するものだけを組み合わせましょう。

第2章　Sessionとコンテキストを整理するコマンド

Claude Desktopでは、Sessionごとに会話履歴、Project Folder、変更内容、コンテキストが独立しています。

長い作業になってくると、「いまの会話を続けるべきか」「要約すべきか」「別のSessionへ分けるべきか」を判断する場面が出てきます。

そこで役立つのが、この章のコマンドたちです。

/clear

/clear

いまの会話を終えて、空のコンテキストで新しいConversationを始めます。

古いConversationが完全に消えるわけじゃありません。

DesktopのSidebarには過去のSessionが残るので、あとから戻れます。

名前を付けて区切る場合。

/clear auth-investigation

/clear が向いているのは、こんな場面です。

• 認証機能の作業が終わって、課金機能へ移る
• 過去の仮説や、間違った調査結果を引き継ぎたくない
• 別のIssueに着手する
• 会話が長くなって、目的まで変わってきた
• いまの作業とは無関係なコンテキストが多い

反対に、いまと同じ仕事を続けたいなら、次の /compact を使います。

/compact

/compact

同じConversationを保ったまま、過去の会話やTool結果を要約して、コンテキストを空けます。

要約のときに「これは残して」という内容も指定できます。

/compact 認証方式の決定、変更したファイル、失敗中のテスト、未完了タスクを必ず残して

/compact が向いているのは、こんな場面です。

• 同じ機能開発を長時間つづけている
• コンテキストの使用量が増えてきた
• 過去の検索結果や、長いLogが大量に残っている
• 重要な設計判断は残したい
• Sessionを分けるほど、目的は変わっていない

Claude Desktopでは、コンテキストが満杯に近づくと、自動でも要約されます。

ただ、自動要約が始まる前に自分で /compact を実行すれば、どの情報を残すかを指定できます。

/context

/context

いまのコンテキストを、何が消費しているのかを確認します。

主な確認対象は、次のとおり。

• Conversation History
• CLAUDE.md
• Rules
• Skills
• MCP Tool定義
• File内容
• Tool Result
• System Instruction

詳細を表示する場合。

/context all

/context を実行するといい「サイン」は、こんな感じです。

• Claudeが過去の依頼と、いまの依頼を混同する
• 関係のないSkillが大量に読み込まれている
• MCPを追加してから、Contextが急に減った
• CLAUDE.mdを大きくしたあと、応答が不安定になった
• 長時間Sessionで、重要な指示を忘れ始めた
• 同じ説明を、何度も繰り返すようになった

問題が会話履歴なら /compact、目的そのものが変わったなら /clear を使います。

/branch

/branch alternative-auth

いまの会話をその地点で複製して、自分自身が複製先のConversationへ移動します。

元のConversationは残るので、いまの案を失わずに別案を試せます。

たとえば、こんな使い方ができます。

/branch jwt-version

元のSessionではSession Cookie方式を進めて、Branch先ではJWT方式を検討する、という具合ですね。

/branch は、Git Branchを作るコマンドじゃありません。

分岐するのはConversationのほうで、設計方針や作業の文脈を別方向へ進めるための機能です。

/fork

/fork 現在案とは別に、JWT方式の安全性と実装コストを調査して

いまのConversation全体を引き継いだ、Background Subagentを起動します。

/branch との違いは、「自分が移動するかどうか」です。

/branch では、自分が複製された会話へ移ります。

/fork では、自分はいまの会話を続けて、別のAgentへ横道の仕事を任せます。

たとえば、メインSessionで実装を続けながら、Forkへこんなことを頼めます。

• 別の設計案を検討する
• Performanceを測定する
• Security Riskを調べる
• Documentationを確認する
• 既存実装との比較を行う

Forkの結果は、終わったあとにいまのConversationへ返ってきます。

DesktopではTasks PaneやSubagent PaneからBackground処理を確認できます。

/btw

/btw この認証処理で使っているCookie名は何だった？

いまのSessionが持っているコンテキストを使いながら、メインConversationには内容を残さない「横質問」をします。

向いているのは、こんな質問です。

• さっき決めた変数名を確認したい
• ある関数の役割だけ知りたい
• いまの設計案の前提を確認したい
• 本筋と関係ない、小さな疑問を解消したい
• いまの作業を、別方向へ誘導したくない

Side Chatは、それまでのメインSessionを読める一方で、回答はメインConversationへ戻しません。

Claude Desktopでは、ローカルSessionとSSH Sessionで使えます。

ショートカットからSide Chatを開くこともできますが、コマンドとしては /btw を使います。

/recap

/recap

いまのSessionを、短く要約します。

長時間の処理から戻ってきたときや、複数Sessionを並行しているときに便利です。

これは「どこまで細かく要約するか」を指定するコマンドじゃなくて、「いまどこまで進んでいるか」を手早くつかむための機能です。

もっと詳しい引き継ぎ文がほしいなら、ふつうのPromptでこう頼んだほうがいいですよ。

これまでに決めたこと、変更済みファイル、未完了タスク、次に行うことをまとめて

/rename

/rename auth-cookie-migration

いまのSession名を変更します。

名前を指定しない場合は、Conversationの内容から自動生成されます。

DesktopではSidebarからもSession名を変えられますが、作業中に入力欄からサッと変えたいときに使えます。

複数Sessionを並行させるときは、こういう曖昧な名前は避けましょう。

New session Bug fix Test

かわりに、目的と状態が分かる名前を付けます。

auth-cookie-implementation payment-retry-investigation typescript-5-migration checkout-ci-fix

第3章　計画と完了条件を制御するコマンド

/plan

/plan 認証処理をJWTからSession Cookieへ移行する計画を作って

ClaudeをPlan modeへ移して、ソースコードを編集する前に、調査と計画をやってもらいます。

DesktopにはPermission modeを選ぶUIもありますが、「作業内容と一緒にPlan modeへ入りたい」というときは /plan が便利です。

Planでは、こんな内容を確認させます。

• 現在の実装
• 変更対象のFile
• 呼び出し元
• Test構成
• Migrationの必要性
• Backward Compatibility
• Security Risk
• Rollback方法
• 完了条件

悪い例。

/plan 認証を直して

良い例。

/plan JWT認証をSession Cookie方式へ移行する。 既存Mobile Clientとの互換性、CSRF対策、Logout処理、 Migration手順、追加すべきUnit TestとIntegration Testを含めて

大きな変更のときは、いきなり実装させるより、Planを確認してから実行へ移ったほうが、手戻りを減らせます。

/goal

/goal すべてのテストが成功し、型エラーが0件になり、変更した登録画面を実際に操作して確認するまで続ける

Claudeへ、はっきりした完了条件を設定します。

ふだんのClaudeは、1回の応答の中で「これで十分完了かな」と判断すると、そこで止まります。

Goalを設定すると、各Turnが終わるたびに、条件を達成できたかを別のEvaluatorが確認します。

条件を満たしていなければ、Claudeは次のTurnへ進みます。

Goalは、こんな仕事に向いています。

• Migrationが完了するまで続ける
• すべてのCall Siteを変更する
• 全Testが成功するまで修正する
• 型エラーを0件にする
• Acceptance Criteriaをすべて満たす
• 指定したIssue一覧を処理する

良いGoalは、客観的に確認できます。

悪い例。

/goal 完璧に完成させる

良い例。

/goal 次の条件をすべて満たすまで続ける。Unit TestとIntegration Testが成功する Type CheckとLintが成功する Login、Logout、Session Expirationを実画面で確認する docs/auth.mdを更新する

いまのGoalを確認する場合。

/goal

解除する場合。

/goal clear

Goalは1つのSessionに1つだけ設定できて、達成すると自動で解除されます。

/loop

/loop 5m CIの状態を確認し、失敗していたら原因を調査して

いまのSessionで、一定の間隔ごとに同じ依頼を繰り返します。

間隔を指定しない場合は、Claudeが状況に応じて次回の実行時刻を判断します。

/loop デプロイ状況とApplication Logを監視し、問題があれば調査して

/loop が向く用途は、次のとおり。

• CI完了を待つ
• Deploy完了を確認する
• Logを監視する
• Pull Requestの状態を追う
• 短時間の定期確認を行う
• 外部処理の完了を待つ

注意したいのは、/loop はいまのSessionに紐づいている、という点です。

長期的な定期実行を作る機能ではありません。

Claude DesktopにはRoutines画面から作るScheduled Tasksがあって、そちらはSessionを閉じても管理できます。

使い分けは、こんな感じです。

• 数分から数時間だけ確認したい：/loop
• 毎日、毎週、毎月実行したい：DesktopのRoutines
• PCが停止中も必ず実行したい：Remote Routine

Desktop Scheduled Tasksは、Applicationが開いていて、PCが起動中である必要があります。

いっぽう /loop は、それに加えて、対象のSessionが動いている必要があります。

第4章　並列処理と大規模作業のコマンド

/batch

/batch src/配下を旧Logging APIから新Logging APIへ移行して

大規模な変更を複数の独立作業へ分解して、Background SubagentとGit Worktreeを使って並列に実装する、公式Skillです。

処理は、だいたい次の流れで進みます。

1. Codebaseを調査する
2. 変更範囲を分析する
3. 5〜30個くらいの独立Unitへ分ける
4. Planを提示する
5. 承認後、UnitごとにSubagentを起動する
6. 各Subagentが独立Worktreeで実装する
7. Testを実行する
8. 必要に応じてPull Requestを作成する

Desktopでは、SessionやBackground TaskをSidebarとTasks Paneから確認できます。

Git Repositoryの場合、並列Sessionには自動でWorktreeが割り当てられます。

/batch が向く作業

• 多数のPackageを同じAPIへ移行する
• Deprecated関数をRepository全体から置換する
• 多数の独立ModuleへTestを追加する
• 複数Directoryの設定形式を更新する
• 同じ規則を多数のEndpointへ適用する
• 独立性の高い複数Issueを処理する

/batch が向かない作業

• 同じFileを複数Agentが編集する
• 前工程が終わらないと次へ進めない
• 1つの小さなBugを修正する
• 変更範囲がまだ分かっていない
• 全体設計が固まっていない
• DB Schema変更と全呼び出し元が強く依存している

Agentの数を増やすだけでは、速くなりません。

各Unitが独立していて、Ownershipが重ならないことが大事なんです。

/deep-research

/deep-research 2026年時点のWebAssembly Component Modelの実装状況を調査して

たくさんのSubagentへ調査を分散して、結果を統合するDynamic Workflowです。

ふつうのWeb検索との違いは、調査の工程を並列にできる点にあります。

たとえば、こんなふうに役割を分けられます。

• 公式仕様を調べるAgent
• 主要Runtimeを調べるAgent
• Production事例を調べるAgent
• 反対意見や制約を探すAgent
• 情報の新しさを検証するAgent
• 最終Reportを統合するAgent

Claude DesktopではAgent Teamsは使えませんが、1つのSession内で動くDynamic Workflowsは使えます。

Tasks Paneから、Workflow内部のSubagentと進捗を確認できます。

第5章　実装したApplicationを動かすコマンド

Claude Desktopの強みは、コードを編集するだけじゃなく、Browser Paneを使ってApplicationを実際に確認できることです。

DesktopはDev Serverを起動して、画面を開いて、DOMを確認して、Screenshotを撮って、Buttonを押して、Formへ入力して、問題があれば修正へ戻れます。

その中心になるのが、/run、/verify、/run-skill-generator の3つです。

/run

/run

ProjectのApplicationを起動して、変更した箇所を実際に操作する、公式Skillです。

/run が確認するのは、Test結果だけじゃありません。

• Applicationが起動するか
• 対象の画面へ移動できるか
• ButtonやFormが動くか
• Console Errorがないか
• Network Requestが成功するか
• Server Logに異常がないか
• 見た目が崩れていないか
• User Flowが成立するか

Claude Desktopでは、ApplicationがBrowser Paneに開かれます。

Frontendだけじゃなく、Backend Serverの起動、API Endpointの確認、Logの監視にも使えます。

/verify

/verify

変更が要件を満たしていることを、実行結果を通して証明する、公式Skillです。

/run が「Applicationを起動して操作する」ことに重点を置くのに対して、/verify は「今回の変更が完了条件を満たしたか」を確認します。

たとえば認証機能なら、こんなふうに確認します。

• 正しい認証情報でLoginできる
• 誤ったPasswordが拒否される
• Logout後にProtected Pageへ入れない
• Session Expirationが機能する
• Reload後も期待した状態になる
• Server Errorがない
• Existing Testが壊れていない

AIコーディングでは、Testだけを実行して「完了」にしてしまう失敗が、けっこう多いんですよね。

でも、Testが成功しても、こんな問題は残り得ます。

• Page Routeが間違っている
• FormがSubmitされない
• CSSが崩れている
• Runtime Errorが発生する
• Environment Variableが不足している
• APIとFrontendの形式が一致していない

/verify は、こういう「コード上の成功」と「Userが使える状態」の差を埋めてくれます。

/run-skill-generator

/run-skill-generator

Project固有の起動・検証方法を学習して、/run と /verify が使う専用Skillを生成します。

Projectによって、Applicationの起動方法は違います。

• Monorepo内の特定Directoryから起動する
• FrontendとAPIを同時に起動する
• Database Migrationが必要
• 特定のEnvironment Variableが必要
• Login用のTest Accountが必要
• Docker Composeを先に起動する
• Emulatorが必要
• 特殊なHealth Checkが必要

これを毎Sessionで再発見させると、時間もTokenも消費します。

/run-skill-generator でProject固有の手順をSkill化しておけば、以後のSession、Subagent、Team Memberが、同じ方法で検証できます。

おすすめの順番は、次のとおり。

/run-skill-generator

一度Project用のSkillを作ったら、通常の作業ではこれを使います。

/run

または、

/verify

第6章　コード品質を上げるコマンド

/simplify

/simplify

今回変更したコードを、単純化と再利用の観点から見直して、必要な修正を当てる、公式Skillです。

特定Pathを対象にする場合。

/simplify src/auth

主なReview観点は、次の4つです。

既存Helperの再利用新しいUtilityやHelperを増やす前に、Repository内に既存の実装がないかを確認します。

不要な複雑性過度な抽象化、いらない分岐、使われていないOption、冗長なStateなどを減らします。

効率不要なLoop、重複Query、過剰なData変換などを確認します。

抽象化レイヤー処理が正しいLayerに置かれているかを確認します。

たとえば、Domain LogicがUI Componentへ直接書かれていないか、共通処理が特定Endpointへ閉じ込められていないか、といったところを見ます。

大事なのは、/simplify はCorrectness Bugを探すのが主目的ではない、という点です。

Bugを探すには、次の /code-review を使います。

/code-review

/code-review

いまの変更を、Bugと品質改善の両面からReviewする、公式Skillです。

Reviewの深さを指定できます。

/code-review low

/code-review high

/code-review xhigh

修正まで当てる場合。

/code-review high --fix

GitHub Pull RequestへInline Commentを投稿する場合。

/code-review high --comment 123

Cloud上のDeep Multi-Agent Reviewを使う場合。

/code-review ultra 123

主な確認対象は、次のとおり。

• 正しさ
• Edge Case
• Stateの不整合
• Error Handling
• 既存機能への影響
• API Contract
• Test不足
• Helperの重複
• 不要な複雑性
• Performance上の問題

/simplify と /code-review は、役割が違います。

• /simplify：Cleanupと設計の整理
• /code-review：Bugと改善点のReview

おすすめの順番は、次のとおり。

/simplify /code-review high

先にコードを整理してからBug Reviewをやると、Review対象が読みやすくなります。

/security-review

/security-review

いまの変更を、Security観点から分析します。

主な確認対象は、次のとおり。

• Authentication
• Authorization
• Input Validation
• SQL Injection
• Command Injection
• Cross-Site Scripting
• CSRF
• SSRF
• Path Traversal
• Secret Exposure
• Sensitive Data Logging
• Information Disclosure

/code-review でも一部のSecurity問題は見つかりますが、Securityに関わる変更では、専用のReviewを追加します。

たとえば、こんな変更では、実行する価値が高いです。

• Login
• Payment
• File Upload
• Admin機能
• Permission
• External API連携
• Database Query
• OAuth
• Token処理
• Personal Data

Security Reviewだけで、安全性を保証できるわけではありません。

専門家によるReview、Dependency Scan、Static Analysis、Penetration Testなどと組み合わせてください。

/review

/review 123

GitHub Pull Requestを、高速なSingle-pass方式でReviewします。

PR番号の後ろに、追加の指示を書けます。

/review 123 認証と権限昇格の問題だけ重点的に確認して

/review と /code-review の違いは、深さと用途です。

/review

• 高速
• Single-pass
• 読み取り専用
• Pull Request向け
• 手早い一次確認

/code-review

• Effortを選べる
• Current Diffにも使える
• 修正を適用できる
• Comment投稿に対応する
• Multi-Agent Reviewがある
• Ultra Cloud Reviewがある

重要度の低いPRを手早く見るなら /review、重要な変更や深いReviewには /code-review を使います。

第7章　Project初期設定と専門作業のコマンド

/init

/init

いまのProjectを調査して、CLAUDE.mdの初期案を生成します。

初期案には、こんな内容が含まれます。

• Project概要
• 使用技術
• Build方法
• Test方法
• Directory構造
• 開発時の注意点
• Coding Pattern

生成されたCLAUDE.mdは、完成品じゃありません。

いらない一般論を削って、Project固有の事実へ絞る必要があります。

良いCLAUDE.mdは、Claudeへ毎回必要な情報を、短く渡します。

悪いCLAUDE.mdは、長い説明、手順、禁止事項、参考資料を一枚に詰め込んで、コンテキストを圧迫します。

繰り返しの手順はSkillsへ、特定Pathだけの規則はRulesへ移しましょう。

/claude-api

/claude-api

Anthropic API、SDK、Tool Use、Streaming、Batch、Structured Outputなどの公式Referenceを読み込むSkillです。

ProjectがAnthropic SDKをImportしている場合は、必要に応じて自動で有効になることもあります。

Model Migrationを行う場合。

/claude-api migrate

Managed Agentsの導入支援。

/claude-api managed-agents-onboard

AI APIは変化が速くて、古いModel ID、古いParameter、廃止予定のSDK形式を、うっかり使ってしまいやすいんです。

Anthropic APIに関するコードを書くときは、一般的なWeb知識だけじゃなく、公式Skillを使う価値が高いですよ。

/dataviz

/dataviz 月次売上、解約率、継続率を比較するDashboardを設計して

Data Visualizationを設計する、公式Skillです。

ただGraphを出すだけじゃなく、こんな内容を扱います。

• Chart Typeの選択
• Axis
• Scale
• 色の意味
• Colorblind Accessibility
• Contrast
• Annotation
• Interaction
• Dashboard Layout
• 情報の優先順位

データに合わないChartを使うと、正しい数字でも誤解を生みます。

/dataviz は、「表示できるGraph」じゃなく「意思決定に使えるVisualization」を作るためのSkillです。

/design-sync

/design-sync packages/ui

Repository内のReact Design Systemを、Claude Designへ同期する公式Skillです。

対象には、こんなものが含まれます。

• Components
• Variants
• Design Tokens
• Typography
• Color
• Spacing

対応環境と、Claude Designへの認証が必要になります。

使えない環境では、「/」メニューに表示されないことがあります。

第8章　Claude Code自体を診断するコマンド

/doctor

/doctor

Claude CodeのInstallation、Settings、Context構成を診断して、必要に応じて修正する、Setup Checkup Skillです。

主な確認対象は、次のとおり。

• 重複Installation
• PATH問題
• 壊れたSettings File
• 未使用Skills
• 未使用Plugins
• 未使用MCP
• Context Cost
• CLAUDE.mdの重複
• 常時読み込む必要のないInstruction
• 遅いHooks
• 頻繁に拒否されるRead-only Command
• 新しいClaude Code Version

/doctor は、いきなりSettingsを変えたりしません。

まず問題と修正候補を報告して、あなたの確認のあとで変更します。

こんな症状があるときに、有効です。

• 最近Claude Codeが重くなった
• Contextがすぐ満杯になる
• Permission確認が多すぎる
• Pluginを大量に入れている
• MCP接続が増えた
• CLAUDE.mdが長くなった
• Hookの実行に時間がかかる
• 設定を何度も変えて、構成が分からなくなった

v2.1.205より前は読み取り専用の診断画面でしたが、いまはBundled Skillとして、改善提案から修正まで行えます。

/debug

/debug MCP Serverへの接続が毎回切断される

Claude CodeのRuntime Problemを診断する、公式Skillです。

対象になる問題は、次のとおり。

• MCP接続
• Hook
• Plugin
• Session
• Permission
• Tool実行
• Background Task
• Claude CodeのDebug Log

Application CodeのBugを調べる、一般的な「デバッグコマンド」ではありません。

たとえば、この2つは使い分けます。

ApplicationのLogin Bug。

Login時に500 Errorになる原因を調査して

Claude CodeのMCP Problem。

/debug GitHub ConnectorがSession開始時に接続されない

/fewer-permission-prompts

/fewer-permission-prompts

過去のSessionを調べて、頻繁に承認しているRead-only処理を抽出して、Permission Ruleの候補を作る公式Skillです。

対象になり得るのは、こんな処理です。

• Git状態の確認
• Test一覧の取得
• Build設定の読取
• Read-only MCP Tool
• 頻繁に使う、安全な調査Command

目的は、なんでも無条件に許可することじゃありません。

繰り返し承認している安全な操作だけを抽出して、Project Settingsへ優先順位付きのAllow候補を追加します。

提案されたRuleは、必ず内容を確認してくださいね。

/insights

/insights

過去のClaude Code Sessionを分析して、自分の利用傾向をReportにします。

分析される可能性があるのは、こんな内容です。

• よく扱うProject領域
• 繰り返し発生する作業
• Permissionによる摩擦
• よく使うSkills
• Subagentの使い方
• 失敗しやすいWorkflow
• 作業の分け方

ただの利用量じゃなく、「Claude Codeをどう使っているか」を振り返るための機能です。

/team-onboarding

/team-onboarding

過去30日くらいの利用履歴から、Team Member向けのClaude Code導入Guideを生成します。

Guideには、こんな内容が反映されます。

• よく扱うProject
• 推奨Workflow
• 使っているSkills
• MCP連携
• よく使う作業方法
• Project固有の注意点

対応Subscriptionなら、Team Memberが直接開ける共有Linkも生成されます。

新しいMemberへ、一から使い方を説明する負担を減らせます。

第9章　Desktopで設定を直接変更するコマンド

Claude Desktopでは、モデル、Effort、Permission mode、Plugin、Connectorなどは、GUI操作が基本です。

いっぽう、Settings Keyと値が分かっている場合は、/config へ直接「key=value」を渡せます。

/config theme=dark

ここで大事なのは、引数なしの /config は、DesktopのCodeタブでは使えない、という点です。

/config

こうやってターミナル用のInteractive Panelを開こうとすると、Desktopでは「この環境では利用できない」と表示されます。

直接値を渡す形式だけが使えます。

/config autoMemoryEnabled=false

ただ、設定名と値を正確に把握していないなら、DesktopのSettings画面を使ったほうが安全ですよ。

第10章　Custom SkillsとPlugin Skills

Claude Desktopのコマンド一覧は、Built-in Commandsだけじゃありません。

Project、ユーザー環境、Pluginから追加されたSkillsも、同じ「/」メニューに表示されます。

Project Skill

Project Repositoryの中に置かれたSkillです。

たとえば、こんなコマンドをチームで共有できます。

/deploy-staging /release-check /create-migration /review-api /test-checkout

Project SkillはRepositoryと一緒に管理できるので、チーム全員が同じ手順を使えます。

User Skill

個人の全Projectで使うSkillです。

向いているのは、こんなもの。

• 自分のReview Style
• 個人的なDocumentation手順
• よく使う調査方法
• Output形式
• Coding Preference

Plugin Skill

導入済みPluginから追加されるSkillです。

入力欄の横の「＋」からPluginsを開いて、Pluginの追加、無効化、削除ができます。

注意したいのは、Plugin Skillsが使えるのは、主にLocal SessionとSSH Sessionだ、という点です。

Claude DesktopのCloud Sessionでは、Pluginは使えません。

だからLocalで表示されていたPlugin Skillが、Remote環境では表示されないことがあります。

Skillの呼び出し例

/release-check version 3.4.0のRelease準備を確認して

/security-review-api POST /api/paymentsの変更を確認して

複数Skillを組み合わせる場合。

/api-rules /security-rules /test-policy 招待APIを実装して

Skillの本文は、使うときまで読み込まれません。

だから、長い手順をCLAUDE.mdへ常時入れておくより、コンテキスト効率がいいんです。

第11章　DesktopではコマンドではなくGUIを使うもの

Claude Desktopは同じClaude Code Engineを使っていますが、Terminal向けのInteractive Panelは、Codeタブでは使えません。

たとえば、こんなコマンドは、この記事の対象から外しています。

/permissions

/config

引数なしの /config はInteractive Panelを開くので、Desktopでは使えません。

さっき説明したとおり、「key=value」を直接渡す形式だけが、例外的に使えます。

それと、次の操作は、DesktopではGUIを使うのが基本です。

• モデル変更：入力欄の横のModel Picker
• Effort変更：Effort Menu
• Permission mode：Send Button横のMode Selector
• Plugin管理：「＋」ボタン、またはCustomize画面
• Connector管理：「＋」ボタン、またはSettings
• Diff確認：Diff Pane
• Background Task確認：Tasks Pane
• Session切り替え：Sidebar
• Scheduled Tasks：Routines画面
• Context使用量：Model Picker横のUsage Ring
• Transcript表示切替：View Mode Menu

Desktopで使えるコマンドだけを確認したいなら、入力欄で「/」を入力して表示された一覧を基準にしてください。

公式Command ReferenceにはTerminal専用コマンドも混ざっているので、その一覧をそのままDesktop版の記事へ転用してはいけません。

第12章　実務で使えるコマンドワークフロー

新機能を安全に実装する

最初に設計します。

/plan ユーザー招待機能を実装する。 権限、期限切れ、重複招待、再送、監査Log、 Unit TestとIntegration Testを含めて計画して

計画を確認して、実装を依頼します。

実装が終わったら、整理します。

/simplify

BugをReviewします。

/code-review high

Securityを確認します。

/security-review

最後に、Applicationを動かします。

/verify

この流れは、AIが書いたコードをそのまま採用するんじゃなく、設計、整理、Review、実証という段階に分けています。

複雑なBugを修正する

最初に完了条件を設定します。

/goal Login失敗を再現し、原因を修正し、関連するRegression Testを追加し、実画面で正常Loginと異常Loginを確認するまで続ける

必要なら、横で別の仮説を調査させます。

/fork Session Store側に原因がないか独立して調査して

実装後に確認します。

/code-review high

/verify

大規模Migrationを行う

最初に影響範囲を整理します。

/plan 旧Logging APIから新APIへのMigrationを計画して。 変更対象、依存関係、互換性、Test方法、Task分割を含めて

独立Unitへ分割できると分かったら、並列化します。

/batch 全Packageを新Logging APIへ移行して

統合したあとにReviewします。

/code-review xhigh

最後に、全体を検証します。

/verify

PRを手早く確認する

/review 123

問題の可能性が高いなら、もっと深く調べます。

/code-review high 123

Securityに関わる変更なら、追加します。

/security-review

Applicationの起動方法が複雑なProject

最初に専用Skillを作ります。

/run-skill-generator

以後は、これを使います。

/run

または、

/verify

毎回、Environment、起動順、Test Account、URLを説明する必要がなくなります。

短時間だけ外部処理を監視する

/loop 5m Deployの状態を確認し、失敗していたらLogを調査して

終了条件がはっきりしているなら、Goalを組み合わせます。

/goal Deployが成功し、Health Checkが200を返し、主要画面が表示されるまで続ける

本筋を壊さず疑問を確認する

/btw このMigrationで旧Clientとの互換期間は何日だった？

Side Chatで確認したら、メインの作業をそのまま続けられます。

第13章　よくある使い分けの間違い

/clear と /compact を混同する

同じ作業を続けるなら /compact。

別の仕事へ移るなら /clear。

無関係な作業を1つのSessionへ追加し続けると、Contextが増えるだけじゃなく、過去の前提に引っ張られやすくなります。

/branch と /fork を混同する

自分が別案へ移るなら /branch。

いまの仕事を続けながら、別Agentへ別案を調べさせるなら /fork。

/loop を定期Taskとして使う

/loop は、いまのSessionが動いている間の、短期監視です。

毎日や毎週の実行には、DesktopのRoutinesを使います。

/simplify だけでBug Reviewを終える

/simplify は、Cleanupが中心です。

Correctness Bugには /code-review を使います。

/run しただけで完了とする

Applicationが起動しただけでは、要件を満たしたとは限りません。

User FlowとAcceptance Criteriaまで確認するなら、/verify を使います。

/batch で同じFileを複数Agentへ渡す

複数Agentが同じFileを編集すると、並列化による速度アップより、統合Costのほうが大きくなります。

Directory、Module、Package、Endpointなど、所有範囲が重ならない単位で分けます。

Goalを抽象的に書く

/goal 完璧にして

これだと、完了判定が主観的になってしまいます。

Test、画面、Performance、Documentationなど、観測できる条件を書きましょう。

第14章　実務で最初に覚えるべきコマンド

Claude DesktopのCodeタブを使い始めたばかりなら、まずはこの辺を覚えるといいですよ。

長い作業の前。

/plan

コンテキストが長くなった。

/compact

別の仕事へ移る。

/clear

横道の質問をする。

/btw

別Agentへ独立調査を任せる。

/fork

完了条件を固定する。

/goal

実装を整理する。

/simplify

Bugを確認する。

/code-review

Securityを確認する。

/security-review

実際に動くか確認する。

/verify

Project固有の起動方法を覚えさせる。

/run-skill-generator

Claude Codeの設定を診断する。

/doctor

この十数個を使い分けるだけでも、Claude Desktopを、ただのコード生成画面じゃなく、計画・実装・Review・検証を回す「開発環境」として使えるようになります。

まとめ――Desktopのコマンドは「GUIの代替」じゃない

Claude Desktopでは、モデル選択、Permission、Diff、Plugin、Connector、Task、SessionなどをGUIから操作できます。

だから、Desktop版のコマンド記事に、ターミナル版の起動方法や管理コマンドを大量に載せる必要はないんです。

DesktopのCodeタブで大事なのは、次のような「作業そのもの」を制御するコマンドです。

会話を新しくする → /clear 同じ会話を圧縮する → /compact Contextを確認する → /context 別方向を自分で試す → /branch 別方向をAgentへ任せる → /fork 本筋へ残さず質問する → /btw 事前に設計する → /plan 条件達成まで続ける → /goal 短時間の監視を行う → /loop 大規模変更を並列化する → /batch 大規模調査を分散する → /deep-research Applicationを起動する → /run 変更を実証する → /verify コードを整理する → /simplify BugをReviewする → /code-review SecurityをReviewする → /security-review PRを高速確認する → /review Claude Codeの構成を診断する → /doctor Runtime Problemを診断する → /debug

Claude Desktopのコマンドは、Terminal操作を覚えるためのものじゃありません。

Claudeへ、いつ計画させて、いつ並列化して、いつ止めずに続けさせて、どの証拠をもって完了とするか。

それを指示するためのインターフェースなんですよ。