whisper-money/.pi/prompts/sentry-issue.md

description	argument-hint
Pick or fix a Sentry issue end-to-end, then PR and watch CI	[issue-id-or-url]

Run Sentry issue repair workflow for this project only.

Input: $ARGUMENTS

Goal:

1. Use provided Sentry issue id or URL. If none provided, choose the highest-impact unresolved issue using frequency, affected users, recency, and production impact.
2. Create/switch to git branch named exactly after the Sentry short issue id.
3. Investigate root cause, implement fix, and add/update tests.
4. Open PR and watch CI until green.

Rules:

• Protect local work. Start with git status --short. If uncommitted changes exist, stop and ask before branching.
• Never expose secrets. Do not print tokens, .env, Sentry auth, DB URLs, or PII.
• Use the Sentry CLI (sentry) first. Prefer stored OAuth login over env build tokens; if SENTRY_AUTH_TOKEN is invalid or too narrow, run CLI commands as env -u SENTRY_AUTH_TOKEN sentry ... unless SENTRY_FORCE_ENV_TOKEN=1 is intentionally set.
• Never print raw Sentry JSON that may contain PII. Redact emails, user IDs when summarizing. Keep secrets out of output.
• For Laravel ecosystem changes, use application-info and search-docs before code changes.
• Activate/read relevant project skills when touched: Pest tests, Inertia React, Wayfinder, Tailwind, Fortify, Pennant.
• Every code change needs programmatic verification. Add or update a focused Pest/test when feasible. Run minimum affected tests. Run vendor/bin/pint --dirty --format agent after PHP edits.
• Prefer small surgical fix. No dependency changes without approval.

Workflow:

1. Identify issue:
   • Confirm auth and org/project access with sentry auth status, sentry org list --json, and sentry project list <org> --json when needed.
   • If $ARGUMENTS is a Sentry URL, extract /issues/<numeric-id>/ or the visible short issue id, then fetch it with sentry issue view <issue> --json --fields id,shortId,title,culprit,permalink,level,status,substatus,count,userCount,firstSeen,lastSeen,project,metadata,priority,platform,isUnhandled.
   • If $ARGUMENTS is a bare issue id or short id, fetch it with sentry issue view <issue> --json --fields id,shortId,title,culprit,permalink,level,status,substatus,count,userCount,firstSeen,lastSeen,project,metadata,priority,platform,isUnhandled.
   • If no args, list unresolved production issues with both frequency and user sorting, then compare top results:
     • sentry issue list <org>/<project> --query 'is:unresolved environment:production' --sort freq --limit 25 --json --fields id,shortId,title,culprit,count,userCount,lastSeen,permalink,priority,metadata,project
     • sentry issue list <org>/<project> --query 'is:unresolved environment:production' --sort user --limit 25 --json --fields id,shortId,title,culprit,count,userCount,lastSeen,permalink,priority,metadata,project
   • Pick best impact score: high event count, high user count, recent lastSeen, production environment, clear actionable stack.
   • Record chosen short issue id and Sentry URL in notes.
2. Branch:
   • Derive branch name from Sentry short issue id only, e.g. WHISPER-MONEY-123.
   • Run git switch -c <issue-id>; if branch exists, git switch <issue-id>.
3. Investigate:
   • Fetch latest issue details and spans with sentry issue view <issue> --spans all --json.
   • Fetch recent events with sentry issue events <issue> --limit 10 --full --json.
   • Extract stack trace, breadcrumbs, environment, release, tags, URLs/routes, affected users count, trace/span data, and suspect queries. Redact PII in notes.
   • For event details if needed, use sentry event view <event-id> --json or sentry api <endpoint> --json.
   • Reproduce locally using tests or focused command. Inspect app logs/browser logs if relevant.
   • If root cause not obvious after issue/event data, run Seer with sentry issue explain <issue> --json and/or sentry issue plan <issue> --json.
4. Fix:
   • Read nearby code and conventions first.
   • Implement minimal fix.
   • Add regression test covering Sentry failure path.
5. Verify:
   • Run targeted test command, e.g. php artisan test --compact --filter=<test-or-class>.
   • Run lint/format commands required by touched files.
   • If failures occur, fix and rerun until pass.
6. PR:
   • Commit changes with concise conventional commit.
   • Push branch.
   • Create PR with gh pr create, including Sentry issue link, root cause, fix summary, and verification commands.
   • Get PR number from gh pr view --json number --jq .number if needed.
   • Watch CI every 10 seconds with gh pr checks <number> --watch --fail-fast --interval 10.
   • If CI fails, inspect logs, fix, commit/push, and watch again until green.

Output when done:

• Issue id + Sentry URL
• Branch name
• Root cause
• Fix summary
• Tests/commands run
• PR URL
• CI status