|
| 1 | +--- |
| 2 | +name: create-bug-reports |
| 3 | +agent: 'agent' |
| 4 | +description: 'Create clear, user-friendly bug reports for Oracle-to-Postgres application migration issues.' |
| 5 | +model: Claude Haiku 4.5 (copilot) |
| 6 | +tools: [vscode/askQuestions, read, edit, search] |
| 7 | +--- |
| 8 | +# Create Bug Reports for Oracle to Postgres Migration |
| 9 | + |
| 10 | +Generate a concise, easy-to-understand bug report for the defect discovered while validating the application migration from Oracle to Postgres. This prompt targets a **single project** identified by `TARGET_PROJECT`. |
| 11 | + |
| 12 | +## Expected Inputs (from router handoff payload) |
| 13 | + |
| 14 | +| Key | Required | Description | |
| 15 | +|---|---|---| |
| 16 | +| `SOLUTION_ROOT` | Yes | Resolved workspace root path. | |
| 17 | +| `TARGET_PROJECT` | Yes | Absolute path to the single application project whose failures are being reported (e.g., `C:/Source/MyApp/MIUS.API.Postgres`). | |
| 18 | + |
| 19 | +INSTRUCTIONS: |
| 20 | +- Treat Oracle as the source of truth; capture expected Oracle behavior versus observed Postgres behavior. |
| 21 | +- Keep wording user-friendly: plain language, short sentences, and clear next actions. |
| 22 | +- Document when client code changes were made or are being proposed; emphasize that changes should be avoided unless required for correct behavior. |
| 23 | +- Always include: summary, impacted feature/flow, severity, environment (Oracle/Postgres, build, branch), prerequisites/seed data, exact repro steps, expected vs actual results, scope of impact, and workaround (if any). |
| 24 | +- Attach supporting evidence: minimal SQL excerpts, logs, and screenshots; avoid sensitive data and keep snippets reproducible. |
| 25 | +- Note data-specific factors (collation, null handling, sequence values, time zones) that might differ between Oracle and Postgres. |
| 26 | +- Recommend a validation step after fixes (re-run repro on both DBs, compare row/column outputs, and check error handling parity). |
| 27 | + |
| 28 | +OUTPUT LOCATION: |
| 29 | +- Save each bug report under `{SOLUTION_ROOT}/.github/o2p-dbmigration/Reports/` using a clear, human-readable filename (e.g., `Bug - {area} - {short-title}.md`). |
| 30 | + |
| 31 | +OUTPUT INSTRUCTIONS: |
| 32 | +Bug Report Output Definition (Template) |
| 33 | +• Filename format: .github/o2p-dbmigration/Reports/BUG_REPORT_<DescriptiveSlug>.md |
| 34 | +• Status line: Status: [✅ RESOLVED | ⛔ UNRESOLVED | ⏳ IN PROGRESS] |
| 35 | +• Component: <High-level component/endpoint and key method(s)> |
| 36 | +• Test(s): <Related automated test names> |
| 37 | +• Severity: <Low | Medium | High | Critical> |
| 38 | + |
| 39 | +Sections (markdown headings): |
| 40 | +1. # Bug Report: <Title> — concise, specific. |
| 41 | +2. **Status:** <status> |
| 42 | +**Component:** <controller/method> |
| 43 | +**Test:** <test(s)> |
| 44 | +**Severity:** <level> |
| 45 | +3. --- |
| 46 | +4. ## Problem — observable incorrect behavior and expected vs actual. |
| 47 | +5. ## Scenario — ordered steps to reproduce. |
| 48 | +6. ## Root Cause — minimal, concrete technical cause. |
| 49 | +7. ## Solution — changes made or required (be explicit about data access/tracking flags). |
| 50 | +8. ## Validation — bullet list of passing tests or manual checks. |
| 51 | +9. ## Files Modified — bullet list with relative paths and short purpose. |
| 52 | +10. ## Notes / Next Steps — follow-ups, environment caveats, or risks. |
| 53 | + |
| 54 | +Style rules: |
| 55 | +• Keep wording concise and factual. |
| 56 | +• Use present or past tense consistently. |
| 57 | +• Prefer bullets/numbered lists for steps and validation. |
| 58 | +• Call out data layer nuances (tracking, padding, constraints) explicitly. |
| 59 | +• Keep to existing runtime/language versions; avoid speculative fixes. |
0 commit comments