菜单
local feed を利用側 repository に接続し、参照追加から restore/build まで通す。作成した nupkg を対象 repository で確認したいとき。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。 接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずに サーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。
調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。 実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。
こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。
Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ 分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。
新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。
| name | consume-local-nuget |
| description | local feed を利用側 repository に接続し、参照追加から restore/build まで通す。作成した nupkg を対象 repository で確認したいとき。 |
local feed を利用側 repository に接続し、参照追加から restore/build まで通すための sub-skill です。pack 側と分ける理由は、こちらの失敗点が NuGet.Config、HintPath、packages.config、PackageReference の整合に集中するからです。trusted repository を前提にし、未確認の repo は sandbox / isolated environment でのみ扱い、restore/build 前に *.csproj、.sln*、Directory.Build.*、*.props、*.targets、NuGet.Config、packages.config を確認します。package の追加・更新は command-first で進め、手編集は command で表現できない例外に限ります。
ゴール駆動で使うため、最初に達成したいゴール、成功条件、確認手段を短く固定します。
このスキルは次のようなときに使います:
packages.config と PackageReference の restore 方法を切り分けたいときまず local feed の場所を決めて NuGet.Config に登録します。repo-local を既定にし、user profile 配下を使う場合は一時的な opt-in として扱います。packages.config の project なら Visual Studio / Package Manager Console の Install-Package で追加し、nuget.exe restore で復元します。CLI-only の legacy repo では、追加は direct edit の例外として扱い、packages.config と HintPath の同期を必要最小限にします。SDK-style の project なら dotnet add package -> dotnet restore -> dotnet build が中心になるため、ここを分けると後続の手順がぶれません。
パッケージを追加したら、利用側 repository で restore を通し、次に build を実行します。失敗しやすいのは、feed 登録漏れ、package version の不一致、HintPath の古さ、足りない transitive dependency の 4 つです。
packages.config では HintPath や .props / .targets / NuGet.Config の同期、またはコマンド後の不整合補正が必要なときだけ direct edit を許可します。| 消費側の形 | まず使うコマンド |
|---|---|
packages.config | Visual Studio / Package Manager Console の Install-Package -> nuget.exe restore |
SDK-style / PackageReference | dotnet restore -> dotnet build |
../pack-local-nuget/ — 使う package を作る側の流れに戻る