← All posts
4 min

From prompt to pushed commit without leaving the session

The /push command stages your changes, writes a commit message from the real diff, and pushes, with a confirmation you actually control.

There's a small, constant tax in AI-assisted development: the agent makes an edit, and then you leave to commit it. Different window, git add, stare at the diff, invent a message, push. Individually trivial. Twenty times a day, it's the thing that breaks flow.

/push collapses it into one step.

What it does

› /push
✓ Staged: auth.ts
  Commit: fix: extend JWT expiry from 30s to 30m
  Push to origin/main? (Y/n) Y
✓ Pushed · abc1f3a → github.com/you/project

Four things happen: changed files are staged, the actual diff is read, a conventional-commits message is drafted from what the diff really does, and, after you confirm, it pushes.

Why the message is usually decent

Most AI commit messages are bad because they're generated from the conversation. The chat said "fix the JWT bug," so the message becomes "fix JWT bug", which restates your prompt rather than describing the change.

Vexi drafts from the diff instead. Seeing expiresIn: 30 become expiresIn: "30m" produces "extend JWT expiry from 30s to 30m": the specific, factual thing that changed. That's a message that means something in git log six months from now, when the conversation is long forgotten.

The confirmation stays

Push is the point where a local mistake becomes a public one. So the (Y/n) prompt isn't decoration and there's no flag to permanently disable it.

The prompt shows the branch you're about to push to. That's the detail that catches the genuinely expensive mistake: realising you're on main when you meant to be on a feature branch, before you push rather than after.

Use it for small, complete changes

Honest guidance on where this fits: /push is at its best for focused changes: a bug fix, a dependency bump, a doc correction. Something you'd be comfortable describing in one line.

It's a poor fit for a large multi-part change that deserves several logical commits. It stages what's changed and makes one commit; it won't split your work into a clean sequence. For anything substantial, commit deliberately by hand.

Treat it as the fast path for small things, not a replacement for thinking about your history.

The safety net underneath

Worth knowing that /push isn't the only thing standing between you and a bad edit. Every file change Vexi makes is snapshotted first, independently of git:

vexi undo      # revert the last AI edit
vexi redo      # reapply it
vexi history   # see what changed, when

This works on uncommitted changes and doesn't touch your git state, so you can undo an AI edit without disturbing a stash or a half-built commit. Between per-edit snapshots and a confirmation before push, there are two independent points to catch a mistake.

Try Vexi

Free, open source, MIT licensed. One command.

$npm install -g vexi-cli