An agentic coding philosophy. One conversation. Full control.
💡 Philosophy • 📖 Docs • 🚀 Quick Start
The best orchestrator for Claude is Claude.
Bearing is not an orchestration framework. It's infrastructure that enables Claude to orchestrate itself.
Claude orchestrates, not Bearing. You work in one conversation with one Claude agent. When you ask for parallel work, Claude decides how to delegate to background sub-agents. Bearing just provides the isolation (worktrees) and state (JSONL files) so those agents don't conflict.
Infrastructure, not framework. Bearing provides:
- Worktree management — Isolated directories so parallel agents don't conflict
- Plan visualization — TUI to see all plans across repos
- State sync — JSONL files synced to GitHub issues for persistence
- Query tools — CLI commands agents can use to understand workspace state
- Hooks — Feed context to Claude Code agents automatically
File system as interface. Your workspace is laid out for parallel work — worktrees for isolation, JSONL files for state, plans/ for tracking work. No databases. No services. Just files that Claude can read and write.
Pattern over product. Bearing is more of a philosophy than a tool. We provide utilities (CLI, TUI, daemon) but the core idea is the workflow pattern itself. Fork it. Adapt it. Make it yours.
- No contention — Background agents work in isolated worktrees
- No context bloat — State lives in files, not your conversation
- Full visibility — See all active work in one place
- Orchestrate everything — From one conversation, coordinate many
Browse all your projects and worktrees. See health status at a glance. Vim-style navigation.
git clone https://github.com/joshribakoff/bearing ~/Projects/bearing
~/Projects/bearing/install.sh> Create a worktree for the auth feature
> Kick off a background agent to refactor the API
> What's the status of my parallel tasks?
> Clean up the merged feature branch
That's it. Bearing integrates with Claude Code's hooks. You orchestrate from one conversation — the agent handles the rest.
~/Projects/
├── 📦 myapp/ # Base folder (stays on main)
├── 🔀 myapp-feature-auth/ # Worktree for auth
├── 🔀 myapp-fix-bug-42/ # Worktree for bug fix
├── 📦 api-server/ # Another project
├── 🔀 api-server-graphql/ # Its worktree
└── 📄 workflow.jsonl # Tracks all active work
Base folders stay on main. Worktrees are isolated per task.
| Command | What it does |
|---|---|
bearing worktree new myapp feature |
Create a worktree |
bearing worktree list |
See all worktrees |
bearing worktree cleanup myapp feature |
Remove after merge |
bearing worktree status |
Health check (dirty, PRs) |
bearing plan sync |
Sync plans to GitHub issues |
bearing-tui |
Launch the terminal UI |
Keep markdown plans synced with GitHub issues:
bearing plan sync --project bearing # Sync all bearing plans
bearing plan push plans/myapp/001.md # Push single planPlans live in ~/Projects/plans/<project>/ with frontmatter:
---
issue: 42
repo: myapp
status: active
---
# My Plan Title| Key | Action |
|---|---|
0-2 |
Focus panel (projects/worktrees/details) |
j/k |
Navigate up/down |
h/l |
Navigate left/right |
p |
Browse plans |
o |
Open PR in browser |
r |
Refresh data |
? |
Show all keybindings |
q |
Quit (saves session) |
Session is persisted across restarts (project, worktree selection, focused panel).
- 📖 Full Documentation — Complete guides and reference
- 📝 Blog Post — The philosophy behind Bearing
- 🐛 Report Issues — Help us improve
⚠️ Fair Warning: This thing was vibe-coded in an afternoon, rewritten in Go the same day, and had a TUI bolted on for good measure. The AI agent that built it dangerously skips permissions and merges its own PRs. Depend on it at your own peril. 🏴☠️
One conversation. Many agents. Full control.