GitHub Copilotのアップデートをカスタマイズする

GitHub Copilotモダン化は拡張可能です。 エージェントは、チームのアップグレード パターンをエンコードし、アップグレード中にコーディング標準を適用し、新しいアップグレード ワークフローを定義するための複数のカスタマイズ ポイントを提供します。

カスタマイズ ポイントの概要

カスタマイズ ポイント	Scope	永続性	努力
チャットの手順	セッションごとまたはアップグレードごと	セッションまたは scenario-instructions.md に保存されました	最小限
シナリオ成果物	アップグレードごと	アップグレードの期間	低
カスタム スキル	チームまたは個人	永続的 (リポジトリまたはユーザー プロファイルにチェックイン)	中程度
カスタム シナリオ	チームまたは個人	パーマネント	高

ヒント

チャットの指示とシナリオの成果物の編集から始めます。 アップグレードの間で同じ手順を繰り返している場合は、カスタム スキルに移動します。

チャットを使用してカスタマイズする

自然な会話を通じてエージェントの動作をリアルタイムでカスタマイズします。 エージェントは、命令を直ちに適用するか、後で参照できるように scenario-instructions.md に保持します。

あなたは言う	何が起きるか
"今後は、各タスクの後に常にコミットします"	実行設定として scenario-instructions.md に保存
"このタスクのテスト検証をスキップする"	現在のタスクにのみすぐに適用されます
"このアップグレードにボトムアップ戦略を使用する"	計画フェーズ戦略に影響を与える
"ロギング プロジェクトに触らないでください"	環境設定に追加されました。エージェントは、そのプロジェクトを除外します
"常にファイル スコープの名前空間を使用する"	コーディング標準設定として保存
"レビューの各タスクの後に一時停止する"	実行スタイルの基本設定として保存

ヒント

アップグレード全体にわたって命令を保持するには、永続的な優先設定として" From now on, always..." または "For all tasks in this upgrade..." (このアップグレードのすべてのタスクについて) と表現します。 エージェントは命令を scenario-instructions.mdに書き込みます。

シナリオ成果物を編集する

エージェントは、アップグレードを実行すると、 .github/upgrades/{scenarioId}/にワークスペースを作成します。 アップグレード フォルダーには、エージェントの動作を直接制御する編集可能な成果物が含まれています。

シナリオ指示.md

scenario-instructions.md ファイルは、アップグレード用のエージェントの永続メモリです。 エージェントは常にこのファイルをコンテキストに読み込むので、ここで記述するものはすべて、エージェントが行うすべての決定に直接影響します。

エージェントをガイドするために、次のようなセクションを追加します。

## User Preferences

### Technical Preferences
- Always prefer explicit type declarations over `var`
- Use `ILogger<T>` instead of `ILoggerFactory` for dependency injection
- Target .NET 10 for all projects
- Keep Newtonsoft.Json in the shared library (don't migrate to System.Text.Json)

### Execution Style
- **Pace**: Methodical
- **Pause Points**: After assessment, after each task group

### Custom Instructions

#### 02-common-lib
- Skip the database migration for now — it has external dependencies
- Use the connection string from `appsettings.Production.json` for testing

#### 03-data-layer
- Keep existing repository interfaces during migration
- Preserve all Entity Framework conventions

## Key Decisions Log
- 2025-01-15: Keep Newtonsoft.Json in SharedLib — third-party SDK requires it
- 2025-01-16: Skip database project — DBA team will handle separately

plan.md

plan.md ファイルは、タスクとそのスコープを定義します。 plan.mdを次の内容に編集します。

• タスクを並べ替えて実行シーケンスを変更します。
• エージェントが計画していないタスクを追加します。
• 適用されないタスクを削除します。
• 特定のタスクのコンテキストを提供するメモを追加します。

個々のタスク ファイル

tasks/{taskId}/task.mdの各タスクには、タスクの仕様と作業メモが含まれています。 次のファイルを編集して次の目的を達成します:

• タスクのスコープを調整します。
• エージェントが見逃したドメイン固有のコンテキストを追加します。
• 目的の結果のコード例を指定します。

Important

エージェントのツールは、読み取り専用ダッシュボードとして tasks.md を管理します。 tasks.mdを直接編集しないでください。 エージェントによって手動による変更が上書きされます。 代わりに、 scenario-instructions.md または個々の task.md ファイルを編集します。

カスタム スキルを作成する

スキルは、エージェントの主要な拡張ポイントです。 スキルは、エージェントが特定のアップグレード、パターン、またはタスクを処理する方法を説明するメタデータ ヘッダーを含む Markdown ファイルです。

カスタム スキルを配置する場所

場所	Scope	次の場合に使用します。
.github/skills/my-skill.md	リポジトリ (チームと共有)	チーム全体のアップグレード パターン
.github/upgrades/skills/my-skill.md	リポジトリ (アップグレード専用)	アップグレード シナリオに固有のスキル
%UserProfile%/.copilot/skills/my-skill.md	ユーザー プロファイル (個人用、すべてのリポジトリ)	個人の好みとパターン

ヒント

リポジトリ レベルのスキル (.github/skills/) が最も一般的な選択肢です。 彼らはコードと一緒に移動し、チーム全体でそれらを使用することができます。

スキル ファイルの構造

すべてのスキル ファイルには、メタデータ ヘッダー (エージェントがスキルが適用されるタイミングを理解するために使用される) と Markdown 本文 (エージェントが従う手順) の 2 つの部分があります。

---
name: migrating-foobar-v2-to-v3
description: >
  Migrate our internal FooBar library from v2 to v3. Activates when
  FooBar.v2 NuGet package is detected, or when asked to "upgrade FooBar",
  "migrate FooBar", or "update FooBar library".
metadata:
  discovery: lazy
  traits: .NET | CSharp
---

# Migrating FooBar Library v2 to v3

## Overview

FooBar v3 introduces a new async-first API surface. This skill guides the
agent through replacing synchronous FooBar.v2 calls with their v3 async
equivalents, updating configuration, and verifying behavior.

## Workflow

1. **Identify FooBar.v2 references**
   - Search for `PackageReference` elements referencing `FooBar.v2`
   - Locate all `using FooBar.V2;` directives

2. **Update package references**
   - Replace `FooBar.v2` with `FooBar.v3` in all `.csproj` files
   - Run `dotnet restore` to verify resolution

3. **Migrate API calls**
   - Replace `FooBarClient.Send(...)` with `await FooBarClient.SendAsync(...)`
   - Replace `FooBarConfig.LoadFromFile(...)` with `FooBarConfig.LoadFromJsonAsync(...)`
   - Update method signatures to `async Task` where needed

4. **Update configuration**
   - Rename `foobar.config` to `foobar.json`
   - Migrate XML config entries to JSON format

5. **Verify**
   - Build the project: `dotnet build`
   - Run existing tests: `dotnet test`
   - Verify no remaining references to `FooBar.V2` namespace

## Success Criteria

- [ ] No references to `FooBar.v2` NuGet package remain
- [ ] All `FooBar.V2` namespace usages replaced with `FooBar.V3`
- [ ] Project builds without errors
- [ ] All existing tests pass

## Error Handling

- If `FooBar.v3` is not available in the configured NuGet feeds, instruct
  the user to add the internal feed
- If async migration causes deadlocks in legacy synchronous code paths,
  wrap calls with `.GetAwaiter().GetResult()` and add a TODO comment

メタデータ フィールド

フィールド	必須	説明
name	はい	kebab-case の一意な識別子。 動名詞 (たとえば、upgrading-、converting-) から始めます。 最大 64 文字。
description	はい	エージェントがスキルを読み込むタイミングを決定します。 スキルをアクティブにする必要がある単語やパターンなどのトリガー フレーズを含めます。
metadata.discovery	いいえ	スキルが読み込まれるタイミングを制御します。 preload (常に使用可能)、 lazy (説明が一致する場合はオンデマンド、既定と推奨)、または scenario (ワークフロー オーケストレーターを定義します)。
metadata.traits	いいえ	.NET、CSharp、VisualBasic、DotNetCore など、プロジェクト内のテクノロジを記述するキーワード。

スキル作成のベスト プラクティス

• 具体的には、次の説明を参照してください。 ユーザーが入力する可能性がある正確なパッケージ名、ライブラリ名、および自然言語トリガー フレーズを含めます。
• 明確でステップ バイ ステップのワークフローを含めます。 ステップ数を指定します。 変更するファイルと実行するコマンドについて明示的に指定します。
• 成功条件を含めます。 成功条件がないと、エージェントは停止するタイミングを認識しません。 チェック ボックスまたは検証可能な条件のクリア リストを使用します。
• エラー処理を含めます。 パッケージの不足、ビルドエラー、壊れたテストなど、一般的な障害モードを予測します。
• スキルに集中する: アップグレードまたはタスクの種類ごとに 1 つのスキル。 "FooBar v2 から v3 へのアップグレード" のスキルは、"すべての内部ライブラリをアップグレードする" よりも優れています。
• 下付き動詞を持つ名前:upgrading-foobar-v2-to-v3やfoobar-upgradeではなく、foobar-v3を使用します。
• lazy検出を使用する: ほとんどのカスタム スキルに対してlazy検出を使用して、エージェントのコンテキスト ウィンドウが肥大化しないようにします。

カスタム シナリオを作成する

まったく新しいアップグレード ワークフローを定義する上級ユーザーの場合、カスタム シナリオでは、完全なマルチフェーズ アップグレード パイプラインを調整できます。 シナリオは、エージェントが従うフェーズを定義する metadata.discovery: scenario を持つスキルです。

---
name: migrating-soap-to-rest-api
description: >
  Migrate legacy WCF/SOAP services to ASP.NET Core REST APIs. Activates
  when WCF service references, .svc files, or SOAP clients are detected,
  or when asked to "migrate SOAP to REST", "replace WCF", or "convert
  web services to REST".
metadata:
  discovery: scenario
  traits: .NET | CSharp
  scenarioTraitsSet: [wcf, soap, web-services]
---

# SOAP to REST API Migration

## Pre-initialization

Gather from the user:
- Which SOAP services to migrate (all or specific ones)
- Whether to maintain backward compatibility with a SOAP facade
- Authentication mechanism for the new REST APIs
- API versioning strategy (URL path, header, query string)

## Assessment

Analyze the solution for:
- `.svc` files and WCF service contracts
- WSDL files and service references
- `System.ServiceModel` usage and binding configurations
- Data contracts and their serialization requirements
- Client proxies consuming SOAP services

## Planning

Create tasks in this order:
1. Create shared DTOs — Convert `[DataContract]` types to POCOs
2. Create REST controllers — One controller per `[ServiceContract]`
3. Map operations to HTTP methods
4. Migrate service implementations
5. Update clients — Replace `ChannelFactory`/generated proxies with `HttpClient`
6. Remove WCF infrastructure
7. Add API documentation — Swagger/OpenAPI via Swashbuckle

## Execution

For each service contract:
1. Create a corresponding controller
2. Create a service interface and implementation
3. Register the service in DI
4. Map WCF operations to REST endpoints
5. Update any in-solution clients to use the new REST endpoints
6. Build and run existing tests

エージェントがそれらを検出するために、シナリオ ファイルを .github/skills/ または .github/upgrades/skills/ に配置します。

ヒント

scenarioTraitsSet フィールドでは、エージェントがソリューションの特性とシナリオを照合するために使用する特性を定義します。 これらの特性は、エージェントが必要に応じてシナリオを提案するのに役立ちます。

ソース管理と分岐

エージェントは Git ブランチで作業することを提供しますが、戦略を完全に制御できます。

• ブランチの名前付け: 使用するブランチ名をエージェントに伝えるか、エージェントに提案させます。
• タスクごとの分岐: 詳細なレビューのために、タスクごとに個別のブランチを要求します。
• コミットのタイミング: 完了したタスク (既定)、完全アップグレードの最後のみ、またはオンデマンドで、エージェントがコミットするタイミングを選択します。
• ソース管理なし: エージェントは Git 以外のフォルダーでも動作しますが、最初にプロジェクトをバックアップすることをお勧めします。

チャット手順の例:

• "このアップグレードにはブランチ名 'upgrade/dotnet10' を使用してください"
• "タスクごとにブランチを作成して、それぞれを個別に確認できるようにします"
• "私が明示的にあなたに頼むまでコミットしないでください"
• "すべてのタスクの後に、わかりやすいメッセージでコミットする"

ヒント

大規模なマルチプロジェクトアップグレードでは、タスクごとのブランチを使用すると、各変更を個別に確認してマージしたり、残りの部分に影響を与えずに単一のタスクをロールバックしたりできます。

スキルの読み込みの優先順位

エージェントが複数のスキルを検出すると、優先度システムを使用して解決されます。 優先順位の高いソースは、優先順位の低いソースをオーバーライドまたは補足します。

優先度	情報源	場所
5 (最高)	カスタム スキル (API を通じてユーザーが提供)	—
4	ユーザー プロファイルスキル	%UserProfile%/.copilot/skills/
3	リポジトリのアップグレード スキル	.github/upgrades/skills/
2	リポジトリのスキル	.github/skills/
1 (最低)	埋め込みスキル (エージェントに組み込まれている)	—

エージェントは、すべてのソースからスキルを収集します。 スキルに重複するスコープがある場合は、優先順位の高いソースが優先されます。 discovery フィールドは、スキルが読み込まれるタイミングを制御します。 lazy は、必要に応じてオンデマンドを意味し、 preload は常に使用可能な状態を意味します。

ヒント

動作を変更するために、組み込みのスキルを置き換える必要はありません。 優先順位の高いリポジトリ スキルは、組み込みのスキルを補完し、ベースラインの動作に加えてチーム固有の規則を追加します。

関連するコンテンツ

• コアコンセプト
• シナリオとスキルリファレンス
• カスタム アップグレード手順を適用する
• ベスト プラクティス