new-feature

new-feature aims to eliminate friction for creating new features. In a single command, it creates isolated git worktrees, allocates conflict-free runtime values, runs project-defined setup and teardown commands (such as creating and deleting a feature database), and optionally launches a configured coding agent in the new worktree.

Install

uv tool install new-feature
new-feature setup --agent codex

new-feature setup launches the configured coding agent in the current repository. With no local default agent yet, pass --agent codex or --agent claude. The agent inspects the project, proposes a repository-specific configuration, asks about unresolved choices such as the optional Codex hook, and waits for approval before further edits. Run it again to review and improve an existing integration.

Releases

Every push to main, including docs-only changes, runs quality gates and publishes an automatic release. CI preserves an unpublished manual version; otherwise it increments the latest patch with uv version, updating pyproject.toml and uv.lock together. It verifies and commits that version before publishing to PyPI and creating the GitHub release. Manual bumps remain available with uv version --bump patch (or minor/major).

Retries reuse the release commit without another bump. Superseded runs defer to the newer push. The bot's version commit does not trigger another workflow run. Pull requests run quality gates without publishing.

Documentation

The documentation site uses this README as its homepage and generates its API reference from package docstrings. Build it before committing documentation changes:

uv run mkdocs build --strict

To preview the site locally with live reload, run uv run mkdocs serve. Pushing to main builds and deploys the site through GitHub Pages.

Usage

# Ask an agent to configure or improve new-feature for this repository.
new-feature setup --agent codex
# Create a feature worktree. It launches no agent unless you configure a local default.
new-feature my-feature
# Create a feature worktree and explicitly launch an agent.
new-feature my-feature --agent claude
# Create a feature worktree without launching an agent, even when a default is configured.
new-feature my-feature --no-agent
# Merges the worktree into the main branch
new-feature merge my-feature
# Run configured teardown and remove the feature worktree.
new-feature teardown my-feature
# Teardown a worktree even if it has uncommitted work.
new-feature teardown my-feature --force
# Inspect managed features and diagnose stale state.
new-feature list
new-feature doctor
new-feature doctor --repair

Project Config

Put shared repository policy in the target repo's .new-feature.toml:

target_branch = "main"
setup = ["uv sync"]
pre_merge = ["uv run pytest"]
post_merge = ["uv run pytest"]
teardown = []

[env]
WEB_PORT = { allocate = "port", min = 3000, max = 3999 }
API_PORT = { allocate = "port", min = 4000, max = 4999 }
DATABASE_NAME = { allocate = "name", prefix = "myapp", max_length = 63 }
CACHE_DIR = { allocate = "path", base = ".new-feature/cache" }

Keep personal preferences in the ignored .new-feature.local.toml sidecar:

default_agent = "codex"
pull_before_create = true
push = true
agents = { custom = ["custom-agent", "--prompt"] }

new-feature setup and feature creation add *.local.toml to Git’s local info/exclude. Generated ignore rules are shared by linked worktrees and leave tracked .gitignore files unchanged. This makes local agent commands, automatic pull/push preferences, and machine-specific values safe to customize without changing versioned repository policy.

All settings remain optional. new-feature resolves a shared configuration from .new-feature.toml when present, otherwise from [tool.new-feature] in pyproject.toml. It then overlays .new-feature.local.toml, which uses the standalone-file syntax above and can also be used on its own. A local value replaces a shared scalar or command list; entries in agents and env overlay by name. For projects that prefer the shared pyproject.toml form, use [tool.new-feature.env] there and [env] in the local sidecar.

default_agent, pull_before_create, and push remain supported in shared config when a repository wants to enforce them, but local placement is the recommended default. default_agent is optional: without it, feature creation does not launch an interactive agent. Codex and Claude are built in and always work with --agent; agents adds or overrides named commands and fixed arguments. new-feature appends its generated feature prompt as the final argument, so a personal agent that requires a prompt flag can be configured in the local sidecar:

# .new-feature.local.toml
default_agent = "custom"
agents = { custom = ["custom-agent", "--prompt"] }

Use a configured agent for one invocation, or pass an executable command directly:

new-feature my-feature --agent claude
new-feature my-feature --agent "fooagent --baz-flag"
new-feature setup --agent claude

When the value exactly matches a key in agents, that configured command is used. Otherwise, new-feature parses the value as an executable command without invoking a shell.

The built-in create and setup prompts can be overridden with create_prompt and setup_prompt in TOML, or for one invocation with --prompt.

setup runs after worktree creation; teardown runs before worktree removal.

Supported env entries:

• { value = "literal" }
• { allocate = "port", min = 3000, max = 3999 }
• { allocate = "integer", min = 1, max = 15 }
• { allocate = "name", prefix = "myapp", max_length = 63 }
• { allocate = "slug", prefix = "myapp" }
• { allocate = "path", base = ".new-feature/cache" }

Lifecycle

Git operations, hook policy probes, lifecycle commands, and launched agents discard inherited repository-location, index, and object-directory overrides such as GIT_DIR and GIT_COMMON_DIR. Their working directory selects the repository, even when invoked from a Git hook. Transport and authentication settings remain available; explicitly configured lifecycle environment values still take precedence.

Merge completion is determined from Git ancestry, including empty features and features merged outside this tool. Already-integrated branches update manifest bookkeeping without running checks or creating another commit. Repeat merges inspect the current branch and require a clean feature worktree. If commits were added after a successful merge, the command runs the full checks and merges those commits. A push-only retry applies only while the branch remains included in the target history.

new-feature my-feature creates branch my-feature and worktree .worktrees/my-feature, reserves env values in .new-feature/manifest.toml, runs setup, and launches an agent only when default_agent or --agent selects one. With pull_before_create = true, it first runs a fast-forward-only pull on the clean, checked-out target branch. It automatically adds .new-feature/, .worktrees/, and *.local.toml to Git’s local info/exclude, preserving a clean target checkout. Existing local exclude rules are retained. If setup fails or is interrupted, it stops the command's process group and runs a forced teardown so the partial worktree, branch, manifest entry, and child processes do not linger.

Running create again for an active feature reuses its recorded worktree and environment, skips pulling, allocation, and setup, and launches the selected agent again. Dry runs also skip pulling. Without a selected agent, it prints the existing worktree guidance. If the recorded worktree or branch is missing, create stops and directs you to new-feature doctor --repair instead of silently replacing inconsistent state.

After a successful create that does not launch an agent (for example, with --no-agent or no selected agent), new-feature prints the absolute worktree path and a copy-pasteable command such as:

Worktree ready: /path/to/repository/.worktrees/my-feature
Next: cd -- /path/to/repository/.worktrees/my-feature

A CLI process cannot change its parent shell's or an already-running coding agent's working directory. In an interactive shell, run the printed cd command; an existing coding agent should use the printed absolute path as the working directory for its subsequent tools. Paths on the Next: line are shell-quoted when necessary.

Creation holds the feature operation lock through setup and publishes an initializing record until setup succeeds. Create, merge, teardown, and doctor repair cannot concurrently mutate the same feature. Interrupted setup reports setup-incomplete; inspect and preserve any work, then teardown and recreate the feature.

Port allocators share reservations across all configured port variables, including values allocated earlier in the same creation.

new-feature list shows each managed feature and its current Git/worktree state, including patch-equivalent when every non-merge patch already exists in the target history despite different commit ancestry. new-feature doctor reports stale manifest entries, dirty worktrees, unmerged branches, and configuration drift. doctor --repair removes stale manifest entries whose worktree and branch are both already gone, and recovers a missing worktree when its branch is merged or patch-equivalent.

new-feature merge my-feature first requires a clean feature worktree and rejects a predicted conflict, before it runs pre-merge checks. Different features can run those checks in parallel, but a second merge or teardown for the same feature fails while its lifecycle is in progress. Merges serialize before validating or changing the shared target checkout. Target checkout selection must succeed before rollback ownership begins. The command then rechecks the conflict under that lock, starts a no-commit merge into the target branch, runs post-merge checks on the merged target checkout, commits the merge only if those checks pass, records the merge, and pushes only when push = true. A failure through the bookkeeping step stops the command process group and restores the target's original clean revision, including removing generated untracked files. A push failure leaves the successful local merge recorded; rerun the same merge command to retry only the push. Failed pre- and post-merge commands retain their combined output under .new-feature/diagnostics/merge-failures/<feature>/; the error prints the exact log path.

new-feature teardown my-feature runs the configured teardown commands before removing the worktree, deleting the branch, and removing the manifest entry. If the manifest does not know the feature, teardown still recognizes the conventional .worktrees/my-feature path, derives its actual branch, and applies the same Git safety checks. It skips configured teardown commands for that fallback because their recorded environment is unavailable. Merged and patch-equivalent branches are safe to remove normally. If the worktree has uncommitted changes, the branch has patches absent from the target history, or an unmanaged worktree is detached, pass --force to abandon it deliberately. Branch ranges containing merge commits remain unmerged because git cherry cannot account for novel conflict resolutions.

Agent hooks

Install the Codex or Claude Code hook in the current repository:

new-feature install-codex-hook
new-feature install-claude-hook

The Codex hook is written to .codex/hooks.json; Codex loads the guard only for this trusted repository. The Claude Code hook is written to the hooks section of .claude/settings.json, which Claude Code loads at session start. Both guards protect the configured target branch from direct agent edits and require Git worktree creation and removal to go through the managed new-feature lifecycle.

Direct edits are allowed before the repository has any commits, so its first commit can be created. Once history exists, protection also applies to orphan target branches. The root .new-feature.local.toml remains editable only while Git ignores it and it is untracked; nested files and symlinks to other files receive no exception. Every path in a multi-file edit is checked independently.

Both installers accept --global to install the guard in the user-level configuration (~/.codex/hooks.json or ~/.claude/settings.json) so it covers every repository on the machine; outside a new-feature-managed repository the guard allows everything. The Claude Code installer also accepts --local to write the guard to .claude/settings.local.json, the personal gitignored settings file, instead of the shared settings.json.