Chief requires four agent CLIs, accepts five provider names, and explains none of cursor

Four CLIs in the requirements, five values in the config

The requirements section lists four agent command line tools that must be installed and authenticated: Claude Code, the Codex CLI, OpenCode and the Gemini CLI. Then the configuration section names the accepted values for the provider setting as `claude`, `codex`, `opencode`, `cursor` and `gemini`. That is five values against four requirements, and the extra one is `cursor`, which appears in no requirements line and has no CLI named anywhere in the documentation. So a user who reads only the requirements will not know which binary to install for that value, and a user who sets it will find out at run time. The rest of the configuration surface is small and consistent: Claude is the default, the provider can be set in a `.chief/config.yaml` file with an optional absolute path to the binary, or overridden per run with a flag or an environment variable, which is the arrangement to use in a script or a container.

Every iteration starts with an empty context window

The mechanism is the one Chief is named after. It runs the agent in what the documentation calls a Ralph Wiggum loop, where each iteration begins with a fresh context window while progress is persisted between runs. The stated benefit is that a large project gets worked through without hitting context limits, which is the actual failure mode of long agent sessions: the transcript grows until the useful instructions fall out of the window. Fresh window per iteration means the agent re-reads whatever the persisted state says rather than recalling a conversation. The lineage is credited in the acknowledgements, with the original Ralph implementation attributed to a separate repository and the pattern itself credited to the person who named it. The same idea explains the commit discipline, since persisted progress and versioned work are two halves of the same choice.

One commit per task is the whole review story

How it works is three steps: describe the project as a series of tasks, let Chief run the agent over them one at a time, and get one commit per task with a clean history that is easy to review. That third step is doing more work than it looks. An agent loop that rewrites files over many iterations produces one large diff if you let it, which nobody reviews properly. A commit per task makes each unit of work a discrete, revertable object and gives you a natural place to intervene, since a task that went wrong can be undone as a unit rather than hunted for in a diff. The cost is that the agent has to be trusted to keep each task to itself, and nothing in the documentation describes what happens when a task fails midway, whether the commit is still made, or how a task is judged finished. Those details are pushed to a hosted concepts page rather than stated here.

One TUI dependency sits on an untagged commit

The module requires Go 1.24.2 and a short direct dependency list, most of it the terminal user interface: bubbletea for the program loop, bubbles for components, lipgloss for styling, glamour for rendering markdown in the terminal, and chroma for syntax highlighting. fsnotify watches files, cobra parses the command line, and yaml.v3 reads the config. Six of those seven are pinned to proper releases. The seventh, lipgloss, is pinned to `v1.1.1-0.20250404203927-76690c660834`, which is a pseudo-version pointing at a specific commit that was never tagged. That is normal Go practice for tracking main, and it is also a dependency that will change content if the commit is ever garbage collected or the module is re-tagged, so a build pinned to it is not reproducible from a version number alone. The indirect list is the usual terminal stack: colour profile handling, runewidth and uniseg for cell width, clipboard support, and an HTML sanitiser pulled in by the markdown renderer.

The Makefile still calls Chief an autonomous PRD agent

The build file opens with a two-line header comment naming the project as an autonomous PRD agent, which is a description the README does not use anywhere. It is a leftover from an earlier framing, and it is the kind of thing that misleads someone skimming the repository rather than reading it. The rest of the file is conventional and mostly well made. The version string comes from `git describe --tags --always --dirty` with a fallback to `dev`, and is injected into the binary through a linker flag targeting a version variable in the main package, which is how a build knows its own version without a generated file. Targets cover build, install, test, a short test variant, lint, vet, fmt, tidy, clean, run and help, plus a snapshot build and a release build that both call goreleaser, with the release target documented as requiring a GitHub token. The help target reads the file's own comments to build the list, so documented and actual targets cannot drift.

A build directory that is cleaned and never built into

Two small things in the build file are worth noting because they are the kind of drift that survives for years. The file declares a binary directory, a build directory and a main package, and the clean target removes all three output paths: the binary directory, the build directory and the distribution directory used by goreleaser. Only two of those three are ever written. The build recipe creates the binary directory and writes the compiled binary there, and goreleaser writes the distribution directory, so the build directory is declared, cleaned, and otherwise unused. Harmless, but it tells you the file was assembled by copy rather than grown. The other detail is the phony declaration: the `.PHONY` line lists eight targets while the file defines more than a dozen, so targets like vet, fmt, tidy and the short test variant are not declared phony. In practice a file named vet or fmt in the working directory would shadow them.

A curl installer pointed at a refs/heads/main URL

Installation is a Homebrew tap or a shell pipe. The brew line installs from the tap as `minicodemonkey/chief/chief`, and the alternative pipes a script fetched from the repository into a shell:

curl -fsSL https://raw.githubusercontent.com/MiniCodeMonkey/chief/refs/heads/main/install.sh | sh

That script URL uses the full refs path form, `refs/heads/main`, rather than the shorter branch form most projects use, which is a small sign that it was generated by a tool rather than typed. Both routes install the same binary and both are unpinned in the sense that matters: the pipe always executes whatever is on the branch at that moment, so two people installing on the same day can get different binaries. That matters more here than usual, because the newest tagged release is v0.8.0 from 2026-03-20 while the last push is dated 2026-09-28, so the branch has moved six months past the last tag and the version you install from a pipe tells you nothing about which commit you received.

Editorial conclusion

Chief is a small, legible wrapper around one idea, and the idea is the reason to read it: keep the agent's context window disposable and put the state somewhere else, then let it grind through a task list with one commit per unit of work. Take it if you already have an agent CLI installed and want a reviewable history rather than one enormous commit. Three things to settle first. `cursor` is accepted as a provider value but is not in the requirements list, so treat it as untested. The dependency on the terminal styling library sits on an untagged commit rather than a release, which is a reproducibility risk you inherit. And the newest tag is six months older than the last push, so pin a commit rather than assuming the release line tracks main.

Frequently asked questions

Official sources

1. License: MIT
2. MiniCodeMonkey/chief on GitHub
3. Project website
4. README
5. Releases