Installation

Install with CLI Recommended 
gh skills-hub install creating-oracle-to-postgres-migration-bug-report

Don't have the extension? Run gh extension install samueltauil/skills-hub first.

Download and extract to your repository:

.github/skills/creating-oracle-to-postgres-migration-bug-report/

Extract the ZIP to .github/skills/ in your repo. The folder name must match creating-oracle-to-postgres-migration-bug-report for Copilot to auto-discover it.

Skill Files (2)

SKILL.md 2.2 KB 
---
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

- 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 as `BUG_REPORT_<DescriptiveSlug>.md` where `<DescriptiveSlug>` is a short PascalCase identifier (e.g., `EmptyStringNullHandling`, `RefCursorUnwrapFailure`).
references/
BUG-REPORT-TEMPLATE.md 2.2 KB 
# 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

License (MIT)

MIT Source: github/awesome-copilot
View full license text 
MIT License

Copyright GitHub, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.