Fabrik: A Go CLI That Turns GitHub Projects Into a Claude Code SDLC Pipeline

What Fabrik Actually Automates

Fabrik solves a specific coordination problem: keeping Claude Code focused on one issue at a time, in a defined order, with the GitHub Project board as the source of truth. Instead of a human pasting a prompt into Claude Code and then manually moving cards, Fabrik polls the board, matches each issue's column to a stage configuration, and invokes Claude Code in an isolated git worktree. The issue body is the spec, comments are user input, and the board columns define the workflow. This is aimed at engineering teams that already use Claude Code and want a repeatable pipeline from specification to validation, with a human either approving each stage or letting it run in yolo mode. The README makes clear that issues are the unit of work, not pull requests or branches. That design choice keeps everything traceable: stage progress is recorded as labels and comments on the same issue.

How the Pipeline Moves an Issue

The mechanism is a poll loop. Fabrik fetches the entire project board with a single GitHub GraphQL query, then matches each issue's board status to a stage config written in YAML. For each matched issue, it creates an isolated git worktree on a branch named fabrik/issue-N, runs Claude Code inside that worktree with the stage's prompt, model, and tool configuration, and waits for Claude to signal completion. On completion, the issue gets a label like stage:<name>:complete. In yolo mode the issue auto-advances to the next stage; otherwise a human moves the card to the next column. The stage configs live in .fabrik/stages/, and the documentation says the board columns define the workflow, so the YAML files are the mapping layer between board positions and Claude prompts. This is a clean separation: the board is the state, the stage files are the behavior.

Getting It Running: Commands and Config

Fabrik requires Go 1.26.1+, the Claude Code CLI, and a GitHub token with repo and project scopes. Installation is a single go install command: go install github.com/handarbeit/fabrik@latest. Then you run fabrik init with a GitHub Project URL, which auto-populates owner, project, and owner_type, and creates .fabrik/stages/, .fabrik/plugin/, and .fabrik/config.yaml. Without a URL, init runs interactive prompts in a TTY or produces a blank template otherwise. You edit .fabrik/config.yaml and commit it, then put your token in a gitignored .env file as FABRIK_TOKEN or GITHUB_TOKEN. Configuration precedence is CLI flag over env var over .env over config.yaml over defaults. For GitHub Enterprise Server, you set --ghes-host or FABRIK_GHES_HOST or ghes_host in config. The README also mentions fabrik refresh-stages --apply to add missing keys to stage files after an upgrade. That command is useful because stage YAML drift is a real failure mode.

The Auto-Upgrade Behavior Is a Double-Edged Sword

Fabrik can self-upgrade. With --auto-upgrade, it checks for a newer release at startup and after two idle polls, downloads it, and re-execs. For dev builds, it detects local or remote commits ahead of the running binary and rebuilds in place from origin/main. That is convenient for a tool that changes fast, but it is also a risk: a background process that rewrites its own binary and restarts itself is not something every team wants in a production loop. The README acknowledges this by making it opt-in via the flag, but the fact that it exists at all means you should pin your releases or run without the flag if you need stability. The upgrade path also checks your .fabrik/stages/*.yaml files against embedded defaults and prints a warning for missing fields. That drift warning is a good idea, but it means an upgrade can break your pipeline silently if you ignore the warning and keep running old stage files.

Security and Auth Handling: A Specific Improvement

Version v0.0.77 introduced a notable security fix: every worker invocation's environment is scrubbed of the Anthropic and Claude Code auth namespace by default. That means an ambient ANTHROPIC_API_KEY in the engine's environment cannot silently redirect a stage from subscription billing to metered API billing. The only supported opt-in for API billing is FABRIK_ANTHROPIC_API_KEY, and apiKeyHelper is refused outright, both at startup and per-invocation. This is a real design decision, not a marketing bullet. It addresses a genuine failure mode where a developer's shell environment could cause unexpected costs. The trade-off is that if you want to use API billing, you must explicitly set that environment variable, which is a small but deliberate friction. The README also notes that GHES support is pure endpoint and host configuration, with no adapter layer, which keeps the codebase simpler but means you get the same behavior on github.com and self-hosted instances.

Performance Optimizations for Large Boards

Fabrik includes two GraphQL cost optimizations that matter for teams with many issues. Version v0.0.57 introduced a lightweight updatedAt-only probe that gates the full deep-fetch. Only items that changed since the last poll trigger a full query, which drops per-poll GraphQL cost by roughly 5 to 10 times on large boards. Terminal items, meaning issues in a cleanup or Done column with a stage:complete label and no active lifecycle labels, are skipped entirely from both probe and deep-fetch. Version v0.0.58 added cold-start optimization: on startup, closed Done items are seeded from probe data as terminal without a deep-fetch, reducing cold-start GraphQL cost by about 80 to 90 percent. The README claims this makes running two Fabrik instances on a single token budget practical. That is a concrete operational benefit, though the exact numbers come from the project's own release notes, not from independent benchmarks.

The Plugin Ecosystem: Fabrik PM and Entwurf

Fabrik ships with two optional Claude Code plugins. The Fabrik PM plugin gives Claude ambient awareness of the board, stages, and stuck items, so you can ask what's on the board or why issue 42 is stuck without leaving your editor. It provides a skill that auto-activates when .fabrik/ is detected, a setup skill, and a /fabrik:status command that shows board snapshots and worker status. The plugin is independent of the engine, so you can install it on its own. The Entwurf plugin targets a non-technical product manager or business owner. It interviews the user about goals, users, scope, constraints, and vocabulary, then produces a Spec Kit folder under specs/NNN-feature-name/ ready for Fabrik to build. This separates the product thinking from the engineering execution, which is a sensible split. However, the README is explicit that the engine's stage skills are embedded in the binary and deployed by fabrik init, and you should not install the separate fabrik-workflows plugin manually. That distinction is easy to miss and could cause confusion.

Limitations and When It Is the Wrong Tool

Fabrik is not a general automation platform. It is tightly coupled to GitHub Projects, Claude Code, and the concept of issues as the unit of work. If your team uses Jira, Linear, or even GitHub Issues without Projects, Fabrik has no adapter for that. The README shows no support for other issue trackers or other AI models. The worktree-per-issue model also means each issue gets its own branch and working directory, which is clean for isolation but can become expensive with many concurrent issues, since each worktree is a full checkout. The auto-upgrade behavior, while opt-in, is a maintenance cost: you must either accept the self-updating binary or remember to disable it and manage upgrades manually. The stage YAML drift warning is helpful, but it only prints a warning; it does not automatically fix the files until you run refresh-stages --apply and review the diff. Finally, the project is in rapid release (v0.0.80 as of August 2026), so the API and behavior may change between minor versions. Teams that need stability should pin a version.

Alternatives and How They Differ

The most direct alternative is a custom GitHub Action or a CI job that runs Claude Code on every issue. That approach differs in a fundamental way: it is event-driven, not poll-driven. A GitHub Action triggers on issue events or labels, whereas Fabrik polls the board on an interval. Polling gives you a single source of truth that can be changed externally, but it also means you have a long-running process that must be kept alive. Another alternative is to use Claude Code's own agentic features without a pipeline driver, where a human manually runs Claude Code per issue and moves cards. That is simpler and more flexible but loses the repeatable stage definitions and the board as the state machine. Fabrik's value is that it enforces a workflow: stages like Specify, Research, Plan, Implement, Review, Validate are not just labels, they are executable prompts with specific model and tool settings. A generic CI approach would require you to build that stage logic yourself. The trade-off is that you are locked into Fabrik's model of stages and its YAML schema.

Editorial conclusion

Adopt Fabrik if your team already relies on Claude Code, uses GitHub Projects as a source of truth, and wants to automate the repetitive parts of issue-driven development with human approval gates. Skip it if you need a non-Claude agent, if your workflow lives outside GitHub Projects, or if you cannot tolerate a binary that self-upgrades and re-execs without explicit opt-out. Before committing, verify that your GitHub token has both repo and project scopes, that your board columns map cleanly to stage YAML files, and that you are comfortable with the auto-upgrade behavior, which can rebuild from origin/main in dev builds. The project is Apache-2.0, actively released (v0.0.80 as of August 2026), and its docs are at fabrik.handarbeit.io, but the real test is whether a single misconfigured stage file stalls your board.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes