Board Autonomy

Turn the task board into a self-driving delivery pipeline. With one explicit consent, the agent chains through ready tasks, isolates every task on its own git branch, opens a pull request when the task is done, and keeps GitHub issues in sync - while you keep the final word on every merge.

Autonomy is per project, opt-in, and recorded: nothing changes until you enable it, and everything it does leaves a visible trail (branch, PR link, issue link, timeline entries, notifications).

What you get

Enabling it (consent dialog)

Open the Tasks panel (Code workbench or Project Home) and click Autonomy in the board header. A consent dialog explains exactly what the agent will be allowed to do:

• create, update and move tasks itself (to do, doing, blocked, done) with evidence;
• pick the next ready task and keep working until the queue is empty or a task blocks;
• notify you on claim, blocked, opened PR and imported issues.

Then it lets you pick each git capability individually:

• Isolated branch per task - claiming a task creates and switches to navin/task-<id>, so your current branch is never touched.
• Pull request on done - when a task reaches done, its branch is pushed and a PR is opened for your review (requires the gh CLI).
• GitHub issues sync - the agent may create issues mirroring tasks and close them when the task is done.
• Fix issues autonomously - the agent may fix a GitHub issue end to end: reproduce, fix on an isolated branch, run the tests until green, commit, then close the issue and re-sync the board. Off by default.
• Autopilot loop - a session-bound cron job processes the board continuously, one ready task per cycle, even without a chat open. Ticking it sends /board loop to the agent (which creates the cron); unticking asks the agent to remove it. Off by default.

Confirming writes your consent, with a timestamp, into the project itself:

// <project>/.navin/board/settings.json
{
  "schema_version": 1,
  "autonomy": {
    "enabled": true,
    "consented_at": "2026-08-04T23:18:52Z",
    "auto_branch": true,
    "open_pr_on_done": true,
    "sync_github_issues": false,
    "fix_issues": false,
    "autopilot_loop": false
  },
  "updated_at": "2026-08-04T23:18:52Z",
  "updated_by": "user"
}

Because the file lives under .navin/board/, the consent travels with the repository and is shared by Code and every studio. Click the toggle again to disable; a fresh enable records a new consent timestamp.

Task lifecycle under autonomy

flowchart LR
    A[board next] --> B[claim task]
    B --> C["git switch -c navin/task-id-slug"]
    C --> D[implement + validate\ntests / lint / verify]
    D -->|evidence| E[move to done]
    E --> F[commit + push branch]
    F --> G[gh pr create\nPR URL saved on task]
    G --> H{linked issue?}
    H -->|yes| I[issue closed]
    H -->|no| A
    I --> A
    D -->|stuck| J[status blocked\nwarning notification]
    J --> A

Details that make it safe and robust:

• Idempotent branching - if the task branch already exists (a resumed run), the agent switches back to it instead of creating a duplicate. A dirty but unconflicted working tree is preserved by git switch -c.
• Never on your branch - leftover changes are auto-committed only when the repo is on a navin/task-* branch. Work sitting on main or your feature branch is never swept into a task commit.
• Existing PR reused - if a PR already exists for the branch, its URL is recorded instead of opening a duplicate.
• Evidence gate still applies - done with validation=test|lint|verify still requires evidence. Autonomy does not weaken the definition of done.
• Repo state respected - mid-merge, mid-rebase, or mid-cherry-pick repositories refuse auto-branching with a clear message instead of corrupting state.
• Everything is best-effort - no gh, no remote, no network: the board keeps working and the reason is recorded as a task comment (Auto-PR skipped: ...).

GitHub issues sync

Three directions, all deduplicated by issue URL:

The Issues tab in Project Home lists the repository's issues (open / closed / all) with author, labels and comment counts, and has its own Import to board button.

Fixing an issue with the agent

Every open issue in the Issues tab has a Fix with agent button. Clicking it sends the agent a precise brief: reproduce the problem, implement the fix on an isolated task branch, run the relevant tests until they are fully green, commit, open a PR when PR-on-done is enabled, and only then close the issue on GitHub (gh issue close <n> --comment) and re-sync the board. The agent is explicitly instructed to never close an issue whose fix is not tested and committed.

The same behaviour is available autonomously (without a click) when the Fix issues autonomously consent option is ticked: the runtime context then authorizes the agent to pick up linked issues during runs and drive them to a tested, committed, closed state.

What the agent knows

When autonomy is on, every agent turn receives a Runtime Context digest, for example:

Board autonomy is ENABLED for this project (user consent recorded 2026-08-04T23:18:52Z).
During a run you were invited into, chain through ready board tasks without asking
again per task; stop and notify on blocked.
Work each claimed task on its isolated navin/task-<id> branch (created automatically
at claim; never commit to the user's starting branch).
When a task reaches done: commit, push its branch and open a pull request
(gh pr create), then record the PR URL on the task.
Destructive git operations (force-push, hard reset, deletes) still require explicit
user approval.

The /forge, /cruise and /mission workflows load the git and github skills and follow this protocol; the project-board skill documents it for every other run.

Design decisions

Two structural choices define how autonomy behaves, both picked for the best power / safety balance:

Guarantees and limits

• The agent never merges pull requests. Review and merge stay with you.
• Destructive git operations (force-push, hard reset, branch deletion) still go through the normal approval flow, autonomy or not.
• Never lose work, by construction. The autonomy plumbing only ever uses creating and preserving commands: git switch -c, git switch, git add, git commit, git push -u (never forced). There is no reset, no clean, no forced push, no branch delete anywhere in it, and a dedicated regression test fails the build if one is ever added. git switch itself refuses to move when it would overwrite conflicting local changes.
• Raw shell is covered too. The git tool asks before push --force and reset --hard; when the operator enables the built-in deny set (Settings > Security > Agent permissions), the same commands typed through the shell (git reset --hard, git clean -f/-d/-x, git push --force, git branch -d/-D, git checkout -f) are intercepted and pause for your approval instead of running.
• Autonomy applies to runs you start. The board does not run itself in the background unless you enable the Autopilot loop option.
• A machine-wide kill-switch overrides every project (next section).

Global kill-switch (operator config)

Settings > Security > Git exposes two machine-wide toggles: Task auto-branch and Pull request on task done. Turning one off disables that automation for every project, regardless of per-project consent. The same switches live in ~/.navin/config.json:

{
  "tools": {
    "boardGit": {
      "autoBranchEnabled": false,
      "openPrEnabled": false
    }
  }
}

Both default to true. When a switch is off, the consent dialog shows a warning and the corresponding automation is skipped silently at runtime.

Data model and API

Each task carries an auditable git trail:

HTTP endpoints (WebUI API, token-authenticated):

FAQ

Does enabling autonomy start work immediately? No. It changes what happens during runs you start. Launch /cruise, /mission, or Run agent on board to see it chain.

What if my project is not a git repository? Branching and PRs are skipped with an explanatory task comment; task chaining and issue-less features still work.

Which CLI does it need? Git for branching; the GitHub CLI (gh), authenticated, for PRs and issues.

Related

• Project Home - Tasks, Issues, 360 Vision and Graph tabs
• Plan Mode - mission ledger, /blueprint /forge /cruise /mission
• Workbench - the Code side of the same board