Creating Oracle To Postgres Migration Bug Report
Document Oracle versus PostgreSQL parity defects in a consistent markdown bug report during a database migration.
Overview
Creating Oracle to Postgres Migration Bug Report is an agent skill most often used in Ship (also Build and Operate) that produces a standardized markdown defect report comparing Oracle baseline behavior to PostgreSQL res
Install
npx skills add https://github.com/github/awesome-copilot --skill creating-oracle-to-postgres-migration-bug-reportWhat is this skill?
- Filename convention BUG_REPORT_<DescriptiveSlug>.md for traceable migration tickets
- Six-section template: Problem, Scenario, Root Cause, Solution, Validation, Files Modified
- Status, severity, component, and related test fields for triage and audit trails
- Scenario block requires Oracle baseline expected result versus PostgreSQL actual result
- Root cause prompts explicit Oracle/PostgreSQL behavioral differences (NULL, coercion, types)
- Six main report sections: Problem, Scenario, Root Cause, Solution, Validation, Files Modified
- Four severity levels: Low, Medium, High, Critical
Adoption & trust: 1.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You found a PostgreSQL result or error that diverges from Oracle during migration, but ad-hoc notes do not give reviewers enough structure to reproduce, root-cause, or validate a fix.
Who is it for?
Teams or solo builders actively migrating from Oracle to PostgreSQL who need repeatable, engine-comparison bug write-ups linked to tests and code paths.
Skip if: Greenfield Postgres-only apps, generic app bugs unrelated to migration parity, or migrations between other database pairs without adapting the template.
When should I use this skill?
Use when creating bug reports for Oracle-to-PostgreSQL migration defects with observable parity differences.
What do I get? / Deliverables
You get a complete BUG_REPORT_<DescriptiveSlug>.md with problem, scenario, root cause, solution, validation, and file list ready for triage and parity re-runs on both databases.
- BUG_REPORT_<DescriptiveSlug>.md following the prescribed structure
- Validation checklist bullets confirming fix parity on Oracle and PostgreSQL
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Migration defects are usually surfaced and recorded while running parity tests and comparing behavior before or after cutover. Structured bug reports belong on the testing shelf because they capture expected-versus-actual results from reproduction steps and automated tests.
Where it fits
After changing a repository to use PostgreSQL types, you file a report when empty-string handling no longer matches Oracle semantics.
A parity test suite fails on PostgreSQL and you capture prerequisites, API steps, and expected Oracle output in one report.
Post-cutover production traffic exposes a coercion bug and you document validation checks and modified data-access files for the hotfix.
How it compares
Use this structured migration defect template instead of generic issue templates that omit Oracle baseline versus PostgreSQL actual comparisons.
Common Questions / FAQ
Who is creating-oracle-to-postgres-migration-bug-report for?
It is for developers and agents documenting parity failures during Oracle-to-PostgreSQL migration work, especially when automated tests or API checks expose behavioral differences.
When should I use creating-oracle-to-postgres-migration-bug-report?
Use it in Ship while running parity tests, in Build when fixing data-access layers, and in Operate when iterating on post-cutover defects—any time you need a factual BUG_REPORT_<slug>.md with Oracle expected versus PostgreSQL actual behavior.
Is creating-oracle-to-postgres-migration-bug-report safe to install?
It is a documentation template skill with no runtime side effects; review the Security Audits panel on this Prism page before installing from any third-party skills source.
SKILL.md
READMESKILL.md - Creating Oracle To Postgres Migration Bug Report
# Bug Report Template Use this template when creating bug reports for Oracle-to-PostgreSQL migration defects. ## Filename Format ``` BUG_REPORT_<DescriptiveSlug>.md ``` ## Template Structure ```markdown # Bug Report: <Title> **Status:** ✅ RESOLVED | ⛔ UNRESOLVED | ⏳ IN PROGRESS **Component:** <High-level component/endpoint and key method(s)> **Test:** <Related automated test names> **Severity:** Low | Medium | High | Critical --- ## Problem <Observable incorrect behavior. State expected behavior (Oracle baseline) versus actual behavior (PostgreSQL). Be specific and factual.> ## Scenario <Ordered steps to reproduce the defect. Include: 1. Prerequisites and seed data 2. Exact operation or API call 3. Expected result (Oracle) 4. Actual result (PostgreSQL)> ## Root Cause <Minimal, concrete technical cause. Reference the specific Oracle/PostgreSQL behavioral difference (e.g., empty string vs NULL, type coercion strictness).> ## Solution <Changes made or required. Be explicit about data access layer changes, tracking flags, and any client code modifications. Note whether changes are already applied or still needed.> ## Validation <Bullet list of passing tests or manual checks that confirm the fix: - Re-run reproduction steps on both Oracle and PostgreSQL - Compare row/column outputs - Check error handling parity> ## Files Modified <Bullet list with relative file paths and short purpose for each change: - `src/DataAccess/FooRepository.cs` — Added explicit NULL check for empty string parameter> ## Notes / Next Steps <Follow-ups, environment caveats, risks, or dependencies on other fixes.> ``` ## Status Values | Status | Meaning | |--------|---------| | ✅ RESOLVED | Defect has been fixed and verified | | ⛔ UNRESOLVED | Defect has not been addressed yet | | ⏳ IN PROGRESS | Defect is being investigated or fix is underway | ## Style Rules - Keep wording concise and factual - Use present or past tense consistently - Prefer bullets and numbered lists for steps and validation - Call out data layer nuances (tracking, padding, constraints) explicitly - Keep to existing runtime/language versions; avoid speculative fixes - Include minimal SQL excerpts and logs as evidence; omit sensitive data --- name: creating-oracle-to-postgres-migration-bug-report description: 'Creates structured bug reports for defects found during Oracle-to-PostgreSQL migration. Use when documenting behavioral differences between Oracle and PostgreSQL as actionable bug reports with severity, root cause, and remediation steps.' --- # Creating Bug Reports for Oracle-to-PostgreSQL Migration ## When to Use - Documenting a defect caused by behavioral differences between Oracle and PostgreSQL - Writing or reviewing a bug report for an Oracle-to-PostgreSQL migration project ## Bug Report Format Use the template in [references/BUG-REPORT-TEMPLATE.md](references/BUG-REPORT-TEMPLATE.md). Each report must include: - **Status**: ✅ RESOLVED, ⛔ UNRESOLVED, or ⏳ IN PROGRESS - **Component**: Affected endpoint, repository, or stored procedure - **Test**: Related automated test names - **Severity**: Low / Medium / High / Critical — based on impact scope - **Problem**: Expected Oracle behavior vs. observed PostgreSQL behavior - **Scenario**: Ordered reproduction steps with seed data, operation, expected result, and actual result - **Root Cause**: The specific Oracle/PostgreSQL behavioral difference causing the defect - **Solution**: Changes made or required, with explicit file paths - **Validation**: Steps to confirm the fix on both databases ## Oracle-to-PostgreSQL Guidance - **Oracle is the source of truth** — frame expected behavior from the Oracle baseline - Call out data layer nuances explicitly: empty string vs. NULL, type coercion strictness, collation, sequence values, time zones, padding, constraints - Client code changes should be avoided unless required for correct behavior; when proposed, document and justify them clearly ## Writing Style - Pla