Diff Analysis

# Git Diff Patterns

## Baseline Establishment

Define comparison scope in git repositories:

```bash
# Show latest commit for context
git log --oneline -1 HEAD

# Find common ancestor between branches
git merge-base HEAD main

# Show summary of changes between baseline and HEAD
git diff --stat <baseline>..HEAD | tail -1

# Count changed files
git diff --name-only <baseline>..HEAD | wc -l
```

## Change Type Isolation

Use `--diff-filter` to focus on specific change categories:

```bash
git diff --name-only --diff-filter=A <baseline>  # Additions
git diff --name-only --diff-filter=M <baseline>  # Modifications
git diff --name-only --diff-filter=D <baseline>  # Deletions
git diff --name-only --diff-filter=R <baseline>  # Renames
```

## Integration with Sanctum

Before running diff analysis on git repositories, use `sanctum:git-workspace-review` to gather repository context:

- Repository confirmation (pwd, branch)
- Status overview (staged vs unstaged)
- Diff statistics
- Diff details

Then proceed with imbue-specific semantic analysis and risk assessment.

## Usage Pattern

1. **Sanctum First**: Use `sanctum:git-workspace-review` to gather raw git data
2. **Imbue Second**: Apply semantic categorization and risk assessment to findings
3. **Evidence**: Use `imbue:proof-of-work` to capture analysis artifacts
4. **Output**: Format with `imbue:structured-output` for downstream consumption


---
name: risk-assessment-framework
description: Framework for evaluating change risk and impact, reusable across review workflows
parent_skill: imbue:diff-analysis
category: risk-analysis
tags: [risk, impact, assessment, testing, quality]
reusable_by: [pensive:rust-review, pensive:api-review, pensive:architecture-review, pensive:bug-review]
estimated_tokens: 400
---

# Risk Assessment Framework

## Risk Indicators

Evaluate each change category for potential impact across these dimensions:

### Breaking Changes
- Public API modifications (function signatures, return types)
- Schema changes (database, data structures, serialization formats)
- Contract alterations (protocols, interfaces, message formats)
- Dependency version changes with incompatible APIs

### Security-Sensitive
- Authentication mechanisms or credential handling
- Authorization logic or permission checks
- Cryptography usage (encryption, hashing, signing)
- Input validation or sanitization
- Network communication or protocol handling

### Data Integrity
- Database operations (writes, updates, migrations)
- State management logic
- Persistence logic or serialization
- Transaction handling
- Data validation or constraints

### External Dependencies
- Third-party service integrations
- Library updates or version bumps
- API client changes
- Infrastructure dependencies (databases, queues, caches)

### Performance-Critical
- Hot paths or frequently-executed code
- Caching mechanisms
- Resource allocation (memory, file handles, connections)
- Algorithmic changes in core operations

## Risk Levels

Classify overall risk based on indicators:

- **Low**: Internal refactors, documentation updates, test additions with no production code changes
- **Medium**: Feature additions with detailed tests, non-breaking API extensions, configuration changes with rollback plans
- **High**: Breaking changes requiring coordination, security modifications, schema migrations, changes to critical paths

## Test Coverage Flagging

Identify changes requiring additional testing attention:

- **Untested Changes**: New code or modifications without corresponding test updates
- **Test-Only Changes**: Test updates without production code (potential false positives)
- **Coverage Gaps**: High-risk changes with insufficient test scenarios
- **Integration Points**: Changes affecting external system