Definition

The Operator is a skill installed globally rather than per-project. Where farmwork init sets up a single repo, the Operator sits one level above and knows about all of them - each repo is a farm, and farms are organised into groups with a title, a description, and a folder path.

Invoke it with /operator in either Claude Code or Codex. On its own it produces a sweep: the git state of every registered farm, checklist progress pulled from FarmFactory, and a short ranked list of what deserves your attention.

Core Principle

The Operator reports and suggests - it does not code. Its job is knowing which farm to open, not opening it. Keeping that boundary sharp is what makes the sweep trustworthy enough to run every morning.

Philosophy

Farmwork was always scoped to a single repository. That works right up until you have twelve of them. At that point the expensive question stops being "what should I do in this project?" and becomes "which project has something rotting in it?" - and answering that meant opening each one to find out.

The Operator answers it in one command. It reads git directly on disk, so the sweep is fast and works offline; the FarmFactory connection layers checklist progress on top when it's available.

What It Flags

Findings are ranked by how much you'd regret missing them:

  • Uncommitted work - the only state that can actually be lost
  • Unpushed commits, especially several, or on a long-lived branch
  • A path that no longer exists - the registry has gone stale
  • Behind upstream on the default branch
  • No CLAUDE.md - the farm was never set up with Farmwork
  • A checklist far from complete, or a farm with no checklist at all

Idleness is deliberately not on that list. Some farms are finished, and a tool that nags about them stops being worth running.

Farms & Groups

The registry lives at ~/.operator/config.json. Groups are just a title, a description, and a list of farms - enough structure to scan a portfolio, and no more:

~/.operator/config.json
{
  "farmfactory": { "baseUrl": "https://factory.farmwork.dev", "apiKey": "…" },
  "groups": [
    {
      "name": "Products",
      "description": "Things with users",
      "farms": [
        {
          "name": "DoTheseTasks",
          "path": "/Users/you/Work/DoTheseTasks.com",
          "description": "Task extension + web app",
          "slug": "dothesetasks"          // matches the FarmFactory repo
        }
      ]
    }
  ]
}

You rarely edit it by hand - operator add does it for you:

bash
operator add DoTheseTasks ~/Work/DoTheseTasks.com --group Products --slug dothesetasks
operator add Farmwork     ~/Work/farmwork         --group Tools    --desc "The harness CLI"

The slug is optional

slug is how a farm is matched to its FarmFactory checklist. Leave it out and the Operator falls back to matching on name - set it when the two differ.

The Sweep

Running /operator with no arguments produces the default view. Farms that are clean, pushed, and complete collapse into a single line - the report leads with what's wrong:

/operator
── Products ────────────────────────────────────
  DoTheseTasks         ████████░░  81%  main       3 uncommitted
  MakeThisVSL          ██████░░░░  62%  feat/hooks 2 unpushed
  OpenPaw              ██████████ 100%  main       clean

── Tools ───────────────────────────────────────
  Farmwork             ███████░░░  74%  main       clean
  FarmFactory                           main       behind 4, no CLAUDE.md

Suggestions
  1. DoTheseTasks has 3 uncommitted files — commit or stash before they rot.
  2. MakeThisVSL: feat/hooks is 2 commits ahead and unpushed.
  3. FarmFactory has no CLAUDE.md — run `npx farmwork init` to set it up.

Arguments are read as intent rather than fixed syntax. A group name scopes the sweep; a farm name focuses on that farm; anything else is a request answered with the CLI:

natural language
/operator Tools
/operator what should I work on today
/operator checklist DoTheseTasks
/operator mark the CI item done in Farmwork
/operator add ~/Work/NewThing to Products

Checklists

The Operator reads and writes checklists through the FarmFactory API, authenticated with an X-API-Key header. Each farm has one checklist, measured against a shared catalog of items grouped by theme.

Items are completed, skipped, or pending. Skipping drops an item out of the denominator entirely, so progress is measured against what's genuinely in scope for that farm rather than against a checklist half of which never applied.

Idempotent by design

complete, skip, and reset set state rather than toggling it. Completing an already-completed item leaves it completed, so a retried request can never quietly undo work that was already done - the failure mode that makes agent-driven writes dangerous.

Because item IDs are stable but you'll refer to items in prose, the Operator resolves your wording against the item titles and asks when the match is ambiguous rather than guessing. It also asks before any write - completions are shared state that other people see in FarmFactory.

Checklists need the connection

Set baseUrl and apiKey in the config, or export FARMFACTORY_URL and FARMFACTORY_API_KEY to keep the key out of the file. The git sweep works without any of it - an unreachable server costs you the checklist column, not the whole report.

Commands

The skill drives these for you, but every one works standalone. Add --json to any of them for machine-readable output. Farm arguments accept a name, a slug, a directory name, or a numeric checklist ID.

Command What It Does
operator status [group] Git + checklist sweep across every farm
operator groups List groups with their farms
operator farms [group] List registered farms and their paths
operator add <name> <path> Register a farm, with --group, --slug, --desc
operator remove <name> Drop a farm from the registry
operator checklists Every checklist with its progress
operator checklist <farm> One checklist, every item with its ID
operator complete <farm> <ids> Mark one or many items done in a single call
operator skip <farm> <id> Mark an item out of scope for that farm
operator reset <farm> <id> Return an item to pending
operator config Show resolved config with the API key redacted

Installation

The Operator ships in the Farmwork repo but installs globally, not into a project. It needs Node 18 or newer - the CLI has zero dependencies and relies on built-in fetch.

bash
git clone https://github.com/wynterjones/farmwork
cd farmwork/operator
./install.sh

One install covers both tools - the skill and slash command land in ~/.claude/, and a self-contained prompt lands in ~/.codex/prompts/ so /operator works identically in Codex:

Path What
~/.operator/bin/operator The CLI, symlinked onto your PATH where possible
~/.operator/config.json Your farm registry - never overwritten on reinstall
~/.claude/skills/operator/ The Claude Code skill
~/.claude/commands/operator.md /operator in Claude Code
~/.codex/prompts/operator.md /operator in Codex

Reinstalling is safe

./install.sh updates the skill, prompt, and CLI while leaving your registry alone. ./install.sh --uninstall removes everything it installed and still keeps your farms on disk.