sprint-plan

You are analyzing a Jira ticket against the current repository to help me prepare for sprint planning. Your job is to surface potential issues I would otherwise discover mid-sprint.

Ticket to analyze: $ARGUMENTS

If no ticket ID was provided above, stop and ask me for one (e.g., PROJ-1234) before doing anything else.

Work through these phases in order. Do not skip phases.

Phase 1: Fetch the ticket. Use the Atlassian MCP to retrieve the ticket. Read the title, description, acceptance criteria, all comments, and any linked tickets. Do not summarize the ticket back to me; I have already read it.

Phase 2: Ambiguity detection. Before touching any code, identify gaps in the ticket itself. List specific ambiguities a reasonable engineer could interpret two different ways. Examples of useful findings:

• "Ticket says 'notify users' but does not specify channel (email, in-app, push), urgency, or what event triggers it."
• "Acceptance criteria mentions 'handle failures gracefully' but does not define what graceful means here. Retry? Dead-letter? User-visible error?"
• "Description says 'update the user schema' but does not say whether existing rows need backfilling."

Skip generic findings like "could be more detailed." Be concrete or omit the item.

Phase 3: Code scoping. Based on the ticket text, find the files, functions, and services in the current repo most likely to be affected. Use Glob, Grep, and Read aggressively. Trace from each entry point the ticket mentions to its direct callers and shared dependencies. List the files you are reasoning about.

If you cannot find code related to the ticket (wrong repo, ticket too vague, ticket is purely about infra/config), say so explicitly and stop. Do not fabricate analysis to fill space.

Phase 4: Risk analysis. For each affected code area, check against this rubric and report only findings with actual evidence in the code:

• Concurrency and race conditions (shared state, locks, async ordering)
• Data migrations or schema changes (pending migrations, in-flight schema work)
• API contract changes (breaking changes for callers, versioning)
• Performance implications (added latency, N+1 queries, hot paths)
• Backward compatibility (deprecated paths, feature flags, rollout state)
• Test coverage gaps (untested branches the change touches)
• Error handling (unhandled cases, swallowed exceptions, timeout behavior)
• Hidden coupling (ticket mentions service A but the change forces a change in service B)

Phase 5: Recent context check. Run git log --oneline -20 on each affected file. Flag any file with heavy recent activity (likely conflict zone with in-flight work) or pending migrations/refactors visible in commit history.

Phase 6: Output. Produce a single Markdown report with these sections, in this order:

## Summary
[One sentence. What this ticket actually changes, in your understanding.]

## Acceptance-Criteria Gaps
- [Specific, actionable. No generic items.]

## Technical Risks
### [High|Medium|Low] — [Risk title]
**Evidence:** `path/to/file.ext:142-168` — [What the code does and why this is a risk.]
**Why it matters:** [Concrete consequence if missed.]

[Repeat per risk. If no risks found, write "No technical risks identified from code analysis." Do not pad.]

## Questions for Refinement
1. [Question to raise in the planning meeting.]
2. [...]
[Three to five questions. Each must be answerable by a human, not by reading more code.]

## Suggested Next Steps
- [Concrete actions before sprint commit. E.g., "Sync with @Priya on the payments refactor before estimating this." Not vague advice like "consider edge cases."]

Hard rules.

• Never invent findings. If the code does not support a risk, do not list it. A short, accurate report beats a long, padded one.
• Every technical risk must cite specific files and line ranges. "Concurrency risk in payment handler" is rejected. "Race condition risk in PaymentService.processRefund (src/services/payment.ts:142-168), which reads and writes refund_status without a lock and is called from both the webhook handler and the admin retry endpoint" is accepted.
• Do not repeat the ticket back to me.
• Do not estimate story points or complexity.
• Do not propose to post anything to Jira. Read-only analysis.
• Keep the report scannable. I am reading this in 90 seconds before standup.

Begin with Phase 1.