Creating Oracle To Postgres Migration Bug Report — Agent Skill by GitHub

From the author

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.

— the description by PrimedPaul

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured framework for identifying, reporting, and resolving technical discrepancies that arise when migrating from Oracle to PostgreSQL. It emphasizes using Oracle as the source of truth and requires detailed documentation of behavioral differences, such as NULL handling, type coercion, and collation issues, to ensure parity and maintainability throughout the migration lifecycle.

What it does

Defines a standardized bug report template for migration-related defects.
Establishes a naming convention for tracking bug reports within the project repository.
Provides guidelines for identifying root causes related to database behavioral differences.
Outlines the necessary sections for a complete bug report, including status, severity, and validation steps.
Encourages clear, concise documentation of data layer nuances and required code changes.

When to use it

When you encounter a functional defect caused by differences between Oracle and PostgreSQL.
When you need to document a bug report for a migration project to ensure team alignment.
When reviewing existing bug reports to ensure they meet project standards for clarity and actionability.
When you need to track the resolution status of migration-related database issues.

Advantages

Ensures consistency in how migration defects are documented and tracked.
Facilitates faster debugging by requiring explicit reproduction steps and root cause analysis.
Promotes clear communication between team members regarding database behavioral differences.
Helps maintain high standards for validation and testing during the migration process.

Usage examples

“Create a bug report for an issue where empty strings are being converted to NULL during migration.”: The agent generates a markdown file using the required template, detailing the problem, reproduction steps, and the specific Oracle-to-PostgreSQL behavioral difference regarding empty strings.
“How should I document a fix for a sequence value mismatch found in the migration?”: The agent provides the structure to document the root cause, the specific file paths modified in the data access layer, and the validation steps to confirm parity between the two databases.

Install

Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/creating-oracle-to-postgres-migration-bug-report/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip creating-oracle-to-postgres-migration-bug-report.zip -d .agents/skills

Documentation by PrimedPaul

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

Plain language, short sentences, clear next actions
Present or past tense consistently
Bullets and numbered lists for steps and validations
Minimal SQL excerpts and logs as evidence; omit sensitive data and keep snippets reproducible
Stick to existing runtime/language versions; avoid speculative fixes

Filename Convention

Save bug reports to .github/oracle-to-postgres-migration/Reports/{ProjectName}/BUG_REPORT_<DescriptiveSlug>.md where:

{ProjectName} is the project's assembly/folder name with spaces normalized to - (e.g. MyApp.DataAccess)
<DescriptiveSlug> is a short PascalCase identifier describing the defect (e.g., EmptyStringNullHandling, RefCursorUnwrapFailure)

Files

ATTRIBUTION.mdAdded by AutoGineer933 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md2.4 KiB
references/BUG-REPORT-TEMPLATE.md2.2 KiB

references/BUG-REPORT-TEMPLATE.md

Bug Report Template

Use this template when creating bug reports for Oracle-to-PostgreSQL migration defects.

Filename Format

BUG_REPORT_<DescriptiveSlug>.md

Template Structure

# 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

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Migrate To Shoehorn
Matt Pocock· Community
Automate the migration of TypeScript test assertions from unsafe as-casting to the type-safe shoehorn library.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
MITGitHub stars of the source repository317.5k
Tdd
Matt Pocock· Community
A reference guide for implementing the red-green-refactor loop in test-driven development.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
MITGitHub stars of the source repository317.5k
Test Driven Development
Jesse Vincent (obra)· Community
A rigorous framework for Test-Driven Development, mandating that failing tests precede all production code.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
MITGitHub stars of the source repository314k
Webapp Testing
AnthropicOfficial
A toolkit for automating local web application testing using Playwright and server management helpers.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
Apache-2.0Low riskHas scriptsGitHub stars of the source repository188.6k
Test Driven Development
Addy Osmani· Community
A systematic approach to software development using the red-green-refactor cycle to ensure code reliability and maintainability.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
MITGitHub stars of the source repository113.9k
Browser Testing With Devtools
Addy Osmani· Community
Integrate Chrome DevTools to enable live browser inspection, debugging, and automated UI verification for your AI agent.
Software developmentClaude CodeClaude appsOpenAI Codex+14 more
MITGitHub stars of the source repository113.9k

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download creating-oracle-to-postgres-migration-bug-report.zip