The workflow
Six steps, the same every time. Two of them are gates only a person opens: landing on dev, unless you opted a task into self-landing, and promoting to main, always.
01 Say it
Hold space and talk, or switch on always listening and say "VIDA". You get a short spoken answer, and anything worth reading goes on screen.
- With always listening on, saying her name sends the words you were already in the middle of, too: the last sixteen are kept in a rolling buffer, so a half-finished sentence arrives whole.
- Spoken replies are held to about three sentences, with the answer first. Lists, ids, code and numbers go in an aside on the HUD instead of being read out.
- You can always type instead. The HUD runs in desktop Chrome on your own machine.
- You say
- "VIDA, pick up the three export bugs in Linear."
- Under the hood
push to talk, or always listening
02 From the tracker
A task can start from an issue key. The issue becomes the brief, moves to in progress when the task starts, and to done when its work lands.
- Linear is connected from the HUD's apps tab with a consent screen: read first, and writing as a separate, second grant. VIDA creates and edits issues, projects and milestones, and never deletes or archives anything there.
- Ideas worth keeping are filed as issues under the project they belong to, so the tracker stays the one backlog.
- An autopilot can work through a project's open issues by itself, screening out anything security-sensitive, destructive, too big or needing a decision.
- You say
- "Start LED-142, LED-147 and LED-151."
- Under the hood
start_task issue: "LED-142"
03 Parallel tasks
Each task is a Claude Code session in a git worktree and branch of its own, so several run side by side without touching each other or your checkout.
- A task keeps running if VIDA restarts, and the HUD shows a live feed of each one: the files it reads, the edits it makes, what it says.
- Before it says it is done, a task commits on its own branch and rebases onto the current dev branch, so what you review sits on top of what is there now. A rebase that conflicts is rolled back and the task is marked as needing one.
- Every task ends with a short patch note, what changed, why and what a person will notice, which is copied into the merge commit that lands it.
- You say
- "How are those going?"
- Under the hood
list_tasks, task_status
04 Review
Finished is not merged. Done-and-unmerged work waits under "needs review", longest-waiting first, until somebody reads it.
- The review tab opens every file a task touched, whole, with the lines it wrote lit up, and steps hunk by hunk across files. It works on a task that is still running.
- VIDA reads the same view you do, so what she describes and what is on screen come from one place.
- There is no approve button on the review tab. Landing work is something you say.
- You say
- "Walk me through the retry change."
- Under the hood
review_task, review_file
05 Land on dev
Everything lands on a dev branch, as one --no-ff merge per task. Merge as it stands, or put it through a merge queue that rebases, builds and tests it first.
- The merge queue takes one task at a time under a lock, builds and tests it in its own worktree, and merges only if all of it is green. "Land it all" works the whole queue in the background.
- Self-landing is opt-in, per task: VIDA merges it herself only if the build and tests pass and it touched nothing security-sensitive. There is no override.
- Every landing is one commit you can take back out: a revert of the whole task, which is itself revertible.
- You say
- "Land the retry fix."
- Under the hood
merge_task, land_task, land_all
06 Promote, when you say
Main only ever receives. It moves for one reason: a person said, out loud, to promote. So main is always a commit someone looked at.
- Asking what would be promoted is a report and changes nothing. Only an explicit, confirmed call fast-forwards main to dev.
- If main has a commit dev does not, the promotion is refused rather than forced: what to do about that is a person's decision.
- Autopilot and self-landing only ever land on dev. Promoting is not something they can reach.
- You say
- "What's waiting to go to main? ... OK, promote it."
- Under the hood
git__promote confirmed: true
Running without you
Two things move work forward with nobody in the conversation, and both are asked for out loud before the fact.
- Self-landing, per task: VIDA follows the task to the end and merges it only if its build and tests pass in its own worktree and it touched no security-sensitive path. Anything else stops with the work safe on its branch and the reason recorded.
- The autopilot, per project: it reads the project's open issues, screens out anything security-sensitive, destructive, too big, needing a decision or an outside account, and works through the rest under a budget, landing only on dev. It stops itself after three landings or about twenty-five changed files so that what landed can be read in one sitting.
When you come back after a few hours, VIDA tells you what happened while you were away: what failed or is held, what is waiting on you, what landed and what came back.