AI

Two ways to bring AI into GForge.

Flow AI is GForge’s own assistant, working inside your projects with a model and API key you provide. gforge-cli connects outside AI tools like Claude Code to GForge from your own machine. Same real project context either way — your choice of how you get there.

  • Flow AI reads and writes tickets, wiki pages, sprints, and more — using your own model provider
  • Off by default. Nothing runs until an administrator explicitly enables it.
  • Attach Flow AI to a workflow transition and it runs automatically, no chat required
  • Prefer your own AI tool? gforge-cli connects Claude Code and any MCP client instead

Your own AI, working inside GForge

Not a bolted-on chatbot — an assistant with real, permission-scoped access to your project, using a model and API key you control.

GForge Flow AI project settings screen showing AI Flow enabled, LLM Provider set to Anthropic, with model and API key inherited from the parent organization

Per-project AI Flow settings — provider, model, and API key, each independently overridable or inherited.

Off by default. Your own key. Your call.

GForge doesn’t operate its own AI model — there’s no training pipeline your tickets, wiki pages, or code could feed, for any customer, on any plan. AI is also off by default: nothing runs until an administrator explicitly enables it and configures their own model provider.

Configure it per project, with settings inheriting down from parent projects to a site default. Bring your own key for OpenAI, Anthropic, Google, Mistral AI, or AWS Bedrock — your provider’s terms govern what happens to what you send it, not ours.

Why this matters right now →

Flow AI chat interface: a user asks it to update a ticket, and Flow AI confirms it set the Work Branch field, assignee, and status

Ask it to check something — or hand it a real task and let it do the work.

A teammate that knows your project

Flow AI can read tickets, wiki pages, sprints, and commit history — and, when you ask it to, take real action: update fields, reassign work, change status, write follow-ups. In the example above, one message updated three separate parts of a ticket in a single pass.

It runs authenticated as you, not a hidden service account — it can only see and touch what you already can.

GForge tracker workflow transition AI tab with an LLM Callout Prompt configured to produce a pre-review briefing when a ticket moves from Accepted to Needs Merge

Attach a prompt to any workflow transition — it runs automatically, no one has to remember to ask.

Put it on autopilot in your workflow

Flow AI doesn’t have to be something someone remembers to open. Attach a prompt to any tracker workflow transition, and it runs the moment a ticket crosses it — reading the ticket, the diff, and the acceptance criteria, then posting its findings as a follow-up.

The example above triggers on Accepted → Needs Merge: a pre-review briefing checking acceptance-criteria coverage, flagging missing test coverage, calling out security- or migration-sensitive changes, and listing open questions for the human reviewer — before anyone opens the diff.

Reads & Writes, For Real

Tickets, wiki pages, sprints, tags, assignees, commit diffs — not a read-only summary tool.

Cites Its Sources

Answers are grounded in your actual tickets, wiki, and commit history — not a guess.

Runs As You

Every action goes through your own permissions — never a superuser or hidden service account.

No Model to Train

GForge doesn’t build or operate a proprietary AI model — there’s no training pipeline for your data to feed, for anyone, on any plan.

Prefer your own AI tool? Bring it to GForge.

gforge-cli connects Claude Code, Cursor, or any stdio MCP-compatible client directly to your GForge instance — from your own machine, using your own AI subscription.

  • One binary handles both AI access and CLI scripting
  • Works with Claude Code, Cursor, and any stdio MCP-compatible AI tool
  • Shell scripts and CI/CD pipelines, without wrestling the raw API
  • macOS · Linux · Windows · zero runtime dependencies
GForge MCP
You
I’m on #65202 — pull mtutty’s last comment so we know what happened.
get_tracker_item #65202 · include_followups
AI Agent
Got ticket #65202: Add tagging support to wiki pages.
mtutty (2 hours ago): “Spent 2 hours on merge conflicts, didn’t trust the result. Dig through git history — don’t just make the tests pass.”
Found it — a dropped property was breaking the build. That branch had since merged upstream, so I rebased fresh instead — down to 2 conflicting files instead of 20. Tags saving correctly.
You
Ok, now that’s dealt with, I see tags are getting added twice when saving a wiki page. What happened? Confirm by checking the DB first and if that’s the case check the code and report back with your findings.
AI Agent
Confirmed: duplicate rows in tag_entry — a race condition between two save hooks firing on the same new page.
You
Ok, add a follow-up to that ticket with your findings and then give me a plan to address this race condition.
add_tracker_item_followup #65202
AI Agent
Followup posted. Plan: update tagsOriginal synchronously right after the first save hook fires, so the second hook sees no diff and skips the redundant save.