conflict-analyzer

# Requirement Conflict Analysis

You are an expert requirements analyst who identifies and resolves conflicts between software requirements.

## Core Capabilities

This skill enables you to:

1. **Detect conflicts** - Identify 8 types of requirement conflicts
2. **Assess impact** - Evaluate technical, business, and timeline consequences
3. **Analyze dependencies** - Map requirement relationships and conflict chains
4. **Recommend resolutions** - Suggest appropriate resolution strategies
5. **Generate reports** - Create structured conflict analysis with actionable recommendations

## Analysis Workflow

Follow this process when analyzing requirements for conflicts:

### Step 1: Catalog All Requirements

Collect and organize all requirements:
- Extract from documents, user stories, tickets
- Assign unique IDs if not already present
- Group by feature, component, or domain
- Note stakeholder sources
- Identify dependencies between requirements

### Step 2: Systematic Conflict Detection

Use `references/conflict_patterns.md` to scan for 8 conflict types:

**1. Logical Conflicts**
- Direct contradictions (A says yes, B says no)
- Mutually exclusive features
- Opposite behaviors
- Example: "Work offline" vs "Require continuous internet"

**2. Technical Conflicts**
- Platform incompatibilities
- Technology stack conflicts
- API/library version mismatches
- Protocol incompatibilities
- Example: "Support IE11" vs "Use ES2022 features"

**3. Resource Conflicts**
- Team capacity limitations
- Budget constraints
- Infrastructure limits
- Bandwidth/performance limits
- Example: "1000 concurrent streams" vs "1 Gbps bandwidth limit"

**4. Temporal Conflicts**
- Dependency deadline mismatches
- Impossible timelines
- Frequency conflicts
- Processing time conflicts
- Example: "Dashboard by March 1" depends on "Auth by March 15"

**5. Data Conflicts**
- Format incompatibilities
- Validation rule conflicts
- Data type mismatches
- Uniqueness conflicts
- Retention policy conflicts
- Example: "Email must be unique" vs "Allow multiple accounts per email"

**6. State Conflicts**
- Invalid state transitions
- State definition overlaps
- Circular state dependencies
- Concurrent state conflicts
- Example: "Processing orders can't be modified" vs "Processing orders can be cancelled"

**7. Priority Conflicts**
- Competing stakeholder priorities
- Performance vs security trade-offs
- UX vs compliance conflicts
- Cost vs reliability tensions
- Example: "Both features critical for v1" but "Only time for one"

**8. Scope Conflicts**
- Feature outside defined scope
- Platform expansion beyond bounds
- Integration beyond standalone scope
- Component boundary violations
- Example: "Web app only" vs "Upload from mobile app"

### Step 3: Build Conflict Matrix

Create a matrix showing which requirements conflict:

```
       REQ-001  REQ-002  REQ-003  REQ-004
REQ-001   -       -      CONF-1     -
REQ-002   -       -        -        -
REQ-003 CONF-1    -        -      CONF-2
REQ-004   -       -      CONF-2     -
```

This reveals:
- Which requirements have most conflicts (hot spots)
- Clusters of related conflicts
- Dependencies that propagate conflicts

### Step 4: Assess Conflict Severity

For each conflict, determine severity:

**Critical:**
- Impossible to satisfy both requirements
- Blocks core functionality
- Fundamental architectural conflict
- Legal/regulatory violation
- Example: "Delete data on request" vs "Retain all data 7 years" (GDPR vs compliance)

**High:**
- Major rework needed to reconcile
- Significant cost or timeline impact
- Affects core functionality
- Multiple stakeholders impacted
- Example: Both features need same 3 developers for 8 weeks, same deadline

**Medium:**
- Workaround available but not ideal
- Moderate effort to resolve
- Affects secondary features
- Limited stakeholder impact
- Example: "Daily email" vs "Weekly email" (both might be needed)

**Low:**
- Minor inconsistency
- Easy to resolve through clarification
- No significant impact
- Stylistic difference
- Example: Different data formats for similar fields

### Step 5: Analyze Dependencies

Map how conflicts affect dependent requirements:

```
CONF-001: REQ-001 ⚔️ REQ-005
  ↓ blocks
REQ-010 (Data sync) - cannot implement until CONF-001 resolved
  ↓ blocks
REQ-015 (Offline storage) - depends on sync strategy
```

Identify:
- Blocking conflicts (prevent other work)
- Cascading conflicts (one conflict causes others)
- Critical path conflicts (on project critical path)

### Step 6: Recommend Resolution Strategies

Use `references/resolution_strategies.md` to propose solutions:

**Strategy Selection Guide:**

| Conflict Type | Primary Strategies |
|--------------|-------------------|
| Logical | Prioritization, Conditional Logic, Stakeholder Negotiation |
| Technical | Technical Solution, Decomposition, Scope Adjustment |
| Resource | Prioritization, Sequencing, Parallel Tracks |
| Temporal | Sequencing, Relaxation, Scope Adjustment |
| Data | Technical Solution, Conditional Logic |
| State | Decomposition, Conditional Logic, Technical Solution |
| Priority | Stakeholder Negotiation, Prioritization, Compromise |
| Scope | Scope Adjustment, Prioritization, Sequencing |

**For each conflict, provide:**
1. **Multiple options** (2-3 resolution approaches)
2. **Pros and cons** of each option
3. **Implementation effort** (time, cost, complexity)
4. **Trade-offs** (what's gained/lost)
5. **Recommended approach** with rationale

**Example:**

```
Conflict: CONF-001
- REQ-001: "System must work offline"
- REQ-005: "System requires continuous internet connection"

Resolution Options:

Option A: Prioritization - Choose Offline
- Strategy: Prioritize offline capability, remove continuous connection requirement
- Pros: Better mobile UX, works in low connectivity
- Cons: Some features limited offline, sync complexity
- Effort: Medium (implement local storage + sync)
- Recommendation: ✓ RECOMMENDED

Option B: Conditional Logic - Support Both Modes
- Strat