Features and scope

A feature is a name, a branch, and the set of repos that branch exists in. It decides two things: what the agent may write to, and what gets delivered together.

Create one

/ivar-feature-create

Creates a persistent feature — for one repo or several. The name is one path segment, unique in the hall, and becomes the branch name.

A fresh feature owns no repos. That is deliberate — repos join one at a time, so scope is a decision you make rather than a guess you commit to up front.

See where you stand

/ivar-feature-status

Reports which repos are promoted — writable, on the feature's branch — and which are read-only. Worth running at the start of every session: it is the fastest answer to why can the agent not edit this file?

Promote a repo

/ivar-promote

Moves a repo from a read-only default-branch checkout to a writable feature-branch worktree for the current feature. A branch that already exists is adopted as it is; one that does not is cut from the repo's base.

Subfeatures

Large work splits into slices that run in parallel. Create a main feature, then one subfeature per slice; each gets its own branch and worktree, cut from the main feature's branch.

ivar feature create <feature>
ivar feature promote <feature> <repo>
ivar feature create <child> --parent <feature>
ivar feature promote <child> <repo>

See the whole tree, including each child's plan approval gate, run execution status and active wave, and session IDs:

ivar feature status <feature> --recursive

Integration requires the child's plan gate to be approved, and the gate exists so a child lands work someone agreed to. Write the child's slice of the parent plan into its plan.md (the files it owns, its waves, any design links), then approve it. Approving the empty scaffold passes the gate and gives the child's session nothing to execute.

ivar plan create <child> plan
ivar plan approve <child> plan

When the child is done, finish its run and stop its session, then integrate it from the parent's session:

ivar feature integrate <child>

The child's work lands on the parent's branch and the child closes as integrated. A merge conflict fails the command with exit code 2, and the repos that did integrate keep their result. Fix the conflict on the child's branch and run the same command again. The main feature is what you deliver.

To orchestrate children in parallel — running planning subagents with human decision routing, batch plan approval, autonomous goal-mode execution, integrating leaves first, and previewing the parent delivery from a single parent session — use the shipped /ivar-subfeatures skill. ivar feature create --parent prints the same next steps: promote, then the short plan path before integrate.

Open it in an editor

/ivar-workspace <feature-name> [repo...]

Opens a multi-root VS Code workspace for the feature. The workspace is the guard rendered as an editor: promoted repos open writable on the feature branch, while context repos open read-only on their default branch. The same boundary the agent works under is the one you read the change under.

Naming specific repos restricts the workspace to a subset, useful when the hall declares more repos than the immediate change concerns.

Which repos are related

/ivar-relations [repo-name]

Maintains the Repository relationships region of HALL.md: human-confirmed, directed sentences from one repo to another. A relation expresses co-belonging — when work starts in the source repo, the target is likely to need a change too.

This is the context planning reads before it analyses anything, which is what lets an analysis say this will also touch web without rediscovering the relationship every time.