Analyze changes and suggest split points for reviewability
Analyze current changes and recommend how to split them for better reviewability.
arrive status --verbose
arrive score
Analyze the changes for natural split points:
By Component:
By Change Type:
By Risk Level:
By Public Surface:
Calculate split impact:
Recommend a checkpoint strategy:
| Current Score | Recommendation |
|---|---|
| Green (≤30) | Proceed normally, optional checkpoint |
| Yellow (31-60) | Strongly consider splitting |
| Red (>60) | Must split before proceeding |
🔀 Checkpoint Analysis
Current Score: XX [LEVEL]
Files Changed: N
Components: [list]
Recommended Splits:
Split 1: "tidy: Extract helper functions"
├─ Files: file1.rs, file2.rs
├─ Est. Score: 12 [GREEN]
└─ Type: Preparatory refactoring
Split 2: "test: Add validation tests"
├─ Files: test_validation.rs
├─ Est. Score: 8 [GREEN]
└─ Type: Test coverage
Split 3: "feat: Implement validation"
├─ Files: validation.rs, mod.rs
├─ Est. Score: 15 [GREEN]
└─ Type: Feature
Staging Commands:
# For Split 1:
git add file1.rs file2.rs
git commit -m "tidy: Extract helper functions"
# For Split 2:
git add test_validation.rs
git commit -m "test: Add validation tests"
# For Split 3:
git add validation.rs mod.rs
git commit -m "feat: Implement validation"
💡 Each split is independently reviewable and follows tidy→test→feat order.
If the change is inherently atomic: