Turn it on
The easiest way: ask your agent to “set up Jig for me”. It asks how far it may go, shows you the file and writes it after your yes (Let the agent ask you). To do it by hand:-
Create
.ai/config.local.yamlin your project if it does not exist, and add one line:The file is yours: Git ignores it, andjig initadds it to.gitignoreif an older project does not ignore it yet. -
For
pr, the agent opens the pull request with GitHub’sghor GitLab’sglab. Install the one for your host and sign in once:Without a signed-in tool the agent still commits and pushes, then tells you the pull request is yours to open. -
Check it took effect:
agent.git in the committed .ai/config.yaml does nothing: that file is shared with
everyone, and a shared value would switch every contributor’s agent on. jig status and
jig doctor warn when they find it there.
Choose how far it goes
Up to
pr, merging is your decision. The same levels apply to a specification’s epic
(Specs and epics).
The merge level
With agent.git: merge, jig task ship opens the pull request, waits for its checks and merges it —
only when at least one check ran and every check passed (it waits up to agent.ci_timeout minutes,
30 by default, set in the same file), the review left nothing serious open, the pull request is not
a draft and it is exactly the commit that was shipped. It merges the way your repository allows: a
merge commit, else squash, else rebase.
It never uses an administrator’s override and never asks the host to “merge when ready” later. When
your repository’s branch protection refuses — a required review, for example — the pull request
stays open and ship says why:
autopilot.unattended: true it is how a
run finishes without you (Autopilot: without stops).
What happens at the end of a task
Nothing changes until the task is done. The agent still sizes the work, and for a risky task it still stops and waits for you to approve the design (Working with tasks). Git rights do not skip that approval. When the work is finished and checked, the agent:- records what the project should remember from the task — or that there is nothing;
- stages the task’s own changes, and only those — if other work sits in the same folder, it stays out of the commit;
- writes the commit message: the first line becomes the pull request’s title, the rest its description — what the task was for and how it was checked;
-
runs
jig task ship, which does the Git part as far as your level allows and reports each step:At a lower level it says where it stopped, for examplestopped at push: the pull request is the human's.
Specs and epics
The same setting covers the work of a specification released at once: the spec reaching your main branch, the epic branch, and the epic’s final pull request. The agent runsjig spec ship <id>, which works out which of the three it is from where your repository stands,
prints it (mode: declare, mode: epic or mode: final) and goes as far as your level allows:
What stays yours at every level:
- Finishing. The agent finishes an epic only when you say every phase is in.
- The version. You choose patch, minor or major when the epic is declared; at the finish the agent raises the version by that choice, or proposes one and waits for your yes when none was recorded.
- Merging. Merging the epic’s final pull request is the release. Only an unattended run at
mergedoes it — with a merge commit, once CI passed and every roadmap item is done — and never for amajorrelease, which it opens as a draft for you.
jig spec ship keeps the limits of jig task ship below: it never force-pushes or skips hooks,
never merges a spec reaching main, merges the epic only as above, commits only what was staged, and refuses when task notes or runtime files are staged. A spec
reaching main is committed on a branch of its own, never on main itself, and may stage nothing but
the spec. The epic is pushed only as a fast-forward: when someone else moved it on the server, the
push is refused and the agent tells you. The final pull request is refused until the epic holds the
latest main.
Review, fix, merge
Review the pull request as you would any other. When you ask for a change, the agent makes it in the same task and runsjig task ship again: it commits the fix, pushes it, and reports the
pull request that is already open instead of opening a second one.
After you merge, the task is not closed yet — a fix may still follow. At the start of a later
session the agent names the merged task and asks whether it can be closed. Nothing is closed
without your yes.
What jig task ship will not do
It is a script, so these limits hold whatever the agent intends:
- it never force-pushes and never skips your Git hooks, and it merges only at
merge, only on green checks and never past your repository’s protection; - it commits only what was staged, never “everything in the folder”;
- it refuses, changing nothing, until the task’s knowledge decision is recorded;
- it refuses on any branch but the task’s own, and on the main branch itself;
- it refuses when task notes (
.ai/workspace/) or Jig’s runtime files (.ai/runtime/) are staged — those never leave your machine.
none it does nothing at all, and the
agent tells you the change is ready for your review.
Turn it off
none — applies again; setting agent.git: none explicitly
does the same thing. The next task ends in your working tree again. The same command takes back
autopilot.unattended, and jig config show --local prints what is left
(Configuration).