Here's how the terminal-only flow would work, following patterns similar to git add -p and git rebase -i:[1][2]
$ git add .
$ omni --segmentAnalyzing changes... Done!
Found 10 modified files. Suggested 3 commits.
┌─────────────────────────────────────────────────────────┐
│ Commit Segmentation (3 commits from 10 files) │
└─────────────────────────────────────────────────────────┘
1. [✓] refactor: authentication system (4 files)
2. [ ] feat: API v2 endpoints (3 files)
3. [ ] test: auth coverage and docs (3 files)
Commands: [n]ext [p]rev [e]dit [s]plit [m]erge [v]iew [a]ccept [q]uit
Current: 1/3
>
> e # Edit commit 1
┌─────────────────────────────────────────────────────────┐
│ Edit Commit 1/3 │
└─────────────────────────────────────────────────────────┘
Title: refactor: authentication system
Message (press 'i' to edit, Esc to return):
Move JWT logic to dedicated auth service
- Extract token generation and validation to AuthService
- Add refresh token rotation mechanism
- Implement proper error handling for expired tokens
- Update security headers and CORS configuration
Files (4):
• src/services/AuthService.ts
• src/middleware/authenticate.ts
• src/utils/jwt.ts
• src/config/security.ts
[i] Edit [f] Move files [Enter] Save [Esc] Cancel
> m # Enter merge mode
┌─────────────────────────────────────────────────────────┐
│ Merge Mode (Space to select, Enter to merge) │
└─────────────────────────────────────────────────────────┘
[✓] 1. refactor: authentication system (4 files)
[✓] 2. feat: API v2 endpoints (3 files)
[ ] 3. test: auth coverage and docs (3 files)
Selected: 2 commits (7 files total)
Press Enter to merge, Esc to cancel
>
> s # Split commit 2
┌─────────────────────────────────────────────────────────┐
│ Split: feat: API v2 endpoints (3 files) │
└─────────────────────────────────────────────────────────┘
Select files for FIRST commit (Space to toggle, Enter when done):
[✓] src/api/routes/users.ts
[✓] src/api/routes/profile.ts
[ ] src/middleware/apiVersion.ts
Remaining files will go to second commit.
>
> v # View all commits summary
┌─────────────────────────────────────────────────────────┐
│ Commit Summary │
└─────────────────────────────────────────────────────────┘
Commit 1: refactor: authentication system
4 files | 156 additions, 89 deletions
Commit 2: feat: API v2 endpoints
3 files | 234 additions, 12 deletions
Commit 3: test: auth coverage and docs
3 files | 445 additions, 0 deletions
Total: 835 additions, 101 deletions across 10 files
[Enter] Return [a] Accept all [q] Quit
> a # Accept and create commits
Creating commits...
✓ Created: refactor: authentication system (8a3f2d1)
✓ Created: feat: API v2 endpoints (9bc4e8a)
✓ Created: test: auth coverage and docs (7f1a5c2)
Done! 3 commits created.
For scriptability and simpler terminals, a more traditional prompt-based approach:
$ omni --segment
Commit 1/3: refactor: authentication system (4 files)
Edit title? [y/N]: n
Edit message? [y/N]: y
<opens $EDITOR>
Include in final commits? [Y/n]: y
Commit 2/3: feat: API v2 endpoints (3 files)
Edit title? [y/N]: n
Edit message? [y/N]: n
Include in final commits? [Y/n]: y
Commit 3/3: test: auth coverage and docs (3 files)
Edit title? [y/N]: n
Edit message? [y/N]: n
Include in final commits? [Y/n]: y
Summary:
3 commits will be created
10 files across all commits
Proceed? [Y/n]: y
✓ Done!Single-character commands - Like git add -p with y/n/s/q responses, keeping interactions fast[2]
Editor integration - Opening $EDITOR for longer text like commit messages, following Unix conventions[3]
Visual selection states - Using [✓] and [ ] for checkbox states, > for current position
Escape hatches - Always providing q to quit, Esc to cancel, consistent with vim/less patterns[6]
Status indicators - Progress like "1/3", file counts, and what's currently selected
Command bar - Persistent reminder of available commands at bottom, similar to nano or htop[7]
The TUI approach uses libraries like ncurses or modern alternatives (bubbletea for Go, blessed for Node) to handle cursor positioning and screen updates without full redraws. The simpler prompt-based flow works in any terminal and remains scriptable.[8][5][6][3]
Here's what a pure terminal/CLI flow would look like for
omni --segment, inspired by tools likegit add --interactiveandgit add --patch:[1][2]Terminal-Based Flow
Initial Command
➜ git add . ➜ omni --segment Analyzing changes... Found 12 files changed, 482 insertions(+), 103 deletions(-) Proposing 4 logical commit segments...Main Interactive Menu
Editing a Segment (Press
1)Editing Message (Press
e)Merging Segments (Press
mfrom main menu)Splitting a Segment (Press
swhile viewing segment)Final Confirmation
Execution
Key Terminal UX Patterns Used
Single-letter commands - Like
git add -p(y/n/s/q), quick actions without Enter[2]Numbered menus - Like
git add -i, select items by number[1][2]Toggle selection - Spacebar to select multiple items (common in terminal file managers)
Visual indicators - Box drawing characters (
━│└) and symbols ([x],✓,-) for clarity[3]Editor integration - Drop into
$EDITORfor multiline text editing[1]Hierarchical navigation - Back/forward navigation through menus with
<orEscConfirmation prompts - Standard
[Y/n]for destructive actionsThis approach feels native to terminal users because it follows established patterns from tools like
git add -i,apt,npm init, and other interactive CLI tools.[2][1]1
2
3
4
5
6
7
8
9
10