'Oracle-to-PostgreSQL Migration Expert' Custom Agent: Update Custom Agent & Plugin & Skills (#2566)

* Enhance Oracle-to-PostgreSQL migration skills and documentation

- Update migration agent guidelines to prioritize extension tool usage for code migration.
- Refine migration phases with detailed steps for pre-migration review and schema migration.
- Add new reviewing skill references for PostgreSQL materialized view refresh and UNION ALL planner risks.
- Ensure consistency in collation handling and testing strategies across skills.

* - Review migration phases to ensure correct order of execution
- Add exit criteria to each migration phase
- Remove invocation of `ms-ossdata.vscode-pgsql` extension due to dependency on VSCode
- Update README.md to reflect changes in migration phases and exit criteria
- Update broken reference to custom agent in plugin.json

* Enhance downstream migration skills and following custom agent improvements

- Added new skill for migrating .NET data access code from Oracle to PostgreSQL.
- Updated README to include new migration skill.
- Improved existing skills with clearer file naming conventions and migration actions.
- Added reference documents for handling Oracle-specific functions and pagination.
- Created detailed guides for NVL, DECODE, ROWNUM, SYSDATE, and DUAL replacements.

* Clarify PostgreSQL schema immutability and stored procedure migration risks

* Update target schema path in migration documentation for clarity

* fix(skills): clarify Phase 3-only scope for Oracle test skills

Both Oracle test skills were ambiguously worded in ways that could
cause a model to invoke them during Phase 6 (PostgreSQL test migration)
instead of using them exclusively in Phase 3.

Key changes:
- Rewrite descriptions to explicitly state Phase 3-only usage and
  warn against invoking during Phase 6
- Replace "scaffold for Oracle first" with "Oracle only" to remove
  the false implication of a second PostgreSQL scaffolding step
- Replace "Tests validate behavior consistency when running against
  Oracle or PostgreSQL" with clear Oracle-only framing
- Rename "DB-agnostic assertions" → "Assertion portability" and
  explain the why (survive Phase 6 migration without rewrites)
- Fix datetime bullet in integration tests skill to use generic
  Oracle column precision language instead of PostgreSQL type syntax
- Name Oracle NuGet package explicitly (Oracle.ManagedDataAccess.Core)

* feat(oracle-to-postgres): gate Phase 1 on DDL presence; add DDL scan to Phase 2 risk analysis

- Phase 1 success criteria now requires Oracle DDL artifacts to be
  confirmed present at the recorded location before proceeding.
  If missing, the agent stops and prompts the user to provide them.

- Phase 2 risk analysis now explicitly scans DDL/Oracle/{ProjectName}/
  as supplemental context, summarising procedure complexity indicators
  (dynamic SQL, DBMS_* / UTL_* references, autonomous transactions,
  pipelined functions, BULK COLLECT/FORALL, REF CURSOR, TYPE bodies)
  rather than ingesting DDL files wholesale. This ensures schema-level
  migration risk is captured even when it isn't visible in application
  code alone.

* - Merge in latest 'main' changes
- Update custom agent plugin (eg resolve conflict and add new skill)
- Validate skills
- Run build

* chore(plugin.json): update version to 1.1.0

* feat(oracle-to-postgres): update version to 1.1.0 for migration expert plugin

* fix: add INOUT to ignore-words-list for PostgreSQL migration

---------

Co-authored-by: TCPrimedPaul <paul.delannoy@tc.gc.ca>
This commit is contained in:
Paul Delannoy
2026-08-10 22:47:51 -04:00
committed by GitHub
parent 3f0bba475e
commit f7e8aaa2d8
18 changed files with 562 additions and 89 deletions
@@ -1,6 +1,6 @@
---
name: scaffolding-oracle-to-postgres-migration-test-project
description: 'Scaffolds an xUnit integration test project for validating Oracle-to-PostgreSQL database migration behavior in .NET solutions. Creates the test project, transaction-rollback base class, and seed data manager. Use when setting up test infrastructure before writing migration integration tests, or when a test project is needed for Oracle-to-PostgreSQL validation.'
description: 'Scaffolds an xUnit integration test project targeting Oracle in .NET solutions. Creates the test project, transaction-rollback base class, and seed data manager. Use only during Phase 3, before writing Oracle baseline integration tests. Do not invoke during Phase 6 — the PostgreSQL test project is produced by migrating this project, not by running this skill again.'
---
# Scaffolding an Integration Test Project for Oracle-to-PostgreSQL Migration
@@ -25,7 +25,7 @@ Read the target project's `.csproj` to determine the .NET version and existing p
**Step 2: Create the xUnit test project**
- Target the same .NET version as the application under test.
- Add NuGet packages for Oracle database connectivity and xUnit.
- Add NuGet packages for Oracle database connectivity (`Oracle.ManagedDataAccess.Core`) and xUnit.
- Add a project reference to the target project only — no other application projects.
- Add an `appsettings.json` configured for Oracle database connectivity.
@@ -40,7 +40,6 @@ Read the target project's `.csproj` to determine the .NET version and existing p
- Create a global seed manager for loading test data within the transaction scope.
- Do not commit seed data — transactions roll back after each test.
- Do not use `TRUNCATE TABLE` — preserve existing database data.
- Reuse existing seed files if available.
- Establish a naming convention for seed file location that downstream test creation will follow.
**Step 5: Verify the project compiles**
@@ -49,6 +48,7 @@ Build the test project and confirm it compiles with zero errors before finishing
## Key Constraints
- Oracle is the golden behavior source — scaffold for Oracle first.
- **Phase 3 only** — this skill scaffolds the Oracle-targeting test project. The PostgreSQL test project (Phase 6) is created by copying and migrating this project; do not run this skill again at that point.
- Oracle is the golden behavior source — scaffold for Oracle only, not PostgreSQL.
- Keep to existing .NET and C# versions; do not introduce newer language or runtime features.
- Output is an empty test project with infrastructure only — no test cases.