Anpassung der Modernisierung von GitHub Copilot

Der Modernisierungsprozess von GitHub Copilot ist erweiterbar. Der Agent stellt mehrere Anpassungspunkte bereit, um die Upgrademuster Ihres Teams zu kodifizieren, Codierungsstandards bei Upgrades durchzusetzen und neue Upgrade-Workflows zu definieren.

Übersicht über Anpassungspunkte

Anpassungspunkt Geltungsbereich Ausdauer Effort
Chatanweisungen Pro Sitzung oder Upgrade Sitzung oder gespeichert unter scenario-instructions.md Wenig
Artefakte des Szenarios Pro Upgrade Dauer des Upgrades Niedrig
Benutzerdefinierte Fähigkeiten Team oder persönlich Permanent (eingecheckt im Repo oder Benutzerprofil) Mittelstufe
Benutzerdefinierte Szenarien Team oder persönlich Dauerhaft Hoch

Tipp

Beginnen Sie mit Chatanweisungen und Szenarioartefaktenbearbeitungen. Wechseln Sie zu benutzerdefinierten Fähigkeiten, wenn Sie feststellen, dass Sie bei Upgrades immer wieder die gleichen Anweisungen wiederholen.

Anpassen durch Chat

Passen Sie das Verhalten des Agenten in Echtzeit über natürliche Unterhaltungen an. Der Agent wendet Ihre Anweisung entweder sofort an oder speichert sie zur späteren Verwendung in scenario-instructions.md.

Sie sagen: Was ist los
„Führen Sie von nun an immer ein Commit nach jeder Aufgabe durch“ Gespeichert in scenario-instructions.md als Ausführungsvorgabe
"Testüberprüfung für diese Aufgabe überspringen" Nur auf den aktuellen Vorgang sofort angewendet
"Verwenden der Bottom-Up-Strategie für dieses Upgrade" Beeinflusst die Strategie der Planungsphase
"Berühren Sie das Protokollierungsprojekt nicht" Zu den Einstellungen hinzugefügt: Der Agent schließt jenes Projekt aus.
„Verwenden Sie immer dateispezifische Namespaces“ Als Codierungsstandardeinstellung gespeichert
"Nach jeder Aufgabe für meine Überprüfung innehalten" Als Ausführungsstileinstellung gespeichert

Tipp

Um eine Anweisung für das gesamte Upgrade beizubehalten, geben Sie sie als dauerhafte Einstellung an: "Von jetzt an, immer..." oder "Für alle Aufgaben in diesem Upgrade...". Der Agent schreibt die Anweisung in scenario-instructions.md.

Bearbeiten von Szenarioartefakten

Wenn der Agent ein Upgrade ausführt, erstellt er einen Arbeitsbereich in .github/upgrades/{scenarioId}/. Der Upgradeordner enthält bearbeitbare Artefakte, die das Verhalten des Agents direkt steuern.

scenario-instructions.md

Die scenario-instructions.md Datei ist der persistente Speicher des Agents für das Upgrade. Der Agent lädt diese Datei immer in den Kontext, sodass alles, was Sie hier schreiben, direkt jede Entscheidung beeinflusst, die der Agent trifft.

Fügen Sie Abschnitte wie diese hinzu, um den Agent zu leiten:

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

Die plan.md Datei definiert die Aufgaben und deren Bereich. Bearbeiten plan.md zu:

  • Ordnen Sie Vorgänge neu an, um die Ausführungssequenz zu ändern.
  • Fügen Sie Aufgaben hinzu, die der Agent nicht geplant hat.
  • Entfernen Sie Aufgaben, die nicht angewendet werden.
  • Fügen Sie Notizen hinzu, um Kontext für bestimmte Aufgaben bereitzustellen.

Einzelne Aufgabendateien

In tasks/{taskId}/task.md enthält jede Aufgabe die Vorgangsspezifikation und Arbeitsnotizen. Bearbeiten Sie diese Dateien in:

  • Verfeinern Sie den Umfang einer Aufgabe.
  • Fügen Sie domänenspezifischen Kontext hinzu, den der Agent verpasst hat.
  • Stellen Sie Codebeispiele für das gewünschte Ergebnis bereit.

Von Bedeutung

Die Tools des Agenten verwalten tasks.md als schreibgeschütztes Dashboard. Bearbeiten Sie tasks.md nicht direkt. Der Agent überschreibt alle manuellen Änderungen. Bearbeiten Sie stattdessen scenario-instructions.md oder einzelne task.md Dateien.

Erstelle benutzerdefinierte Skills

Fähigkeiten sind der primäre Erweiterungspunkt für den Agenten. Eine Fähigkeit ist eine Markdown-Datei mit einem Metadatenheader, der dem Agent vermittelt, wie ein bestimmtes Upgrade, Muster oder eine bestimmte Aufgabe behandelt wird.

Wo sie benutzerdefinierte Fähigkeiten platzieren können

Ort Geltungsbereich Verwenden Sie, wenn
.github/skills/my-skill.md Repository (mit dem Team geteilt) Teamweite Upgrademuster
.github/upgrades/skills/my-skill.md Repository (upgrade-spezifisch) Spezifische Fähigkeiten für Upgradeszenarien
%UserProfile%/.copilot/skills/my-skill.md Benutzerprofil (persönlich, alle Repos) Persönliche Einstellungen und Muster

Tipp

Fähigkeiten auf Repositoryebene (.github/skills/) sind die am häufigsten verwendete Wahl. Sie reisen mit dem Code, und das gesamte Team kann sie verwenden.

Kompetenzdateistruktur

Jede Qualifikationsdatei hat zwei Teile: einen Metadatenheader (den der Agent verwendet, um zu verstehen, wann die Qualifikation gilt) und einen Markdown-Textkörper (Anweisungen, die der Agent folgt).

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

Metadatenfelder

Feld Erforderlich Beschreibung
name Ja Eindeutiger Bezeichner in Kebab-Case. Beginnen Sie mit einem Gerandium (zum Beispiel: upgrading-, converting-). Maximal 64 Zeichen.
description Ja Bestimmt, wann der Agent die Skill lädt. Schließen Sie Triggerausdrücke ein, z. B. Wörter und Muster, die die Fähigkeit aktivieren sollen.
metadata.discovery No Steuert, wann die Skill geladen wird: preload (immer verfügbar), lazy (bei Bedarf, wenn Beschreibung übereinstimmt, standardmäßig und empfohlen) oder scenario (definiert einen Workflow-Orchestrator).
metadata.traits No Schlüsselwörter, die die Technologien in Ihrem Projekt beschreiben, z. B. .NET, CSharp, VisualBasic oder DotNetCore.

Bewährte Methoden bei der Erstellung von Skills

  • Seien Sie in der Beschreibung spezifisch: Fügen Sie genaue Paketnamen, Bibliotheksnamen und in natürlicher Sprache formulierte Ausdrücke ein, die Benutzer eingeben können.
  • Fügen Sie klare, schrittweise Workflows ein: Nummer die Schritte. Geben Sie explizit an, welche Dateien geändert werden sollen und welche Befehle ausgeführt werden sollen.
  • Erfolgskriterien einschließen: Ohne Erfolgskriterien weiß der Agent nicht, wann er aufhören soll. Verwenden Sie Kontrollkästchen oder eine liste der überprüfbaren Bedingungen.
  • Fehlerbehandlung einbeziehen: Berücksichtigen Sie häufige Fehlermodi, wie z. B. fehlende Pakete, Buildfehler oder fehlgeschlagene Tests.
  • Konzentrieren Sie sich auf Fähigkeiten: Eine Fähigkeit pro Upgrade oder Aufgabentyp. Eine Fähigkeit zum "Upgraden von FooBar v2 auf v3" ist besser als "Upgrade aller internen Bibliotheken".
  • Name mit einem Gerundverb: Verwenden upgrading-foobar-v2-to-v3, nicht foobar-upgrade oder foobar-v3.
  • Verwenden Sie die lazy Ermittlung: Verwenden Sie lazy die Ermittlung für die meisten benutzerdefinierten Skills, um zu vermeiden, dass das Kontextfenster des Agenten überfrachtet wird.

Erstellen von benutzerdefinierten Szenarien

Für erweiterte Benutzer, die völlig neue Upgradeworkflows definieren möchten, können Sie in benutzerdefinierten Szenarien eine vollständige mehrstufige Upgradepipeline koordinieren. Ein Szenario ist eine Fähigkeit, mit metadata.discovery: scenario der die Phasen definiert werden, die der Agent folgt.

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

Platzieren Sie Szenariodateien in .github/skills/ oder .github/upgrades/skills/, damit der Agent sie ermitteln kann.

Tipp

Das scenarioTraitsSet Feld definiert Merkmale, die der Agent zum Abgleichen Ihres Szenarios mit den Eigenschaften der Lösung verwendet. Diese Merkmale helfen dem Agent bei Bedarf, Ihr Szenario vorzuschlagen.

Quellcodeverwaltung und Verzweigung

Der Agent bietet an, auf einem Git-Branch zu arbeiten, aber Sie behalten die volle Kontrolle über die Strategie.

  • Branch-Benennung: Geben Sie dem Agenten den gewünschten Branch-Namen an oder lassen Sie den Agenten einen Namen vorschlagen.
  • Branches pro Aufgabe: fordern Sie für eine detaillierte Überprüfung einen separaten Branch pro Aufgabe an.
  • Commit-Zeitpunkt: Wählen Sie aus, wann der Agent die Commits durchführt: nach jeder abgeschlossenen Aufgabe (Standard), erst am Ende des vollständigen Upgrades oder auf Abruf.
  • Keine Quellcodeverwaltung: Der Agent funktioniert auch mit Nicht-Git-Ordnern, empfiehlt jedoch, zuerst Das Projekt zu sichern.

Beispiel-Chatanweisungen:

  • "Verzweigungsname 'upgrade/dotnet10' für dieses Upgrade verwenden"
  • "Einen Branch für jede Aufgabe erstellen, damit ich jede einzeln prüfen kann"
  • „Führen Sie kein Commit durch, bevor Sie nicht ausdrücklich darum gebeten werden“
  • „Führen Sie nach jeder Aufgabe Commit mit einer beschreibenden Nachricht durch“

Tipp

Bei großen Multiprojektupgrades geben Ihnen Aufgabenzweige die Flexibilität, jede Änderung unabhängig zu überprüfen und zusammenzuführen oder eine einzelne Aufgabe zurückzusetzen, ohne dass dies den Rest beeinflusst.

Skill-Ladepriorität

Wenn der Agent mehrere Fähigkeiten entdeckt, löst er sie mithilfe eines Prioritätssystems auf. Quellen mit höherer Priorität überschreiben niedrigere Prioritäten oder ergänzen diese.

Priorität Quelle Ort
5 (höchste) Benutzerdefinierte Fähigkeiten (vom Benutzer über API bereitgestellt) —
4 Benutzerprofilfähigkeiten %UserProfile%/.copilot/skills/
3 Fähigkeiten zur Aktualisierung von Repositorys .github/upgrades/skills/
2 Repository-Fähigkeiten .github/skills/
1 (niedrigster Wert) Eingebettete Fähigkeiten (in den Agent integriert) —

Der Agent sammelt Fähigkeiten aus allen Quellen. Wenn Fähigkeiten einen überlappenden Bereich haben, haben Quellen mit höherer Priorität Vorrang. Das discovery Feld steuert, wann die Funktion geladen wird. lazy bedeutet bedarfsgesteuert und preload bedeutet immer verfügbar.

Tipp

Sie müssen keine integrierte Fähigkeit zum Ändern des Verhaltens ersetzen. Eine Repository-Funktion mit höherer Priorität ergänzt die integrierte Skill und erweitert das Basisverhalten um die spezifischen Konventionen Ihres Teams.

Verwandte Inhalte

  • Last updated on