GitHub Copilot 현대화 사용자 지정

GitHub Copilot 현대화는 확장할 수 있습니다. 에이전트는 팀의 업그레이드 패턴을 인코딩하고, 업그레이드 중에 코딩 표준을 적용하고, 새 업그레이드 워크플로를 정의하는 여러 사용자 지정 지점을 제공합니다.

사용자 지정 지점 개요

채팅을 통해 사용자 지정

자연스러운 대화를 통해 실시간으로 에이전트의 동작을 사용자 지정합니다. 에이전트는 즉시 명령을 적용하거나 나중에 참조할 수 있도록 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

계획.md

파일은 plan.md 작업 및 해당 범위를 정의합니다. plan.md를 편집합니다:

• 작업 순서를 변경하여 실행 순서를 변경합니다.
• 에이전트가 계획하지 않은 작업을 추가합니다.
• 적용되지 않는 작업을 제거합니다.
• 특정 작업에 대한 컨텍스트를 제공하는 메모를 추가합니다.

개별 작업 파일

각 tasks/{taskId}/task.md 작업에는 작업 사양 및 작업 노트가 포함됩니다. 다음 파일을 편집하십시오:

• 작업의 범위를 구체화합니다.
• 에이전트가 놓친 도메인별 컨텍스트를 추가합니다.
• 원하는 결과에 대한 코드 예제를 제공합니다.

사용자 지정 기술 만들기

기술은 에이전트의 기본 확장 지점입니다. 기술은 특정 업그레이드, 패턴 또는 작업을 처리하는 방법을 에이전트에 알려주는 메타데이터 헤더가 있는 Markdown 파일입니다.

사용자 지정 기술을 배치할 위치

기술 파일 구조

모든 기술 파일에는 메타데이터 헤더(에이전트가 기술이 적용되는 시기를 이해하는 데 사용됨) 및 Markdown 본문(에이전트가 따르는 지침)의 두 부분이 있습니다.

---
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

메타데이터 필드

기술 작성 모범 사례

• 설명에서 구체적으로 설명합니다. 사용자가 입력할 수 있는 정확한 패키지 이름, 라이브러리 이름 및 자연어 트리거 구를 포함합니다.
• 명확한 단계별 워크플로를 포함합니다. 단계에 번호를 매깁니다. 변경할 파일과 실행할 명령에 대해 명시적이어야 합니다.
• 성공 조건 포함: 성공 기준이 없으면 에이전트는 언제 중지해야 하는지 알 수 없습니다. 확인란 또는 확인 가능한 조건의 명확한 목록을 사용합니다.
• 오류 처리 포함: 패키지 누락, 빌드 실패 또는 테스트 실패와 같은 일반적인 오류 모드를 예상합니다.
• 기술 집중 유지: 업그레이드 또는 작업 유형당 하나의 기술입니다. "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/에 배치하세요.

소스 제어 및 분기

에이전트는 Git 브랜치에서 작업하라고 제안하지만, 전략을 전적으로 관리할 수 있습니다.

• 분기 이름 지정: 에이전트에 사용할 분기 이름을 알리거나 에이전트가 이름을 제안하도록 합니다.
• 작업별 분기: 세분화된 검토를 위해 작업당 별도의 분기를 요청합니다.
• 커밋 타이밍: 에이전트가 커밋할 시기를 선택합니다. 완료된 모든 작업(기본값) 후, 전체 업그레이드가 끝날 때만 또는 요청 시 선택합니다.
• 소스 제어 없음: 에이전트는 Git이 아닌 폴더에서도 작동하지만 먼저 프로젝트를 백업하는 것이 좋습니다.

채팅 지침 예제:

• "이 업그레이드에 분기 이름 'upgrade/dotnet10'을 사용합니다."
• "각 분기를 개별적으로 검토할 수 있도록 작업당 분기 만들기"
• "명시적으로 요청할 때까지 커밋하지 마세요."
• "설명 메시지를 사용하여 모든 작업 후에 커밋"

기술 로드 우선 순위

에이전트가 여러 기술을 검색하면 우선 순위 시스템을 사용하여 문제를 해결합니다. 우선 순위가 높은 원본은 우선 순위가 낮은 원본을 재정의하거나 보완합니다.

에이전트는 모든 원본에서 기술을 수집합니다. 기술에 겹치는 범위가 있는 경우 우선 순위가 높은 원본이 우선합니다. discovery 필드는 기술이 로드되는 시기를 제어합니다. lazy 는 관련될 때 요청 시를 의미하며, preload 는 항상 이용 가능함을 의미합니다.

관련 콘텐츠

• 핵심 개념
• 시나리오 및 기술 참조
• 사용자 지정 업그레이드 지침 적용
• 모범 사례