open source · pip install briar-cli

The local CLI for engineering AI agents that ship.

Briar reads what is really going on in GitHub, Jira, Linear, your cloud and your meetings into a local knowledge store. Then it runs LLM agents that take a ticket to a draft pull request, or answer the review comments on one you already have. All on your machine, with your own keys.

View on GitHub See how it works

briar · terminalLocal

$ briar extract --company acme --include pr-archaeology
› reading merged PRs and review threads in acme-co/acme-app
✓ saved knowledge:acme
$ briar agent implement --ticket-key ACME-42 --tracker jira
› ticket-context: ACME-42 + knowledge:acme
branch chore/acme-42 · 3 files changed · tests pass
✓ draft PR #482 opened · awaiting review
$

Reads from the tools your engineers already use

GitHub
Bitbucket
Jira
Linear
AWS
GCP & Azure
Fireflies
Slack

What Briar gives you

One CLI for the full agent lifecycle.

Extract
23 extractors turn PR history, reviewer habits, CI health, tickets, cloud inventory and meetings into markdown. Agents read the parts that fit their job before they act. Run them once with briar extract, or on a schedule with briar runbook serve.
Act
briar agent implement takes a Jira, Linear or GitHub ticket to a draft PR. briar agent prfix answers the open review comments on a PR. briar plan run works a whole board, card by card.
Observe
briar dashboard serves a read-only status page. briar journal keeps every plan run: which card was picked, why, and how it ended. briar doctor tells you which config, credential or store is missing.

Under the hood

Where the knowledge comes from, and where the work goes.

Everything in the dashed box runs on your machine and reads from your tools. Agents push branches, open draft PRs and reply on reviews; their send_message tool only reaches the channels you list in the runbook.

Scroll sideways to see the whole diagram.

01Extractors read your tools, on demand or on a schedule, and write markdown knowledge to a local folder or to Postgres.
02You point an agent at a ticket or a PR. It fetches the ticket, the PR's review threads, and matching meeting notes and Slack messages live.
03In a clean git worktree it first reads the knowledge sections that fit its job (conventions, hotspots, reviewers, PR history), writes the code on a new branch and runs your tests. Coding agents run on Anthropic with your own key.
04It pushes and opens a draft PR. If you allow those channels in the runbook, it can also comment on the ticket or post in Slack or Telegram.
05You review. briar agent prfix answers the comments with one commit per thread. You merge; briar never does.
06A plan run writes what each card taught into the plan's knowledge, which its selector reads before the next pick. All knowledge also feeds Claude Code (CLAUDE.md) and any MCP client.

A day with briar

Less digging, more shipping.

Five moments from a normal day, and the command that does the digging for you. Each one assumes a .briar.toml from briar init.

09:00 · Start of the day
What is waiting on me, and is CI healthy?
```
$ briar extract --include active-work \
  --include stale-prs --include ci-health \
  --blob-name knowledge:acme.today
$ briar context get knowledge:acme.today
```
→Open PRs, the ones idle too long, and the flakiest workflows, on one page.
Instead of clicking through every repo's PR list and CI tab.
10:30 · After standup
We agreed on the fix in the meeting. Now build it.
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --meeting-query 'login retry'
```
→A draft PR built from the ticket's acceptance criteria and what was said about "login retry" in recent meetings.
Instead of re-reading the ticket and the call notes before the first line of code.
14:00 · Review came back
Comments landed on yesterday's PR.
```
$ briar agent prfix --pr 482 --branch fix/login
```
→One commit per review thread and a reply on each, pushed to the same branch.
Instead of switching back into a branch you left yesterday and fixing nits one by one.
16:00 · A production question
Which services and queues does this touch?
```
$ briar extract --include aws-infra \
  --blob-name knowledge:acme.cloud
$ briar chat
```
→A snapshot of services, databases, queues and log groups, and a terminal chat that answers from it (needs the [mcp] extra).
Instead of opening the cloud console and clicking service by service.
18:00 · Before you log off
The sprint board still has cards nobody started.
```
$ briar plan run q3 --llm anthropic --limit 3
```
→The next three cards, picked in order and worked one at a time, each ending in a draft PR. It runs on your machine, so leave it on.
Instead of starting each ticket from zero tomorrow.

Every feature

Every feature, by the problem it solves.

23 extractors read your repos, tracker, cloud and meetings into a markdown knowledge blob. Pick the ones that answer today's question: a run updates only their sections and keeps the rest. Agents look for their sections in every knowledge:acme* blob.

New to a repo?
Learn how this codebase and its reviewers work before you change anything.
```
$ briar extract --include codebase-conventions \
  --include reviewer-profile --include review-nits
```
→Language, test runner and tooling; what each top reviewer asks for; the review asks that keep coming back.
Full reference
Why is the code like this?
Get the reasons behind past changes without digging through history by hand.
```
$ briar extract --include pr-archaeology \
  --include ticket-archaeology \
  --ticket-archaeology-project ACME \
  --blob-name knowledge:acme.history
```
→Patterns from merged PRs and from closed tickets.
Full reference
Where will the next bug be?
Find the fragile parts of the code before you touch them.
```
$ briar extract --include defect-hotspots \
  --include code-hotspots --include revert-signals \
  --blob-name knowledge:acme.risk
```
→Files ranked by churn, bug fixes and size; files that always change together; areas that needed reverts or hotfixes.
Full reference
Is this repo healthy?
One look at CI, tests, dependencies and static analysis.
```
$ briar extract --include ci-health \
  --include test-discipline \
  --include dependency-health --include code-scanning \
  --blob-name knowledge:acme.health
```
→CI pass rate and flaky workflows, source files with no test, open dependency alerts by severity, open static-analysis findings.
Also: pr-hygiene, repo-governance, release-cadence, todo-density, commit-message-quality
Full reference
What is in flight?
See open work and recent decisions across repos, tracker and meetings.
```
$ briar extract --include active-work \
  --include stale-prs --include meeting-digest \
  --include active-tickets --ticket-project ACME \
  --blob-name knowledge:acme.today
```
→Open PRs, PRs idle past a threshold, open tickets, and recent meeting summaries with action items (Fireflies).
Full reference
What runs in production?
A snapshot of your cloud and deployments, without the console.
```
$ briar extract --include aws-infra \
  --include github-deployments \
  --blob-name knowledge:acme.cloud
```
→Services, databases, queues and log groups in AWS (GCP or Azure with --cloud), plus GitHub deployments and environments.
Full reference

Agents read the knowledge that fits their job before they act and work in a clean git worktree. They open draft PRs or push to yours; merging stays with a person.

A ticket is ready to build
Take a Jira, Linear, GitHub Issues or Bitbucket Issues ticket to a draft PR.
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira
```
→Reads the ticket and its acceptance criteria, codes on a new branch, runs your tests before it pushes, opens a draft PR.
Full reference
The answer is in a meeting or a Slack thread
Give the agent what was said, not only what was written in the ticket.
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --meeting-query 'login retry' \
  --slack-query 'login retry'
```
→Matching meeting transcript excerpts (Fireflies) and Slack messages go into the agent's context next to the ticket. Both searches default to the ticket key.
Full reference
A whole sprint to get through
Turn a Jira board or GitHub Project into an ordered plan and work it card by card.
```
$ briar plan build jira:KAN --name q3 \
  --llm anthropic --with-knowledge
$ briar plan next q3 --llm anthropic
$ briar plan run q3 --llm anthropic
```
→plan next says which card comes next and why. plan run works them one by one, a draft PR each, and writes what it learned back to knowledge.
Full reference

Keep a person in charge: preview before you spend, read back what happened, merge by hand.

Comments piling up on a PR
Get a first pass on every open review thread.
```
$ briar agent prfix --pr 482 --branch fix/login
```
→One commit per thread and a reply citing the commit SHA. A subjective comment gets a reply, not a commit. Never force-pushes or rebases.
Full reference
Check before you spend tokens
See exactly what the agent would get before it runs.
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --dry-run
$ briar agent prfix --pr 482 --branch fix/login --dry-run
```
→The prompt, knowledge and tools the agent would get. The LLM call is skipped.
Full reference
What did the plan run do?
Read back every decision a plan run made.
```
$ briar journal list --command plan
$ briar journal show <session-id>
$ briar journal export <session-id> --out q3.md
```
→Which card the selector picked and why, and when each card started, finished, failed or stopped. Scaffold runs are recorded too.
Full reference

Put the work on a schedule and let results reach the people who need them.

Knowledge goes stale
One YAML file per company says what to extract and how often.
runbooks/acme.yaml
```
version: 1
companies:
  acme:
    knowledge:
      name: "knowledge:acme"
    schedules:
      - task: knowledge
        every: "day at 03:17"
        extract:
          - name: pr-archaeology
          - name: ci-health
```
```
$ briar runbook serve runbooks/
```
→An in-process scheduler, no cron, writing knowledge:acme.knowledge every day, where agents find it. Without knowledge.name it writes knowledge:acme, which agents read too. runbook sweep does one pass over every file.
Full reference
The agent should report back
Name the channels an agent may post to; it gets a send_message tool for them.
runbooks/acme.yaml (under companies.acme)
```
messages:
  ticket_comment: { kind: jira-comment }
  move_ticket:
    kind: jira-transition
    config: { status: "In Review" }
  ops_chat: { kind: slack-channel }
```
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --runbook runbooks/acme.yaml
```
→The agent can comment on the ticket, move it to In Review and post in Slack. Also: GitHub or Bitbucket PR comments, Telegram.
Full reference
Know when a scheduled run fails
Send failures where someone will see them.
```
$ export BRIAR_NOTIFY_SINKS=slack,pagerduty
$ briar runbook serve runbooks/
```
→A failed runbook task sends an alert to every listed sink: Slack, email, PagerDuty or Telegram.
Full reference
One page for all of it
Watch the scheduler without reading logs.
```
$ briar dashboard --examples runbooks/
```
→A read-only page on 127.0.0.1:8080: schedulers, recent cycles, GitHub API quota, connectivity and host health.
Full reference

Plug the knowledge into the tools you already use, and keep credentials and storage where you want them.

Claude Code should know your team
Point Claude Code at the knowledge without copying it around.
```
# every extractor that can run here
$ briar extract --merge-claude-md
```
→A short knowledge index in ./CLAUDE.md, so Claude Code reads the full detail on demand.
Full reference
Use briar from any MCP client
Serve briar's own features as MCP tools.
```
$ pip install 'briar-cli[mcp]'
$ claude mcp add briar -- briar mcp serve
# or over HTTP, behind a bearer token
$ briar mcp serve --transport http --token-env MCP_TOKEN
```
→Knowledge, runbook config and extractors as MCP tools, over stdio or HTTP.
Full reference
Ask in plain words
A chat in your terminal that drives briar for you.
```
$ briar chat --llm anthropic
```
→It reads and edits knowledge, reads and changes runbook config, and runs extractors. Gated tools ask you first. Needs the [mcp] extra.
Full reference

Give the agent more tools

List extra MCP servers per company; agents bind them at run time.

runbooks/acme.yaml (under companies.acme)

mcp:
  sentry:
    transport: http
    url: https://mcp.sentry.dev/mcp
    headers:
      Authorization: SENTRY_MCP_BEARER
    purpose: "Production errors and stack traces"

$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --runbook runbooks/acme.yaml

→The agent can call Sentry next to its own bash and file tools, plus the default think and time servers.

Full reference

One knowledge store for the team
Share knowledge instead of keeping it on one laptop.
```
$ export BRIAR_DATABASE_URL=postgresql://...
$ export BRIAR_STORE=postgres
$ briar context list
```
→Every command reads and writes knowledge in Postgres, so the whole team sees the same blobs. The default is local files in ./knowledge.
Full reference
Credentials without the mess
Log in once per tool and see what is missing.
```
$ briar auth login jira-token --company acme
$ briar secrets doctor --examples runbooks/
```
→Tokens in a local env file, AWS Secrets Manager, SSM or Vault (--cred-store). secrets doctor lists what each company and extractor is missing.
Full reference

Also in the box

briar init · config show · doctor Write a .briar.toml, see where each setting comes from, check your setup.
briar scaffold implementation | pr-fixes A JSON config bundle for a downstream agent orchestrator.
briar context put | list | delete Manage knowledge blobs by hand.
--format json | yaml | csv Machine-readable output for scripts, on every command.
briar completion bash | zsh Tab completion for your shell.
briar secrets bootstrap Load credentials from a store into the environment.
briar telemetry off Turn off error and usage telemetry. Prompts, code and repo names are never sent.

See it run

What happens when you press enter.

Four pictures of the parts you will use every day, drawn from what the CLI code actually does.

Start from what you need right now and land on the exact command.

Scroll sideways to see the whole diagram.

01Want to know something about the code, the team or production? Read it once with briar extract, every day with runbook serve, from Claude Code or any MCP client, or ask briar chat.
02Want code changed? One ticket is agent implement, an open PR with review comments is agent prfix, and a whole board is plan build once, then plan run.
03Setting up or checking? briar init and briar doctor first, secrets doctor when a credential is missing, and journal list to read back what a plan run decided.

How it works

Three steps from a fresh repo to autonomous engineering.

Connect your tools

briar auth login stores each token on your machine. Your LLM key comes from the environment.

›briar auth login github-pat --company acme
›briar auth login jira-token --company acme
›export ANTHROPIC_API_KEY=sk-ant-...

02
Mine what your team knows
Extractors read PR history, review habits, code conventions and more into a knowledge blob. Agents read the parts they need before they act.
```
›briar extract --company acme \
›  --include pr-archaeology
›briar context get knowledge:acme
```
03
Point an agent at a ticket
The agent clones the repo, writes the code on a branch and opens a draft PR for your team to review.
```
›briar agent implement \
›  --ticket-key ACME-42 --tracker jira
›→ draft PR opened
```

Usage examples

What you type, and what you get back.

The main commands, in the order you would usually run them. The examples assume a .briar.toml from briar init; without one, add --company and --repo.

Set up a repo
First time in a repo. Write a config, store a token, check everything is wired.
```
$ pip install briar-cli
$ cd acme-app
$ briar init --company acme
$ briar auth login github-pat --company acme
$ export ANTHROPIC_API_KEY=sk-ant-...
$ briar doctor
```
→A .briar.toml at the repo root, so later commands need no --company or --repo, and a report of any missing credential.
Full reference
Mine what your team knows
Before an agent touches the code. Turn PR history and review habits into notes it can read.
```
$ briar extract \
  --include pr-archaeology \
  --include reviewer-profile \
  --include codebase-conventions
$ briar context get knowledge:acme
```
→A markdown knowledge blob (knowledge:acme): patterns from merged PRs, what each top reviewer asks for, and the repo's language, test runner and tooling.
Full reference
Feed it to Claude Code
You already use Claude Code or another MCP client and want it to know your team's context.
```
# write a knowledge index into CLAUDE.md
$ briar extract --merge-claude-md
 
# or expose knowledge and extractors as MCP tools
$ pip install 'briar-cli[mcp]'
$ claude mcp add briar -- briar mcp serve
```
→Claude Code reads the knowledge index from ./CLAUDE.md on demand, or calls briar's tools directly over MCP.
Full reference
Ship one ticket
A Jira, Linear or GitHub ticket is ready to work. Preview the prompt first, then run it.
```
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira --dry-run
$ briar agent implement --ticket-key ACME-42 \
  --tracker jira
```
→The agent reads the ticket and its acceptance criteria, codes on a new branch, runs your tests before it pushes, and opens a draft PR. --dry-run spends no tokens.
Full reference
Answer review comments
A PR has open review threads and you want a first pass done for you.
```
$ briar agent prfix --pr 482 --branch fix/login
```
→One commit per review thread, pushed to the same branch, and a reply on each thread with the commit SHA. No force-push, no rebase.
Full reference
Work a whole board
A sprint full of cards. Let briar pick the order and work them one at a time.
```
$ briar plan build jira:KAN --name q3 \
  --llm anthropic --with-knowledge
$ briar plan run q3 --llm anthropic --limit 3
$ briar plan status q3
```
→An ordered plan, then one draft PR per card. What each card taught goes into the plan's knowledge, which the selector reads before the next pick.
Full reference
Keep knowledge fresh
Several repos or companies. Refresh their knowledge on a schedule and watch it from a status page.
```
# one YAML per company: what to extract, how often
$ briar runbook serve runbooks/
$ briar dashboard --examples runbooks/
```
→A long-running scheduler with no cron, and a read-only dashboard on http://127.0.0.1:8080.
Full reference

Plan runs

Work a whole board, one card at a time.

briar plan build turns a Jira or GitHub Projects board into an ordered plan. briar plan run picks the next card, implements it, opens a draft PR and writes what it learned back to knowledge. briar plan status shows where every card stands.

plan acme-q3 3 cards

1 done

KAN-2 · Rate-limit the login endpoint

IN PROGRESS

chore/kan-2

implementing

KAN-1 · Move session store to Redis

DONE

chore/kan-1

PR #482

KAN-2Rate-limit the login endpoint

In Progress

Selector picked KAN-2: it unblocks KAN-3plan next

Branch pushed, draft PR openedimplement

$ git push -u origin chore/kan-2
$ gh pr create --draft --title 'KAN-2: rate-limit login'
https://github.com/acme-co/acme-app/pull/483

Your reviewPR #483

Briar opens drafts only. Nothing reaches main until a person merges it.

Security & control

Your machine, your keys, your call.

Credentials stay where you keep them
Tokens live in a local env file, AWS Secrets Manager, SSM or Vault. briar secrets doctor shows which company and extractor is missing what.
Plan runs on record
briar journal keeps every plan run, card by card: which card was picked and why, and how each one ended, so you can read it back later.
Drafts, not merges
Agents open draft PRs, and briar has no merge command: a person merges. When fixing a PR, the agent is told never to force-push, amend or rebase. --dry-run shows the prompt and tools before a token is spent.
Your own keys
Coding agents run on Anthropic with your own key; planning and chat can also use Bedrock, OpenAI or Gemini. Error and usage telemetry never includes prompts, code, ticket keys or repo names, and briar telemetry off turns it off.

Install it and point it at a ticket.

pip install briar-cli, log in to GitHub and your tracker, and let an agent draft its first PR. Docker works too, agents included: run iklob1/briar with GITHUB_TOKEN and an Anthropic key.

View on GitHub Read the docs

The local CLI for engineering AI agents that ship.

Reads from the tools your engineers already use

Extract

Act

Observe

What is waiting on me, and is CI healthy?

We agreed on the fix in the meeting. Now build it.

Comments landed on yesterday's PR.

Which services and queues does this touch?

The sprint board still has cards nobody started.

New to a repo?

Why is the code like this?

Where will the next bug be?

Is this repo healthy?

What is in flight?

What runs in production?

A ticket is ready to build

The answer is in a meeting or a Slack thread

A whole sprint to get through

Comments piling up on a PR

Check before you spend tokens

What did the plan run do?

Knowledge goes stale

The agent should report back

Know when a scheduled run fails

One page for all of it

Claude Code should know your team

Use briar from any MCP client

Ask in plain words

Give the agent more tools

One knowledge store for the team

Credentials without the mess

Also in the box

Connect your tools

Mine what your team knows

Point an agent at a ticket

Set up a repo

Mine what your team knows

Feed it to Claude Code

Ship one ticket

Answer review comments

Work a whole board

Keep knowledge fresh

plan acme-q3 3 cards

Credentials stay where you keep them

Plan runs on record

Drafts, not merges

Your own keys

Install it and point it at a ticket.