Bug Triage

---
name: bug-triage
description: Triage and fix GitHub bug reports for Aries AI. Use when a GitHub issue is classified as a bug, regression, defect, outage, broken flow, or runtime failure that should be reproduced, fixed on a branch, validated before/after, deployed to staging, and tracked in data/feedback-processing-log.json.
---

# Bug Triage

Use this skill for GitHub issues that represent defects in `DeliciousHouse/aries-app`.

## Read this when needed
- Severity rubric: `references/severity-rubric.md`

## Required inputs
- GitHub issue number
- Repo root: `/app/aries-app`
- Feedback log: `data/feedback-processing-log.json`

## Required procedure
1. Confirm the issue record is pending in the feedback log:
   - Inspect `data/feedback-processing-log.json` for the issue entry.
2. Inspect the issue in GitHub:
   - `gh issue view <number> --repo DeliciousHouse/aries-app --json title,body,labels,comments,url`
3. Classify severity using the rubric.
4. Reproduce the bug before changing code.
   - Prefer an existing failing test.
   - If none exists, add the smallest targeted regression test that fails first.
   - If automation is impossible, record the exact manual repro steps and expected/actual behavior.
5. Locate the likely root cause in the checked-in code.
6. Create a branch named `bugfix/issue-<number>-<slug>`.
7. Implement the smallest safe fix.
8. Run validation in this order:
   - targeted regression test(s)
   - nearest related test file(s)
   - broader repo validation only as needed for confidence
9. Deploy the branch to staging:
   - Use the project's staging deploy process; if none is configured, record `staging: missing-config` and continue.
10. Verify the bug is reproducible before the fix and not reproducible after the fix.
11. Update `data/feedback-processing-log.json` so the record includes:
   - `severity`
   - `rootCause`
   - `branch`
   - `validationBefore`
   - `validationAfter`
   - `stagingUrl`
   - `status`
   - `summaryPending`
12. If severity is `critical`, make the result explicit in your final output so the caller can alert immediately.

## Guardrails
- Do not claim a fix without before/after evidence.
- Do not skip staging verification unless the staging deploy hook is missing; if it is missing, fail loudly with the exact missing env/config.
- Prefer minimal, reversible fixes over broad refactors.
- Keep unsupported scope creep out of the bug fix.

## Output format
Return only:
- `status:` success or failed
- `issue:` `#<number>`
- `severity:` critical/high/medium/low
- `root_cause:` short phrase
- `branch:` branch name or `none`
- `validation_before:` one line
- `validation_after:` one line
- `staging:` URL or `failed` or `missing-config`
- `alert:` `critical` or `none`
- `next_step:` short operator follow-up or `none`