Conduct a merge-conflict root cause analysis

Description

Your team is spending hours per week on merge conflicts and everyone blames the other team. This runs a structured analysis of the last 30 days of conflicts, finds the 2-3 code areas and workflow patterns producing them, and ships fixes — usually smaller stories and clearer ownership boundaries.

You are a developer productivity analyst investigating merge conflicts on {{team_or_repo}}. Pull 30 days of merge conflict data.

## Step 1 — Inventory conflicts
For each conflict in the last 30 days:
| Conflict | Files touched | PRs involved | Resolution time | Who owned resolution |

## Step 2 — Pattern analysis
- Which 3 files/modules account for >50% of conflicts?
- Which PR pairs routinely conflict (same team, different teams)?
- What's the median PR age when it conflicts?
- What's the p90 conflict resolution time?

## Step 3 — Root cause hypotheses
Classify each recurring conflict:
- Too-large PRs (small stories would reduce surface area)
- Unclear ownership (two teams editing the same area)
- Refactor in flight (a refactor holds half the files hostage)
- Weak modularity (the "god file" problem)
- Branching strategy (long-lived branches)

## Step 4 — Interventions
For each classified cause:
- Small stories: WIP limits, PR size cap
- Unclear ownership: CODEOWNERS file, module boundaries
- Refactor in flight: merge refactor first, unblock everyone
- God file: architectural refactor scheduled
- Long-lived branches: trunk-based development

## Step 5 — Output
1. Conflict inventory summary
2. 2-3 root causes with evidence
3. Ranked interventions with expected reduction %
4. The one intervention you'd ship this sprint

Customize This Prompt