Legacy dotnet agent kit

LegacyDotnetAgentKit

Use this skill to help an agent modernize a legacy .NET codebase without losing hidden behavior.

Operating Rules

1. Treat the repository as the source of truth.
2. Read repo-local agent instructions, contribution notes, architecture docs, and feedback logs before changing code.
3. Map current behavior before proposing a migration.
4. Preserve user-visible behavior unless the user explicitly asks to change it.
5. Find the real authority boundary: UI, client service, server call, workflow engine, database, cache, or external integration.
6. Keep modernization slices small, reviewable, and testable.
7. Report verification honestly. Do not imply runtime confidence when only static checks were possible.
8. Leave durable notes so the next agent can continue without relying on chat history.

Default Workflow

1. Intake: inspect local rules, project files, relevant docs, entry points, and recent changes.
2. Behavior map: trace the current user flow, data flow, permission flow, and failure states from source.
3. Risk register: identify cache, async, security, data-shape, duplicated logic, and legacy dependency risks.
4. Slice plan: choose one behavior-preserving modernization slice with clear acceptance criteria.
5. Implementation: make narrow changes that respect existing boundaries. Avoid broad rewrites unless the user explicitly chose that tradeoff.
6. Verification: run available checks. If builds or tests are unavailable, do source-level checks and name the gap.
7. Handoff: update the project feedback log or create a handoff note with decisions, validation, and remaining risk.

What To Inspect First

• Repo-local agent instructions: AGENTS.md, AGENT.md, .github/copilot-instructions.md, or equivalent.
• Feedback or operating memory: collaboration_feedback_log.md, docs/, ADRs, migration notes, or issue trackers.
• Project shape: *.sln, *.csproj, package files, target frameworks, generated client code, and old framework references.
• Workflow entry points: UI event handlers, controllers, services, server calls, background jobs, and report renderers.
• Data boundaries: repositories, custom ORM layers, DTO selection shapes, cache layers, migrations, and database scripts.
• Security boundaries: server-side checks, role checks, data-scope filters, ownership rules, and generic-operation restrictions.

Reference Files

Load only the reference needed for the task:

• references/intake.md: use before planning or implementation.
• references/risk-patterns.md: use during audits and modernization planning.
• references/migration-slices.md: use when choosing implementation scope.
• references/verification.md: use before final handoff.
• references/agent-handoff.md: use when writing durable continuation notes.

Recommended Outputs

Use templates from the repo root when helpful:

• templates/architecture-map.md
• templates/current-behavior-map.md
• templates/migration-risk-register.md
• templates/modernization-slice-plan.md
• templates/regression-test-matrix.md
• templates/agent-feedback-log.md
• templates/rewrite-boundary-assessment.md

Guardrails

• Do not treat Entity Framework, a new API, or MVVM as a drop-in replacement for domain behavior.
• Do not move permission decisions from server-side code into client-side UI state.
• Do not optimize loading until you know which data is required for first render.
• Do not replace old reporting or workflow systems until active business use and fallback needs are mapped.
• Do not call a migration complete when it is only a source-level slice.