Skip to content
v1.1.26 · CLI · pip install briar-cli

Point it at a board. Get PRs back.

Briar is a free engineering tool you run on your own laptop. Point it at your project board — Jira, Linear, GitHub Projects — and it picks the next ticket, writes the code, and opens the pull request for your team to review. It remembers what shipped so the next ticket goes faster.

Under the hood:

  • An LLM-driven selector picks the next card from your board.
  • An engineer agent clones the repo, writes the code, opens the PR.
  • A per-project knowledge file is updated with what it learned.
  • Loop until the board is done — or until you stop it.

No SaaS, no upload — everything runs on your machine. A read-only HTML dashboard ships in the box.

GitHub starsPyPI versionPyPI monthly downloadsSupported Python versionsLicense
briar plan runLive
$ briar plan build jira:KAN --company acme --llm anthropic
› fetched 12 cards · synthesised scope + risks via anthropic
✓ saved plan:acme-q3 · seeded knowledge:acme.acme-q3
$ briar plan run acme-q3 --llm anthropic --owner acme --repo widgets
[INFO] plan.next.decision pick KAN-1 · "unblocks the auth chain"
[INFO] plan.run.card.start KAN-1 · branch=briar/kan-1
✓ plan.run.card.completed KAN-1 · PR #482 opened
[INFO] knowledge:acme.acme-q3 updated · 3.4 KB
[INFO] plan.next.decision pick KAN-2 · "unblocks notifications"
$

Who it's for

One tool, three jobs to do.

Briar is a CLI engineers run on their own laptops. Here's what it does for the three people who care about that decision.

  • For engineers

    Stop drowning in tickets.

    Briar reads your project board, picks the next ticket, writes the code, and opens the pull request. You review. The boring parts of every sprint — done before standup.

  • For your team

    Every PR is reviewable.

    Briar opens normal pull requests with a full description of what it did and why. Your team's existing review process applies. Nothing ships without a human approval.

  • For your CTO

    Your code never leaves your hardware.

    Briar runs on your machine — there is no Briar server. It uses your LLM API key directly. MIT-licensed, free CLI; you pay only your LLM provider, with no markup.

Plugs into the tools your engineers already use

  • GitHub
  • Bitbucket
  • Jira
  • Linear
  • AWS
  • Slack
  • Sentry
  • PagerDuty

What Briar gives you

One CLI. The full plan-to-PR lifecycle.

  • Plan

    Tell Briar which project board you want to work on. It reads each ticket, breaks down what's in scope, flags the risks, and saves a plan you can review before any code is written.

  • Run

    Briar picks the highest-leverage ticket, an engineer agent writes the code, opens the pull request, and posts a summary of what it changed and why. It remembers what worked so the next ticket goes faster.

  • Observe

    A simple web dashboard ships in the box. See every ticket's status, the reasoning behind each agent decision, and what's queued next — all from a single page running on your machine.

Honest comparison

How Briar stacks against what you're using today.

We don't pretend Briar wins on every axis — cloud agents have slicker UX, DIY scripts cost nothing. Here's the honest break-down so you can decide where Briar fits.

Briar

local CLI

Cloud agents

Cursor / Devin / Replit

DIY scripts

shell + GitHub Actions

Where your code lives during a run

Your machine — clone happens locally
Uploaded to the vendor's cloud
Your machine

Context the agent sees

23 extractors mining PRs / AWS / meetings / tickets / code-quality
Whatever the IDE pane has open
Whatever you paste into the prompt

Planning across a board

LLM selector picks the next card from past runs + knowledge
One ticket at a time, manually
You build it from scratch

Audit trail

Append-only journal · every decision recorded
Vendor logs you can't grep
stdout, if you redirected it

Observability

Read-only HTML dashboard · 24 sections · port 8080
Vendor dashboard (paid tier)
None

LLM cost model

Your API keys, your bill — no markup
Bundled SaaS pricing, often 3-10× key cost
Your API keys, your bill

License

MIT · pip install briar-cli
Closed source · per-seat subscription
Whatever you wrote

Short version: pick Briar when you want a real audit trail, your code on your hardware, and your LLM bill at cost. Pick a cloud agent when polish trumps everything else. Pick DIY when the investment of building it yourself is genuinely worth it.

The primitives

Eight primitives. One CLI.

Briar ships these eight concepts and nothing else — every one is a real CLI command you can run today. No hosted backend, no account to create, no workspace to provision.

  • Extractors

    Twenty-three plug-in extractors mine fresh state from GitHub, Bitbucket, Jira, Linear, AWS, and Fireflies meetings into per-company markdown. PR archaeology, codebase conventions, reviewer profiles, ticket history, plus code-quality signals — defect hotspots, PR hygiene, CI health, dependency & code-scanning alerts. Merge it straight into CLAUDE.md for Claude Code to read on demand.

    briar extract
  • Plan

    Point at a board, get an LLM-curated card list. The synthesiser annotates every card with scope, out-of-scope, risks, and inferred dependencies. The plan is local markdown + JSON; the live knowledge file is seeded alongside.

    briar plan
  • Agents

    Two archetypes ship today: the engineer agent implements one ticket end-to-end (clone, code, open PR); the pr-fixer agent reads review comments and pushes follow-up commits with [AI]-prefixed replies.

    briar agent
  • LLM-driven selector

    An LLM-driven planner reads past runs from the journal and the live knowledge file, picks the next card, and tells the runner what to do — pick, replan, complete, or block. No dependency-graph algorithm; pure judgement.

    briar plan next
  • Scheduler

    `briar runbook serve` reads a YAML manifest, registers every (company, task) job in an in-process scheduler, and ships every fire to the journal. Replaces cron; no systemd, no remote queue.

    briar runbook
  • Decision journal

    Every command writes an append-only session of decision events. Inspect with `briar journal show <session-id>`. The dashboard groups recent sessions by command family for fast triage.

    briar journal
  • Read-only HTML dashboard

    24 sections covering plans, journal sessions, knowledge bodies, scheduler calendar, GitHub quota, system state. Single in-process server on :8080 — safe to expose publicly because it's HTTP GET only.

    briar dashboard
  • Telemetry & secrets

    Opt-out Sentry telemetry with an allow-list scrubber (no prompts, no file contents, no ticket keys, no flag values). Credentials live in env files, AWS Secrets Manager, SSM, or Vault — your choice.

    briar telemetry

How it works

Three steps from a fresh repo to autonomous engineering.

  1. 01

    Mine your context

    Briar reads everything it can about your project — recent pull requests, open tickets, AWS infrastructure, meeting notes from the last week — and saves it as a single markdown file the agent can refer to later.

    Under the hood

    Authorize GitHub, Bitbucket, Jira, Linear, AWS, or Fireflies meetings. `briar extract` writes everything into per-company markdown knowledge files. Scopes minimal, credentials rotatable, coverage auditable.

    briar extract --company acme
    → knowledge:acme · 12 KB · 6 sections
    → ✓ github · jira · aws · meetings
  2. 02

    Build a plan from a board

    Point Briar at a Jira board or GitHub Projects view and it reads every ticket. For each one it figures out what's in scope, what's out of scope, what could go wrong — and saves a plan you can review before any code is written.

    Under the hood

    Point `briar plan build` at a Jira board or GitHub Projects v2. The synthesiser annotates every card with scope, out-of-scope, risks, and inferred dependencies. The plan is saved locally; a plan-scoped knowledge file is seeded alongside.

    briar plan build jira:KAN --name q3 \
    --company acme --llm anthropic
    ✓ 12 cards · plan:q3 · knowledge:acme.q3
  3. 03

    Run the loop — get PRs back

    Briar picks the highest-leverage ticket from the plan, clones your repo into a temp folder, writes the code, opens the pull request, and posts a summary of what changed. Then it picks the next one. Loop until your board is empty.

    Under the hood

    `briar plan run` invokes an LLM selector that reads the journal + the live knowledge file, picks the next card, hands it to the engineer agent. PR opens, knowledge file learns, loop continues until the board is done.

    briar plan run q3 --llm anthropic \
    --owner acme --repo widgets
    ✓ KAN-1 done · PR #482 · knowledge refreshed

Compose features

Real work chains a few features in one flow.

Every command does one thing — but the leverage is in chaining them: gate on credentials, mine context, act, then inspect and audit. A few worked flows:

  1. Fix a PR with infra + meeting context

    Mine AWS, recent meetings, and PR history, then let the agent address review comments with the right transcript spliced in.

    extractaws-inframeeting-digestagent prfixjournal
    briar extract --include aws-infra \
    --include meeting-digest --include pr-archaeology
    briar agent prfix --pr 128 --branch fix/login \
    --meeting fireflies --meeting-query "login retry"
    briar journal show <session-id>
  2. Ship a whole board, card by card

    Turn a Jira board or GitHub Project into an ordered plan, then run the loop — the knowledge file learns after every card.

    extractplan buildplan runcontextdashboard
    briar plan build jira:KAN --name q3 \
    --with-knowledge --llm anthropic
    briar plan run q3 --owner acme --repo widgets \
    --continue-on-failure
    briar dashboard --once
  3. Zero to first PR

    Onboard a brand-new company — credentials in, coverage proven, knowledge mined, one ticket shipped autonomously.

    authsecretsextractagent implement
    briar auth login github-pat --company acme
    briar secrets doctor --examples examples/
    briar extract --company acme --pr-repo acme/widgets
    briar agent implement --ticket-key KAN-42 --tracker jira

Five knowledge sources

Your agents are only as good as what they know.

Briar mines five real-world sources into per-company markdown knowledge files: Fireflies meeting transcripts, your live AWS topology, any number of GitHub repos, per-reviewer style fingerprints, and the full archaeology of your tracker board. Every line of every example below is what the CLI actually prints.

01 · meeting transcripts

Decisions made in standups land in the agent's prompt.

Briar's Fireflies extractor mines every meeting transcript from the last N days, distils the action items, and writes them into the company's knowledge file. When the agent later picks up KAN-7, it knows what was decided about KAN-7 last Tuesday at standup — without you ever pasting a meeting note.

fireflies → knowledge
$ briar extract --company acme \
--include meeting-digest \
--meeting fireflies --meeting-since-days 14
› fetched 12 transcripts · 4 contain decisions about ENG repo
✓ knowledge:acme · meeting-digest section: 1.8 KB
# the next agent run gets it spliced into the system prompt
$ briar agent implement --ticket-key KAN-7 ...
[INFO] knowledge spliced: meeting digest 1.8 KB · 4 transcripts

02 · live AWS topology

Your current cloud, in the agent's context window.

The aws-infra extractor walks ECS, Lambda, RDS, SQS, and CloudWatch Logs via boto3 and writes a clean markdown snapshot. When the next agent run is "scale up the payments DB", it knows there are 3 RDS instances tagged env=prod and which one matches — before it touches a console.

aws-infra → knowledge
$ briar extract --company acme \
--include aws-infra \
--aws-extract-service ecs \
--aws-extract-service rds \
--aws-extract-service sqs
› boto3: ecs.list_clusters · rds.describe_db_instances · sqs.list_queues
✓ knowledge:acme · AWS: 4 ECS clusters · 12 RDS · 8 SQS · 21 log groups

03 · other github repos

Conventions and PR patterns from every repo it touches.

pr-archaeology + codebase-conventions + github-deployments + code-hotspots mine across multiple repos at once. When the planner picks a card for acme/widgets, it already knows what shipped in acme/api last sprint, what conventions acme/billing enforces, and which files churn the most.

github (multi-repo) → knowledge
$ briar extract --company acme \
--include pr-archaeology \
--include codebase-conventions \
--include github-deployments \
--include code-hotspots \
--pr-repo acme/api --pr-repo acme/web --pr-repo acme/billing
› merged PR sample: 300 · last 30 deploys · 3 repos covered
✓ knowledge:acme · 4 sections refreshed · 11.4 KB total

04 · reviewer profiles

Reviewer-aware PRs that match each engineer's style.

reviewer-profile samples the last N PRs each top reviewer has touched and fingerprints what they care about — explicit error returns, test coverage thresholds, comment density. The engineer agent writes a PR that already matches their tastes; the pr-fixer agent knows what they'll flag next.

reviewer-profile → knowledge
$ briar extract --company acme \
--include reviewer-profile \
--reviewer-repo acme/api \
--reviewer-top-n 5 --reviewer-pr-sample 60
› fingerprinted 5 reviewers · 60 PRs sampled
✓ knowledge:acme · alice: strict-returns · bob: terse · ...
# pr-fixer reads it before drafting replies
$ briar agent prfix --pr 482 ...
[INFO] reviewer profile: alice prefers explicit error returns

05 · ticket archaeology

Past tickets teach the agent what already shipped.

ticket-archaeology + active-tickets pull both the closed history and the live backlog from your tracker. When the planner synthesises card scope for KAN-12, it cites three prior KAN-style tickets and how they were resolved — so the agent doesn't reinvent a fix you already shipped six months ago.

jira / linear → knowledge
$ briar extract --company acme \
--include ticket-archaeology --include active-tickets \
--tracker jira --ticket-archaeology-project KAN \
--ticket-max 200
› fetched 200 tickets · grouped by component + resolution pattern
✓ knowledge:acme · ticket-history: auth(12) infra(8) billing(15) ...
# planner uses it during synthesis
$ briar plan build jira:KAN --llm anthropic --with-knowledge
[INFO] synthesiser cited 3 prior KAN tickets for KAN-12's scope

Security & control

Local-first by design — and verifiable.

  • Runs entirely on your hardware

    Briar is a local Python CLI. Knowledge files live on your disk (or your Postgres). Your prompts, code, and ticket bodies never touch a Briar server because there is no Briar server.

  • Bring your own LLM credentials

    Configure Anthropic, OpenAI, Gemini, or AWS Bedrock with your own keys. The agent calls them directly from your machine. No prompts or completions transit a third-party proxy.

  • Append-only decision journal

    Every command writes a session of structured decision events to ./journal/. Inspect with `briar journal show <id>`, replay, or export to markdown. The dashboard groups recent sessions by command family.

  • Opt-out telemetry with a real scrubber

    Sentry telemetry is on by default and explicit about it. The scrubber drops prompts, file contents, ticket keys, flag values, paths, and 8 credential-shaped regexes before any event leaves your machine. Disable with `briar telemetry off` or `DO_NOT_TRACK=1`.

Frequently asked

Six questions every engineer asks before installing.

  • What does Briar actually do?

    Briar reads your engineering team's project board (Jira, Linear, or GitHub Projects), picks the next ticket worth working on, writes the code to address it, and opens a pull request for your team to review. Everything runs on your laptop — there is no Briar cloud. You install it with `pip install briar-cli`, point it at a board, and it loops: pick → code → PR → learn from the merge → pick the next one.

  • Who is this for?

    Software engineering teams that ship work from a tracker — Jira, Linear, GitHub Projects, Bitbucket Issues. The most common adopter is an engineer or team lead who wants to offload the routine "first cut" of a ticket to an agent and keep human review as the merge gate. Engineering managers like it because every Briar PR is visible in the normal review process; CTOs like it because the code never leaves the company's hardware.

  • Is my company's code safe?

    Yes. Briar runs entirely on the machine you install it on. It clones the repo locally, calls your LLM provider (Anthropic, OpenAI, Gemini, or AWS Bedrock) directly with your API key, writes the diff to your local disk, and opens the PR via the standard GitHub or Bitbucket API. No Briar server sees your prompts, your code, your tokens, or your tickets — there is no Briar server. Optional Sentry telemetry is opt-out and scrubs prompts, file contents, ticket keys, paths, and credential-shaped strings before any event leaves your machine. Disable it entirely with `briar telemetry off` or `DO_NOT_TRACK=1`.

  • Which LLM providers does Briar support?

    Anthropic, OpenAI, Google Gemini, and AWS Bedrock are the four LLMProvider adapters that ship today. Pick one with `--llm anthropic` (or the others) on every command that needs it. Override the model with `--model claude-sonnet-4-6`. Adding a fifth provider is one new adapter file under `agent/_llms/` plus a registry entry — no codebase-wide refactor.

  • How does Briar handle my code and prompts?

    Everything happens on your machine. The CLI clones the repo into a local worktree, runs the LLM call from your process with your API key, writes the diff to disk, and opens the PR via the GitHub / Bitbucket SDK. No Briar server is in the loop. Telemetry (Sentry) is opt-out and scrubs prompts, file contents, ticket keys, paths, and credential-shaped values before send.

  • Where does the knowledge live? Files or a database?

    Both, your choice. Default is the file backend — `./knowledge/<category>/<name>.md` markdown blobs. For multi-host setups, set `BRIAR_DATABASE_URL` and use `--store postgres` and the same blobs land in a Postgres table. Plan blobs (`plan:<name>`) and per-company knowledge (`knowledge:<company>` + `knowledge:<company>.<plan>` shards) share the same store; the dashboard surfaces them either way.

  • Will it work on a private repo or behind a VPN?

    Yes — Briar uses standard GitHub PATs or Bitbucket app passwords (acquired via `briar auth login`). Whatever the user running Briar can clone, Briar can clone. The agent runs in a temp worktree under `/tmp`, so private code never leaves your filesystem. AWS extractors use whatever AWS profile / SSO session is already configured on the host.

  • Can I self-host telemetry or run it without Sentry?

    Yes. Set `BRIAR_SENTRY_DSN` to your own Sentry project (self-hosted or cloud) and events route there instead of the default project. Or disable telemetry entirely with `briar telemetry off` (persisted), `BRIAR_TELEMETRY=off` (per-process), or `DO_NOT_TRACK=1` (industry-standard). Inspect what would be sent with `briar telemetry preview` before trusting it.

  • What does it cost?

    Briar itself is MIT-licensed and free: `pip install briar-cli`. You pay your LLM provider directly for tokens (Anthropic / OpenAI / Gemini / Bedrock — your API keys, your bill) and your tracker / cloud at their usual rates. There is no SaaS subscription because there is no SaaS.

Question we didn't cover? Open an issue on GitHub →

One install. Local files. No accounts.

Install, extract, plan, run. Four commands from zero to a draft PR on a real ticket.

quick-start
$ pip install briar-cli# 1. mine fresh context from your repos + tracker + cloud$ briar extract --company acme --include pr-archaeology --include aws-infra# 2. build an LLM-curated plan from a board$ briar plan build https://github.com/orgs/acme/projects/12 \    --name q3 --company acme --llm anthropic --with-knowledge# 3. let the LLM selector pick → implement → writeback, in a loop$ briar plan run q3 --llm anthropic --owner acme --repo widgets✓ KAN-1 done · PR #482 opened · knowledge:acme.q3 refreshed# 4. (optional) read-only HTML dashboard on :8080$ briar dashboard