A software factory for AI-assisted development: each role — committer, documentalist… — does one job with only the context it needs, tools do the mechanical work, and an AI is called only when a decision needs judgement. Everything keeps working without AI.

Status (2026-09-24): used daily on its author's machine;

Install

You need git. Each release holds the binary for Linux, macOS and Windows; on Linux or macOS, into ~/.local/bin:

os=$(uname -s | tr A-Z a-z); arch=$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')
curl -fsSL "https://github.com/JN0V/workline/releases/latest/download/workline_${os}_${arch}.tar.gz" | tar -xz -C ~/.local/bin workline
workline version

Or, with Go 1.21 or later, which puts it in $(go env GOPATH)/bin, usually ~/go/bin (add it to your PATH):

go install github.com/JN0V/workline/cmd/workline@latest

To update, run the same command again, into the same place: the global hooks call the binary where it was when they were installed (command -v workline says where). Then set up this machine:

workline setup    # asks, then does: the global hooks, your agent, the tools the roles use

It asks whether to check every commit (the global hooks, below), which agent judges (none, or Claude Code: below), and installs the tools the roles use — gitleaks for secrets, the claude CLI — each with the command it shows first. Run it again to change your answers; --yes takes the defaults. It ends with workline doctor, which says at any time what is set up and what is missing, each with the command that sets it up.

In a repository, workline init has the committer and the documentalist run before each push, and, with an agent, proposes for each doc the code it describes, for you to review and commit: until a doc names its sources, nothing tells when it goes wrong. --review has the reviewer read each merge request's code too; workline review reads a branch's before you push it.

Check every commit on this machine

workline setup does this when you say yes; by hand:

workline hooks install --global     # git's global core.hooksPath now goes through workline
workline hooks uninstall --global   # gives core.hooksPath back as it was

Each global hook hands over to the one that held core.hooksPath before, or, when there was none for that hook, to the repository's own (.githooks/, .git/hooks/): nothing that ran before stops running. A repository opts out with an empty .workline/off file.

Try it in any repository:

git commit --allow-empty -m "AC-3 fix the thing"
# workline committer: block — rewrite the commit message
#   format subject: the subject must read `type(scope): summary`…

Let an AI rewrite what is refused (optional)

By default no AI is used: a refused message is explained, and you rewrite it. To let an AI rewrite it (workline setup installs Claude Code and does step 2; you still log in once):

1. Install Claude Code, run claude once and log in (a Claude subscription or an API key). workline calls claude -p with that login: it holds no key of its own.

2. Tell workline to use it, for all your repositories:

   mkdir -p ~/.config/workline
   echo 'ai: claude' >> ~/.config/workline/config.yaml
   

   On macOS the file is ~/Library/Application Support/workline/config.yaml. A project's own .workline/config.yaml wins over yours, and WORKLINE_AI=none git commit … turns the AI off for one commit.

The same commit now goes through, rewritten:

workline committer: pass — message rewritten
workline: the commit goes on with this message instead of yours:
  │ fix: fix the thing
  │
  │ Refs: AC-3

Claude Code is the only agent built in (cmd:<command> runs any other).

Where it runs

On your machine, on a forge, or both: each place fires its own events, and one routing (routing.default.yaml, changed in .workline/config.yaml) says which roles each event runs. A role behaves the same wherever it runs; only the trigger, the agent at hand and the way proposals are applied differ. Setting it up in CI, on GitHub or GitLab, another forge, or none: docs/ci.md.

flowchart LR
  routing[("one routing<br/>.workline/config.yaml")]
  subgraph machine["Your machine"]
    commit["git commit"] -- commit-msg --> committer1["committer"]
    push["git push"] -- pre-push --> local["the project's pre-push line"]
  end
  subgraph forge["Forge: GitHub or GitLab"]
    mr["merge request"] -- merge-request --> judge["judge job<br/>committer, documentalist<br/>no write token but code scanning's"]
    judge -- proposals --> apply["apply job<br/>no AI key"]
    schedule["schedule<br/>a pipeline you add"] -- schedule --> documentalist["documentalist"]
  end
  machine -- git push --> forge
  routing -.-> committer1
  routing -.-> local
  routing -.-> judge
  routing -.-> documentalist

So the committer checks your messages as you write them, and again on the merge request for those without the hook; the documentalist runs on the forge. On a forge, one job judges with no write token but code scanning's (SARIF upload) and another applies without an AI key (--no-apply, then workline apply).

The CI templates run workline route (merge-request; schedule for the gardening ones), so a project's routing: reaches its CI too.

Take only a part

workline is one binary with its roles inside, and needs nothing but git (and gh to reach GitHub; GitLab is reached through its API). Any existing pipeline can call one role, and leave the rest:

workline run-role committer --event merge-request --ai none \
  --input range=origin/main..HEAD --json    # exit code: 0 pass, 1 block, 2 human, 3 external
workline run-role documentalist --event schedule --ai none --json
workline gate release --json   # a gate declared in .workline/config.yaml: your scanners' SARIF, with thresholds

• The exit code carries the verdict; --json gives the findings to whatever reads them.
• The global hook hands over to the hooks that were there before; nothing stops running.
• --no-apply and workline apply fit a pipeline that keeps tokens apart.
• A role is a folder (role.yaml, facets, pre and post in any language): a team can replace one facet (.workline/roles/<role>/), or run its own roles with --roles <dir> (role contract).

Not there yet: an agent other than Claude Code built in (--ai cmd:<command> runs any).

Develop

git clone https://github.com/JN0V/workline && cd workline
go build -o ~/.local/bin/workline ./cmd/workline   # or anywhere on your PATH
go test -count=1 ./...    # unit tests and the conformance suite

-count=1 matters: the conformance suite builds the engine itself, which Go's test cache does not see. The evaluation grades the roles with a real agent on real cases, and costs tokens, so it runs only when asked: WORKLINE_EVAL=claude go test -count=1 -timeout 60m ./tests/evaluation/ (docs/spec/conformance.md, "Evaluation").

Read next

• Usage — commands, options, exit codes, files, variables
• CI — setting it up on GitHub, gitlab.com, a self-managed GitLab
• Principles — the rules every choice is checked against
• Role contract — what a role is
• Decisions · Research · Backlog