Aviator CLI (av) for Stacked PRs

You are helping the user work with stacked pull requests using Aviator's av CLI tool.

IMPORTANT: NEVER modify the av/av.db file inside the git dir (found via git rev-parse --git-common-dir ) directly. This JSON file is managed by av commands. You may read it to understand stack structure, but always use av CLI commands to make changes.

First Steps (ALWAYS DO THIS)

When working with av, ALWAYS read av/av.db from the git common dir first to understand the branch structure. This JSON file is the source of truth.

cat "$(git rev-parse --git-common-dir)/av/av.db"

Note: Use cat , not the Read tool - the .db extension causes Read to incorrectly treat it as binary.

Tip: Use git branch --show-current to identify the current branch, then look up that branch's entry in av.db for its stack context and PR info.

Do NOT use av tree to understand structure - its visual output is misleading. Only use av.db.

Critical Rules

NEVER use git commit or git push directly. Always use av commit and av sync --push=yes --prune=yes . Using git directly skips restacking and breaks the stack.

NEVER pass --no-edit to av commit --amend . The flag doesn't exist — no-edit is already the default behavior. Just use av commit --amend .

Detection & Setup

Check if av is initialized: test -f "$(git rev-parse --git-common-dir)/av/av.db"

• If the file exists, the repo is av-initialized. Use av commands for branch/PR operations.

• If the file does NOT exist, ask the user if they want to initialize with av init .

• For detailed command reference, see reference.md.

• For workflow examples, see examples.md.

• Run av <command> --help or man av-<command> for up-to-date command documentation.

Non-Interactive Mode (Agents & Automation)

Many av commands default to interactive TUI prompts that agents cannot use. Always use the non-interactive flags listed below.

Critical syntax note: Flag values require = (equals sign), not a space. --push=yes works; --push yes does NOT.

Command Interactive behavior Non-interactive flags

av sync

Prompts for push and prune confirmation --push=yes (or =no ), --prune=yes (or =no )

av pr

Opens editor for title/body --title "..." --body "..."

av switch (no args) Opens branch picker av switch <branch-name>

av adopt (no args) Interactive branch selection av adopt --parent <parent> on the target branch

av split-commit

Interactive chunk picker No non-interactive mode. Use git reset

• manual staging instead

av reorder

Opens editor for rebase plan No non-interactive mode. Use av reparent

• manual operations instead

Recommended agent workflow:

av commit -A -m "message" av pr --title "Title" --body "Body" av sync --push=yes --prune=yes

Understanding Stack Structure

Read "$(git rev-parse --git-common-dir)/av/av.db" to understand branch relationships. Format:

{ "branches": { "feature-api": { "name": "feature-api", "parent": { "name": "master", "trunk": true }, "pullRequest": { "number": 123, "permalink": "https://github.com/org/repo/pull/123" // USE THIS URL } }, "feature-ui": { "name": "feature-ui", "parent": { "name": "feature-api", "head": "abc123" } } } }

Key fields:

• parent.trunk: true → branch is directly off main/master (not stacked)

• parent.name

• parent.head → branch is stacked on another branch

• pullRequest.permalink → full PR URL (always use this when displaying PR info, not just the number)

• excludeFromSyncAll: true → branch excluded from av sync --all

Reading the structure: Each branch's parent.name tells you what it's based on. Build the tree by following parent relationships. Branches with trunk: true are all independent roots.

Core Concepts

What is a Stack?

A stack is a chain of dependent branches where each branch builds on the previous one:

main └── feature-auth (PR #1: adds auth) └── feature-login (PR #2: adds login, depends on auth) └── feature-logout (PR #3: adds logout, depends on login)

Why Use av?

• Automatic rebasing: When you update a branch mid-stack, av rebases all child branches.

• Correct PR bases: av pr automatically sets the correct base branch (parent branch, not trunk).

• Coordinated syncing: av sync fetches, rebases, and pushes all branches in one command.

How Stacked PRs Work

Each PR shows only its own diff (changes relative to its parent branch), not the cumulative diff against trunk. This makes code review focused and manageable.

Common Use Case: Full-Stack Features

The most common workflow is building features that span multiple layers:

main └── add-feature-db (DB schema/migrations) └── add-feature-service (Backend service logic) └── add-feature-api (REST/GraphQL endpoints) └── add-feature-ui (Frontend components)

Each layer gets its own focused PR. Reviewers with different expertise (DBA, backend, frontend) review the relevant parts. When the DB schema changes during review, av sync propagates updates through the entire stack automatically.

Essential Commands

Branch Management

Command Purpose

av branch <name>

Create a new branch stacked on current branch

av branch --parent <parent> <name>

Create branch with specific parent

av branch -m <new-name>

Rename current branch

av adopt --parent <parent>

Adopt current branch into the stack with given parent

av adopt --remote <branch>

Fetch and adopt a remote branch (e.g., colleague's work)

av reparent --parent <new-parent>

Move current branch to a different parent

av orphan

Remove current branch from av management

av adopt --remote is particularly useful for pulling in a colleague's branch (or any remote branch not yet tracked locally) and automatically setting up the correct stack relationships. It fetches the branch, detects its parent chain, and integrates it into your local av state — much more reliable than manually checking out and adopting.

Committing

Command Purpose

av commit -m "message"

Commit and auto-restack children

av commit -a -m "message"

Stage modified files and commit

av commit -A -m "message"

Stage ALL files (including untracked) and commit

git add <files> && av commit -m "msg"

Stage specific files, then commit

av commit --amend

Amend last commit, then restack children

av split-commit

Interactively split current commit (no non-interactive mode)

av squash

Squash all branch commits into one

av commit vs git commit — key differences:

• --amend reuses the existing message by default. There is no --no-edit flag — it is the default behavior.

• --edit explicitly opens the editor when amending (the opposite default from git).

• -a behaves the same as git's -a (stages modified/deleted tracked files only).

• -A / --all-changes is av-specific: stages ALL files including untracked (git has no equivalent single flag).

Selective staging: -a and -A stage everything (tracked or all). To commit only specific files, stage them first with git add <files> , then run av commit without -a /-A . This works for both new commits and amends.

Common mistakes:

• git commit -m "message" → use av commit -m "message" instead

• git push → use av sync --push=yes --prune=yes instead

• av commit --amend --no-edit → just av commit --amend (no-edit is the default, the flag doesn't exist)

Pull Requests

Command Purpose

av pr --title "Title" --body "Description"

Create/update PR for current branch

av pr --all

Create/update PRs for entire stack

av pr --all --current

Create/update PRs up to current branch

av pr --draft

Create PR as draft

av pr --edit

Edit existing PR title/body

Note: Always pass --title and --body flags explicitly to avoid interactive prompts.

Synchronization

Command Purpose

av sync

Fetch, restack current stack, push

av sync --rebase-to-trunk

Rebase stack root onto latest trunk

av sync --all --rebase-to-trunk

Rebase all stacks onto latest trunk

av restack

Rebase children locally (no push)

av fetch

Fetch latest state from GitHub

Non-interactive mode: av sync prompts for confirmation by default. Use explicit flags (note the = syntax — a space does not work):

av sync --push=yes --prune=yes # Sync current stack av sync --all --push=no --prune=yes # Sync all stacks (use after PRs are merged, ask user before pushing)

Both --push and --prune must always be specified — omitting either triggers a TUI prompt. Options: yes , no , or ask (default). --prune=yes is safe in most cases — it only deletes local branches whose PRs have already been merged. Use --prune=no if you need to keep merged branches around locally (e.g., for reference or if other worktrees have them checked out).

Timeout: av sync performs a fetch + rebase + push cycle and can take 15-30+ seconds. Use a timeout of at least 60 seconds for any av sync command.

Navigation

Command Purpose

av switch

Interactive branch switcher

av switch <branch>

Switch to specific branch

av next

Move to child branch

av prev

Move to parent branch

av next --last

Jump to end of stack

av prev --first

Jump to stack root

Conflict Resolution

When rebasing causes conflicts:

• Resolve conflicts in your editor

• Stage resolved files with git add

• Continue with av sync --continue or av restack --continue

Or abort with --abort , or skip the problematic commit with --skip .

Using av for All Workflows

Once a repo is av-initialized, use av for everything - even single PRs. av works great for non-stacked workflows too and keeps things consistent.

Scenario Command

Create a branch av branch <name>

Commit changes av commit -m "message"

Create/update a PR av pr --title "Title" --body "Description"

Create PRs for part of a stack av pr --all --current

Create PRs for entire stack av pr --all

Sync after making changes av sync --push=yes --prune=yes

After a PR is merged av sync --all --push=no --prune=yes

Adopt a remote branch av adopt --remote origin/<branch>

Switch branches av switch <branch>

View diff against parent av diff

Important Behaviors

• Use av commands consistently - they work for single PRs and stacks alike.

• av commit auto-restacks child branches when you have them.

• Let av pr set the base - don't manually specify base branches.

• After PR merges, run av sync --all --push=no --prune=yes to clean up and rebase remaining branches. Ask the user before pushing all stacks.

• Don't mention stacks in commits/PRs - never reference stack position, parent branches, or stack relationships in commit messages, PR titles, or PR bodies. The av tooling handles this metadata automatically.

• Always show full PR URLs - when displaying PR info, use the permalink field from av.db. Never show just "PR #123" - always show the full clickable URL like https://github.com/org/repo/pull/123 .