AI delivery engine that turns Linear issues into merged PRs through a reliable multi-stage pipeline.
AI can write code. Werma makes sure it ships.
Werma is an early-alpha CLI built in Rust. It works — we use it daily to ship real code across multiple repositories — but the edges are rough and the API will change.
What it can do right now:
- Full delivery pipeline — Linear issue → analyst → engineer → reviewer → deployer → done. Each stage is an AI agent running in tmux with appropriate permissions (read-only for review, edit for code, full shell for deploy).
- Transactional outbox — External API calls (Linear, GitHub, Slack) go through a durable outbox with exponential retry and dead-letter queue. No more lost state transitions.
- Single binary + SQLite — No external services, no Docker, no Kubernetes. One Rust binary, one database file. Install and run in 30 seconds.
What you should expect at this stage: breaking changes between versions, incomplete documentation, and workflows tuned to our team's setup. We're not pretending otherwise.
We open-sourced Werma early because the best way to build developer tools is to build them with developers.
- Develop in public — AI agent orchestration is a new problem space. We'd rather iterate in the open, get feedback on real usage, and course-correct early than polish in private and ship something nobody asked for.
- Feedback over features — We have strong opinions about how AI agents should deliver code (pipelines, verdicts, outbox reliability), but we want to stress-test those opinions against teams that aren't us.
- Honest engineering — If something is broken, you can see it. If something is missing, you can ask for it. No marketing layer between the code and the people using it.
Werma's north star: make a single developer as effective as a small team by handling the delivery pipeline end-to-end.
What that looks like over time:
- Tracker-agnostic — Linear today, but the pipeline engine doesn't need to be coupled to any single tracker. GitHub Issues, Jira, and others are on the roadmap.
- Wave execution — Launch a batch of issues as a wave, track them as a unit, and get notified when the wave completes. Parallel delivery across an entire sprint.
- Agent evaluation — Built-in rubrics and golden datasets to measure agent quality, not just whether the task completed.
- Self-improving prompts — Memory and feedback loops so pipeline agents get better at your codebase over time.
None of this is in the codebase yet. It's the direction, not a promise. If any of it excites you, open an issue or start a discussion.
Download the latest binary from Releases.
cargo install --git https://github.com/RigpaLabs/werma wermaOr clone and build:
git clone https://github.com/RigpaLabs/werma
cd werma
make build-release
# Binary at engine/target/release/werma (codesigned automatically on macOS)Or manually:
cd werma/engine
cargo build --release
# macOS: codesign to prevent Gatekeeper from killing the binary (exit 137)
codesign --force --sign - target/release/werma- Rust 1.88+ (build from source)
- Claude Code CLI (agent runtime)
- tmux (agent sessions)
- macOS or Linux
# Add a task to the queue
werma add "Research best practices for error handling in async Rust" -t research
# Run the next pending task (launches a Claude Code agent in tmux)
werma run
# Run all pending tasks in parallel
werma run-all
# Check status of all tasks
werma st
# Review a pull request with an AI reviewer agent
werma review 42# Install the daemon (polls Linear, processes completions, drains outbox)
werma daemon install
# Check pipeline status — which issues are at which stage
werma pipeline status
# Manually trigger a pipeline stage for an issue
werma pipeline run RIG-42 --stage analyst ┌─────────────┐
│ Linear │ Issue tracker
└──────┬──────┘
│ poll (30s)
┌──────▼──────┐
│ Daemon │ Tick loop: poll, callbacks, effects
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌─────▼─────┐ ┌───▼───┐ ┌─────▼─────┐
│ Pipeline │ │ Queue │ │ Effects │
│ Callback │ │ │ │ Outbox │
└─────┬──────┘ └───┬───┘ └─────┬─────┘
│ │ │
│ ┌─────▼─────┐ │
└─────►│ Runner │◄────┘
└─────┬─────┘
│ spawn
┌─────▼─────┐
│ tmux │ Isolated agent sessions
│ sessions │ (one per task)
└───────────┘
Issues flow through a YAML-configured pipeline. Each stage runs a specialized agent:
| Stage | Agent Type | What It Does |
|---|---|---|
| Analyst | read-only | Writes technical spec, sets labels |
| Engineer | edit | Creates branch, writes code, opens PR |
| Reviewer | read-only | Reviews PR on GitHub, approves or requests changes |
| Deployer | full (shell) | Merges PR, triggers deploy, runs health checks |
Each agent emits a verdict on its last output line (e.g., VERDICT=DONE, REVIEW_VERDICT=APPROVED). The pipeline engine parses verdicts and transitions issues to the next stage automatically.
| Agent | Role | Personality |
|---|---|---|
| Watchdog | Infrastructure guardian | Silent sentinel, alerts only on problems |
| Analyst | Technical research & specs | Methodical researcher, thorough documenter |
| Engineer | Implementation | Pragmatic builder, clean code advocate |
| Reviewer | Code review | Sharp-eyed critic, fair but demanding |
| QA | Quality assurance | Meticulous tester, no shortcuts |
| DevOps | Deploy & monitoring | Calm operator, safety-first |
| Type | Permissions | Use For |
|---|---|---|
research |
Read-only | Research, documentation, analysis |
analyze |
Read-only | Code review, audits, specs |
code |
Edit files | Writing/modifying code |
full |
Edit + shell | Deploy, infra, anything needing bash |
Werma stores runtime data in ~/.werma/:
~/.werma/
├── werma.db # SQLite database (tasks, effects, schedules)
├── config.toml # User configuration (optional)
├── .env # Credentials (LINEAR_API_KEY, etc.)
├── logs/ # Per-task agent logs + daemon.log
└── backups/ # Automatic DB backups
Copy .env.example to ~/.werma/.env and fill in your keys:
| Variable | Required | Description |
|---|---|---|
LINEAR_API_KEY |
For pipeline | Linear API key for issue tracking |
WERMA_LINEAR_WORKSPACE |
No | Linear workspace slug — enables Linear links in auto-created PRs |
SLACK_BOT_TOKEN |
No | Slack bot token for notifications |
GITHUB_TOKEN |
No | GitHub token for self-update / private repos |
The pipeline config is compiled into the binary (engine/pipelines/default.yaml). To inspect it:
# View the current pipeline stages and transitions
werma pipeline show
# Validate the config
werma pipeline validateTo customize stages, edit engine/pipelines/default.yaml and rebuild.
External side effects (Linear state changes, GitHub PR creation, Slack notifications) are processed through a durable outbox:
# List pending and failed effects
werma effects
# Show dead-lettered effects (exhausted retries)
werma effects dead
# Retry a failed effect
werma effects retry <id>Effects use exponential backoff (5s → 30s → 120s → 300s → 600s) and are classified as blocking (must succeed for pipeline to continue) or best-effort (retried independently).
Run tasks on a cron schedule via the daemon:
# Add a daily research task
werma sched add daily-review "0 9 * * 1-5" "Review open PRs and summarize status" --type research
# List schedules
werma sched ls
# Enable/disable without deleting
werma sched on daily-review
werma sched off daily-reviewSee CONTRIBUTING.md for development setup, conventions, and workflow.
make check # fmt, clippy, test — all in oneWerma (ཝེརམ) means "warrior spirit" in the Bon tradition. They protect, execute, and maintain order. This tool embodies the same principle: reliable execution of well-defined tasks, with clear boundaries and accountability at each stage.