workspace

workspaceスキルの概要

workspaceスキルで何ができるか

workspace スキルは、Claude Code にモノレポや複数リポジトリ全体の動的な把握力を与え、各フォルダを切り離された孤立した領域として扱うのではなく、トポロジー、共有型、API契約、プロジェクト間依存関係を踏まえて判断できるようにします。フロントエンド、バックエンド、packages、共有サービスをまたいで変更をそろえたいときに、差分のズレを減らし、実装の重複を避けるうえで特に有効です。

どんな人がインストールすべきか

作業が日常的に複数のコードベースにまたがるなら、あるいは1つのリポジトリ内に複数のアプリがあり、それらが契約や依存関係を共有しているなら、workspace を導入する価値があります。ワークフロー自動化、プラットフォームエンジニアリング、そして1か所の変更が他の領域にどう波及するかを Claude Code に理解させたいチームに向いています。

実務で重要な理由

本質的な価値は、漠然とした「コンテキスト増量」ではありません。ズレを減らせることです。workspace ガイドは、Claude が既存の実装、契約の置き場所、変更時に更新すべき下流コードを推測しやすくするために設計されています。そのため、単なるクロスリポジトリ作業向けの汎用プロンプトよりも、判断材料としての価値が高いのです。

workspaceスキルの使い方

インストールして有効化する

まずはリポジトリの Claude skill install の流れでスキルを導入し、そのうえで Claude が関連リポジトリや packages を निरीできる workspace 内で作業します。workspace install は、エージェントが実際のプロジェクト構造を見られる場合にだけ意味があります。したがって、Claude Code を動かす予定の実環境に、同じようにインストールしてください。

適切な入力から始める

良い workspace usage プロンプトには、何が変わったのか、正本はどこにあるのか、何を互換維持する必要があるのかが書かれています。たとえば「services/payments の checkout API を更新し、apps/web と packages/api-types の共有型とクライアント呼び出しを確認してほしい」のように指示します。これは「バグを直して」よりずっと有効です。影響範囲をスキル側が具体的にたどれるからです。

まず確認すべきファイル

最初に SKILL.md を読み、そのあと README.md、AGENTS.md、metadata.json を確認します。さらに存在するなら、workspace 固有の rules/、resources/、references/、scripts/ フォルダも見てください。このリポジトリでは支援用の補助ファイルがないため、SKILL.md が主な情報源です。実際に役立つ挙動のほとんどは、このスキル本文に書かれています。

ワークフローに組み込んで使う

workspace for Workflow Automation の実践的な流れは、トポロジーを把握し、共有契約を特定し、それらを定義しているファイルを見つけ、依存するアプリやリポジトリを更新して破綻がないか確認する、というものです。最良の結果が出るのは、編集のあとではなく、前に影響範囲の追跡を Claude に依頼したときです。

workspaceスキル FAQ

workspace はモノレポ専用ですか？

いいえ。workspace スキルは、別々のリポジトリでも1つのシステムのように連動している場合に役立ちます。特に、API、共有型、リリース時期が密接に結びついているケースに向いています。

通常のプロンプトと何が違いますか？

通常のプロンプトでも変更指示はできますが、workspace スキルは、単発の指示では見落としがちな関係性、たとえば隠れた依存関係や契約の所有元を Claude に確認させやすくします。そのため、孤立した単一ファイルの作業よりも、リポジトリをまたぐ編集で効果を発揮します。

初心者でも使えますか？

はい。アプリの境界と変更の目的を説明できれば十分です。リポジトリを深く知っている必要はありませんが、どの repo、package、service から始めるべきかはスキルに伝える必要があります。

使わないほうがよいのはどんなときですか？

複数リポジトリの文脈が関係しない、小さく完結した修正では使わなくて構いません。1つのファイルや1つの package の外で何も壊れない作業なら、workspace スキルはメリットよりも手間のほうが大きくなります。

workspaceスキルを改善するには

正本マップを与える

最も強い入力は、各契約の責任システムを明示します。たとえば「OpenAPI schema は services/api/openapi.yaml、生成された client types は packages/sdk、UI の呼び出しは apps/admin にある」といった形です。これにより、workspace スキルが正本の所在を推測せずに済みます。

互換性制約を最初に伝える

変更で挙動、バージョン管理された API、共有型を維持する必要があるなら、最初に明言してください。workspace スキルは、壊してはいけないもの、再生成してよいもの、手で編集すべきものを指定したほうが、より良い結果を出します。

編集の前に影響分析を依頼する

workspace スキルを使うときは、コード変更の前に簡単な依存関係チェックを求めてください。たとえば「影響を受けそうな repos、packages、entry points を挙げたうえで、最も安全な編集順を提案してほしい」といった指示です。これにより、Claude が実装にすぐ飛びつくのではなく、blast radius を考えて判断するようになるため、出力品質が上がります。

部分的な結果から段階的に詰める

最初の結果が広すぎる場合は、package、契約、repo 境界で絞り込んで再実行します。最良の workspace guide ワークフローは、1回目でシステム全体を地図化し、2回目で得られた文脈を使って範囲を絞った変更を実行するやり方です。