Skip to main content

creating-oracle-to-postgres-migration-bug-report

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.

설치로 이동

소스 정보

저장소
github/awesome-copilot
최근 소스 활동
2026년 8월 11일 02:47
감지된 SKILL.md 언어
영어
스타
39,255
포크
4,987

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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 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`)
GitHub에서 보기