単一リポジトリへ専用の開発手順を追加したい個人開発者向けです。複数案件でSkillsを再利用したいヘビーユーザーにも適しています。さらに、チームのSkillバージョンと変更責任を統一したいプラットフォーム担当者にも役立ちます。

置き場所を決める前に、Skillの内容を次の三点で分類します。

• 参照範囲： 特定リポジトリだけか、複数案件で共通か。
• 変更責任： 個人が自由に編集するか、レビューを経て配布するか。
• 信頼境界： ソースコードだけを読むか、シェル、デプロイ、秘密情報周辺へ触れるか。

プロジェクト専用のビルド手順やテスト制約は、使用するコードの近くに置きます。リポジトリと同じ変更履歴でレビューでき、ブランチの切り替えと同時にSkillの内容も切り替えられるからです。

一方、複数案件で使う文章整形、一般的なコードレビュー、ログの要約といった能力はユーザー単位が候補です。ただし、特定の社内コマンドや固定パスを含むなら、見た目が汎用的でも全体配置には向きません。

プロジェクト専用Skillには、ビルドコマンド、テスト順序、コーディング規約、変更禁止領域などが含まれます。これらはアプリケーションの版と結び付いているため、ユーザー単位へ置くと別案件へ誤って持ち込む可能性があります。

DeepSeek Harness自体も、リポジトリを中心に開発手順、設定、実行方法を管理しています。導入時は公式の開発ガイドで、使用中の版における環境変数、認証情報、作業ディレクトリの扱いを確認してください。

リポジトリへ含める方式には、次の利点があります。

• Pull RequestでSkill本文をレビューできる。
• ブランチごとに異なる手順を保持できる。
• 新しいMacへ移っても、リポジトリの取得で再現しやすい。
• チームメンバー間で「どの手順を使ったか」を説明しやすい。

ただし、Skillは単なるメモではありません。Agentの判断やツール利用へ影響する指示資産です。外部から取得した内容を無検査でコミットせず、実行コマンド、ファイル削除、外部通信、権限変更の有無を確認してください。

注意： APIキー、SSH秘密鍵、アクセストークン、社内URLの認証情報をSKILL.mdへ書かないでください。Skillを共有するリポジトリと秘密情報の保管場所は分離します。公式リポジトリの認証情報と環境変数に関する開発資料にも、実キーをコミットしない運用が示されています。

ユーザー単位のSkillは、案件をまたいでも意味が変わらないものに限定します。たとえば、コミットメッセージの形式、一般的なテスト結果の報告、ログを個人用の形式へ整える手順などです。

便利さの代わりに、三つのコストが発生します。

1. 誤トリガー： 関係のないプロジェクトでも説明や指示が候補に出ます。
2. バージョン漂流： いつ変更されたか分からないまま、全案件の動作が変わります。
3. 影響の拡散： 一つの修正が、検証していない別プロジェクトへ及びます。

環境変数のDSH_HOMEを利用する場合も、そこへ何でも集約しないことが重要です。ユーザー単位へ置くSkillには、現在の作業ディレクトリを前提にした相対パスや、特定チームだけのデプロイ手順を入れないでください。

小規模チームでは、プロジェクト単位＋読み取り専用の共有ソースが現実的です。共有ソースを正本にし、各リポジトリには承認済みの版をコピー、同期、または固定参照します。

ここで大切なのは、共有元を全員が直接編集できる状態にしないことです。変更はレビュー対象にし、最低限次の情報を残します。

• Skill名とバージョン。
• 変更日と変更理由。
• 対象プロジェクト。
• 互換性を確認したHarnessの版。
• 問題発生時に戻す版。
• 変更を承認した担当者。

「共有Skillを直せば全員へ即時反映」という運用は、検証前の変更が一斉に広がる点で危険です。標準版を読み取り専用で配布し、実験版は別名または別ディレクトリへ分ける方が、問題の切り分けが容易です。

クラウドMacやCI用の実行環境では、個人のホームディレクトリに依存しないでください。実行プールごとにSkill一覧を定義し、マシンイメージ、初期化処理、または環境引き渡し資産へ含めます。

公式のWeb UI利用ガイドでは、起動したプロセスの作業ディレクトリやワークスペース選択が説明されています。Skillの配置を検討するときも、ログインしたアカウントのホームだけでなく、Harnessを起動するディレクトリと選択したワークスペースを分けて記録してください。

検収は、単にファイルが存在するかを見るだけでは不十分です。次の順番で確認します。

第一歩：正本と配布版を分ける

共有リポジトリを正本にします。実行環境へ入れるものは、コミットIDまたはタグで固定した配布版にします。

第二歩：検出対象を記録する

プロジェクトルート、ユーザールート、共有Agentルート、カスタムディレクトリのどこを使うかを環境仕様書へ記載します。公式設定の候補範囲と、実際のバージョンでの表示結果を分けて記録してください。

第三歩：ファイル変更を確認する

Skillの追加や更新を行い、現在のセッションで一覧が変わるかを確認します。変更が表示されない場合は、ファイル監視の設定、再走査のタイミング、セッション再起動の要否を調べます。

第四歩：再起動から復旧させる

Macを再起動、または実行プロセスを再生成します。その後、同じプロジェクトで同じSkillが発見されるかを確認します。個人のキャッシュや一時ディレクトリだけに存在する場合は不合格です。

第五歩：実行プール間で比較する

開発用、検証用、本番相当の各プールでSkill一覧を取得します。差分があれば、意図した差なのか、配布漏れなのかを判定します。

第六歩：安全性を確認する

所有者、書き込み権限、シンボリックリンクの参照先を確認します。信頼境界をまたぐリンクは、リンク先の所有者と変更履歴まで検査してください。

経験則： シンボリックリンクは「同期が簡単」ですが、リンク先の差し替えを見落とすと、レビューしたファイルと実際に読まれるファイルが一致しないことがあります。チーム標準では、まず固定コピーで検証し、リンクは明確な管理下に限定します。

全体配置の最大の問題は、個人の変更が別の案件へ届くことです。特に、ファイル操作やシェル実行を含むSkillでは、内容の更新権限そのものがリスクになります。

次の条件に一つでも当てはまるなら、書き込み可能なユーザー単位の共有を避けます。

• 複数の顧客案件を同じMacで扱う。
• 本番環境へ接続できる。
• Skillがシェル、Git、デプロイツールを呼び出す。
• 監査で変更者と変更時刻を示す必要がある。
• チームメンバーごとに権限が異なる。

この場合は、プロジェクト内の固定版と、管理者だけが更新できる共有ソースを組み合わせます。SKILL.mdの本文だけでなく、同じディレクトリにある補助スクリプトや参照ファイルも一つの配布単位として扱ってください。

公式のエージェント向け指示ファイルも、リポジトリ内の開発規約を管理するための資産です。Skillだけを特別扱いせず、Agentへ影響する指示ファイル全体について、所有者、レビュー経路、変更権限を定義すると運用が安定します。

以下の条件分岐で決めると、配置を感覚で選ばずに済みます。

• そのSkillが一つのリポジトリのパス、テスト、ビルド規約を参照するなら、プロジェクト単位を選びます。
• 複数案件で同じ入力と同じ権限だけを使うなら、ユーザー単位を選びます。
• チームで内容を統一し、更新履歴と復旧版が必要なら、共有ソース＋プロジェクト単位へ戻します。
• 実行環境が使い捨て、または自動再生成されるなら、イメージか初期化処理へ含めます。
• 書き込み権限や信頼境界を説明できないなら、全体共有を選ばず、プロジェクト単位へ戻します。
• オフラインで納品する必要があるなら、Skill本体と補助ファイルを固定版として同梱します。

DeepSeek Harness Skillsはどの場所に置くと管理しやすいですか？

リポジトリ固有のビルド規約、テスト手順、ディレクトリ構成を参照するSkillはプロジェクト内に置きます。複数の案件で使う一般的なレビュー手順や文章整形だけをユーザー単位へ分離してください。チームで配布する場合は、承認済みバージョンを共有ソースで管理し、各プロジェクトへ固定版として届ける方法が安全です。

複数のプロジェクトで同じDeepSeek Harness Skillを使えますか？

共用は可能ですが、同じファイルを複数プロジェクトから直接書き換える運用は避けてください。パス、秘密情報、利用するコマンドが共通しているSkillだけを共有対象にし、プロジェクト固有の条件は各リポジトリ側へ残します。更新時はバージョン、変更理由、適用範囲、戻し方を記録しておくと影響を追跡できます。

DeepSeek Harnessが追加したSkillを認識しないときは何を確認しますか？

最初にディレクトリ名、SKILL.mdの位置、読み取り権限、設定されたSkill Providerを確認します。新規ファイルを実行中のセッション途中で追加した場合、一覧が再走査されないこともあります。新しいセッションを開始し、公式設定とツール実装で現在の検出条件を確認したうえで、同じテストタスクを再実行してください。

クラウドMacへチームのSkillsを同期するときの注意点は何ですか？

個人のホームディレクトリへ手作業でコピーするのではなく、初期化処理、イメージ、または環境引き渡し資産として配布します。Skillのバージョン、配置先、所有者、読み取り権限を記録し、再起動後にも同じ一覧が表示されるか確認してください。APIキーやSSH鍵はSkill本文へ入れず、別の秘密情報管理経路で渡します。

配置を決めたら、Skillを呼び出す同一のテストタスクを用意します。プロジェクトAで発見されること、必要な場面だけで読み込まれること、プロジェクトBの作業へ内容が漏れないことを確認します。

検収項目は次の通りです。

• Skill名と説明が一覧へ出る。
• SKILL.mdと補助ファイルを読み取れる。
• 指定した条件でだけ適用される。
• 別プロジェクトでは専用指示が発動しない。
• ファイル更新後の再走査条件が分かっている。
• プロセス再起動後も同じ版を発見できる。
• シンボリックリンクの参照先を説明できる。
• 書き込み権限と変更履歴を追跡できる。

DeepSeek Harness Skillsを個人の全体領域へ集める方式は、短期的には手軽です。しかし、プロジェクトごとの規約差、版の漂流、権限の違いを吸収できません。特にチーム運用では、手作業コピーや可変の共有フォルダが原因で、同じ名前のSkillが違う内容になる問題が起きます。

そのため、単一案件ならプロジェクト単位、個人の純粋な汎用作業ならユーザー単位、チームやリモート実行環境なら固定版の二層構成を選ぶのが妥当です。現在のMac構成でSkillの配置、版、再起動後の復旧記録まで揃えにくい場合は、KVMNODEのMac環境を比較対象に入れ、Mac miniの構成選びと同じ検収表で環境を確認してください。リモートMacを使う場合も、単に接続できるかではなく、Skillsの配布資産と復旧結果まで引き渡し条件へ含めると、個人依存の運用から抜け出せます。