TARS 恢复开发并发布 v0.54.0，本地 AI 智能体运行时打包为单个 Go 二进制

TARS is a local AI agent runtime that runs on your machine, under your control.

Homepage: tars.marvin-42.com — project overview, features, and quickstart.

Important

Development resumed. TARS is no longer archived. Latest tagged release is v0.54.0 (2026-10-08). The narrower console navigation described below shipped in v0.36.0. This README tracks main; see the changelog for tagged-release behavior.

TARS is a local agent runtime for people who want an inspectable AI workbench without handing workspace control to a hosted service. It packages a browser console, API server, CLI, background jobs, memory, and extension system into one Go binary.

The core promise is direct control:

• Run agent chat, subagents, cron jobs, watchdog checks, and reflection on your own machine.
• Inspect sessions, tool calls, memory candidates, run history, approvals, usage, logs, and config from the console.
• Route work across heavy, standard, and light model tiers with role-level defaults and traceable runtime logs.
• Extend behavior with skills, companion CLIs, plugins, MCP servers, Telegram, webhooks, and local APIs without bloating the default prompt.

The name comes from the TARS in Interstellar — practical, direct, dependable when things get complicated. TARS aims for that. Not affiliated with the film; the name is borrowed.

Comparison

Verified on 2026-08-02 from official project documentation and release pages. OpenClaw v2026.7.2-beta.6 capabilities are treated as pre-release, not stable. See the status-separated market scan and reproducible evaluation baseline for sources, limitations, and the TARS evolution roadmap.

Key Features

Public Agent Packages

Public packages under pkg/ turn the runtime primitives into a small Go agent-building kit. Lightweight apps can reuse provider-normalized LLM contracts, the tool registry, the iterative agent loop, memory helpers, skill loading, and MCP adaptation without copying internal/ code.

• pkg/llm, pkg/tools, and pkg/agentloop are the core loop: provider client, registered tools, and tool-calling iterations.
• pkg/memory, pkg/skill, and pkg/mcp expose the first helper surfaces for durable memory, SKILL.md loading, and MCP tool adaptation.
• examples/min-agent shows the minimal no-network composition, while docs/public-agent-packages.md documents package boundaries and what still intentionally remains internal.
• That page also carries the stability policy: which packages are stable versus experimental, what deprecation means here, and how a breaking change is caught. The surface itself is checked in at docs/public-api-surface.txt and diffed in CI, so a change to what consumers can rely on shows up in review.

Chat + Memory

The primary interface is the browser console at http://127.0.0.1:43180/console.

• Multi-session chat with tool-calling loops, session search, pins, archives, cleanup review, and message-level forks.
• Dockable panels for sessions, files, terminal, Git inspection, Changes, tool calls, prior context, Tasks, Session Health, and session-specific policy.
• Durable memory through MEMORY.md, reviewed experiences, daily logs, semantic search, structured compaction, and a Memory Inbox review queue.
• Explicit context injection through @ file/directory mentions, / command autocomplete, and user-invocable skills.
• Configurable system prompts through USER.md, IDENTITY.md, AGENTS.md, and TOOLS.md.
• A locale-aware companion surface for Poke, Suggest, Feedback, runtime signals, and bounded handoff into Chat.

See docs/console.md for the detailed console page and panel inventory.

Native exec uses POSIX shell syntax for quoted arguments, pipes, redirects, and chained commands in both foreground and background runs (Git sh/bash on Windows). Existing tool approvals still apply; shell command validation is defense in depth, not a sandbox. Tool cards show exit status and error output, and follow-up messages added after reconnecting to a running turn continue automatically when that turn finishes.

Durable Work Ledger

TARS opens a local SQLite Work Ledger at workspace/_shared/work-ledger/work-ledger.db. Versioned Work, Step, Attempt, Event, Approval, Artifact, Proof, CapabilityVersion, EvaluationRun, and CapabilityOutcome records use workspace-scoped idempotency keys and transactional state transitions. SQLite runs in WAL mode with foreign keys, full synchronous writes, checksummed migrations, and indexed read projections.

During the compatibility window, startup imports existing Session Goal/Plan/Task/Contract/Evidence and Agent Runtime runs.json records without deleting or rewriting those files. Session task saves and Agent Runtime snapshots append new ledger revisions; existing task/run API shapes read the latest projection with a legacy fallback.

The durable dependency scheduler is on by default (work_ledger.scheduler.enabled) and runs whenever Agent Runtime is enabled; without Agent Runtime the server starts and the scheduler stays off. subagents_orchestrate calls submit the complete DAG, return a work_id, and continue independently from the originating request. Atomic leases and heartbeats prevent duplicate valid claims; recovery reconnects supported Agent Runtime attempts or deterministically reclaims them into the configured retry, replan, decompose, review, or blocked policy. Scheduled attempts execute through native Agent Runtime in the configured workspace. Mutating local tools write pending and committed effect receipts around invocation, so checkpoint replay can suppress a completed effect and require a human decision for an ambiguous unsafe effect. Proof-gated Steps record worker output as reported, run declared command/artifact/HTTPS verification under a separate identity and environment, and stop in review or blocked when evidence is missing, failed, or stale. The Tasks timeline follows scheduler events live and allows an operator to cancel work or resume a reviewed/blocked step with a durable reason.

Set work_ledger.enabled: false (or TARS_WORK_LEDGER_ENABLED=false) and restart to stop ledger writes and return readers to the untouched legacy stores. The SQLite database is retained for inspection or recovery. See Work Ledger operations for backup, JSONL export, restore, doctor, quarantine, and preview rollback procedures, checkpoint recovery for retry/replay/resume semantics, independent proof verification for proof policies, provenance, freshness, and deterministic verifier limits, and reviewed self-improvement for capability evaluation, approval, rollout, regression review, and rollback.

Sub-Agent Orchestration

Spawn read-only agents for research, planning, and specialized tasks:

# workspace/agents/explorer/AGENT.md
---
name: explorer
tier: light
tools_allow: [read_file, list_dir, glob, memory_search]
---

Use subagents_run when tasks are independent and can fan out in parallel:

{"tasks": [
  {"prompt": "find all API endpoints", "tier": "light"},
  {"prompt": "design the migration plan", "tier": "heavy"}
]}

Use compare mode when 2-3 safe subagents should inspect the same prompt independently and TARS should keep their outputs side-by-side:

{"mode":"compare","tasks": [
  {"agent": "explorer", "title": "Explorer pass", "prompt": "find the root cause"},
  {"agent": "reviewer", "title": "Reviewer pass", "prompt": "find the root cause"}
]}

In Console Chat, subagents_run renders as a progress card with running/completed/failed counts, elapsed time, compact task titles, and direct links to each Agent Runtime run once they are available. Compare-mode results add common findings, conflict candidates, sourced evidence snippets, and side-by-side output panes.

Advanced staged-flow tools are available only when explicitly allowed for a session: subagents_orchestrate runs dependency-aware parallel / sequential steps, and subagents_plan uses the heavy-tier planner model to draft such a flow. With the durable scheduler enabled, orchestration is projected directly from the Work Ledger instead of independently mutating the legacy session task mirror. With it disabled, the existing request-bound implementation and task mirror remain available as the rollback path.

Experimental consensus mode remains hidden from the default subagents_run schema unless agentruntime.consensus.enabled is explicitly set.

Tier resolution priority: task tier > agent YAML tier > config default.

The Console Agent Runtime page keeps run history, run topology, event replay, versioned recovery checkpoints, explicit Retry/Replay/Resume actions, checkpoint safety decisions, cost/token flow, file attention, git diff attribution, and subagent profile management in one operational surface. See docs/console.md, checkpoint recovery, and docs/tutorials/22-agentruntime.md for details.

3-Tier Model Routing

Route workloads to different models for cost and quality optimization:

# tars.config.yaml
llm:
  providers:
    default:
      kind: anthropic
      auth_mode: api-key
      api_key: ${ANTHROPIC_API_KEY}
  tiers:
    heavy:
      provider: default
      model: claude-opus-4-6
    standard:
      provider: default
      model: claude-sonnet-4-6
    light:
      provider: default
      model: claude-haiku-4-5
  default_tier: standard
  role_defaults:
    pulse_decider: light
    agentruntime_planner: heavy

System roles such as chat, pulse, reflection, compaction, cleanup, and agent runtime agents map to tiers. Background work defaults to light, Chat can recommend a tier before the first expensive turn, and runtime logs record the resolved role, tier, provider, model, and source for traceability. Tier bindings and providers can be edited directly in Settings; the onboarding wizard remains available for guided setup. Search or filter settings, edit typed fields or advanced JSON, then choose Save or Save and apply. Saved YAML, environment-effective values and running values are shown separately. Applying changes that require a server restart asks for explicit confirmation and checks the new runtime after reconnecting. Masked or omitted provider credentials are preserved; environment overrides remain authoritative.

Background Surfaces

Two isolated surfaces run independently from user chat:

• Pulse — 1-minute watchdog scanning cron failures, stuck runs, stalled chats, disk pressure, Telegram delivery health, and reflection status. LLM classifier picks ignore / notify / autofix. The Console renders recent signals as incident cards with likely cause, evidence, recommended action, safe navigation, and re-check controls, while repeated chat-attention notifications are grouped with occurrence counts instead of inflating unread rows. Autofixes are whitelisted in config, cleanup-like autofixes are opt-in, and stalled-chat continuation requires per-session auto-resume consent.
• Reflection — Nightly batch (default 02:00–05:00) running memory reflection (Memory Inbox candidate extraction) and stale empty-session pruning.

Both use the light tier by default and have no access to user-facing tools (enforced at compile time via RegistryScope).

Scheduling

Native cron with session binding:

• Cron expressions and one-shot at: schedules
• Session-bound jobs inherit the session's tool policy, work dirs, and prompt override
• Audit logs: artifacts/<session_id>/cronjob-log.jsonl
• Console Cron page for global job management plus per-session Cron tabs in chat context

Channels

Multi-channel I/O beyond the web console:

• Telegram — Bidirectional messaging with pairing-based access control
• Webhooks — Inbound HTTP triggers for external integrations
• Assistant — macOS popup and voice helpers that share the core ~/.tars/workspace default unless overridden
• Local — Direct API calls for scripts and automation
• Remote Access — Tailscale Serve can publish the loopback-only console over tailnet HTTPS with a TARS-owned target, while browser sessions use admin/user password auth and remote/mobile logins stay user-scoped.

Embodiment

TARS has a core embodiment subsystem for body providers. The shipped default is enabled: false with no providers, so existing chat/runtime behavior is unchanged and no LLM tools are registered. When enabled, known providers can post Percepts; owner audio becomes an autonomous directive turn, while ambient/stranger observations stay non-triggering by default. Cognition turns can emit structured tars-body-action blocks, which TARS routes back to the bound provider only when the provider declares the matching capability.

In the Console, open Settings and use the Quick Start Embodied Bot and Embodied Bot providers cards to edit the same settings without switching to raw YAML. The providers card opens a structured form with Mac Host, StackChan, and Custom presets, field hints, and grouped capability toggles. For MCP providers, endpoint must match an mcp.servers key from the companion server config.

embodiment:
  enabled: true
  providers:
    - name: stackchan
      enabled: true
      transport: mcp
      endpoint: tars-stackchan
      capabilities: [vision, hearing, speech, expression, motion, led]
      session_id: sess_main
      owner_only_directive: true
      min_trigger_interval: 30s
      max_triggers_per_hour: 60
    - name: host
      enabled: true
      transport: mcp
      endpoint: tars-stackchan-host
      capabilities: [hearing, speech]
      session_id: sess_main
      owner_only_directive: false
      trigger_observations: true
      min_trigger_interval: 30s
      max_triggers_per_hour: 60

Providers may also use the existing webhook inbox path /v1/channels/webhook/inbound/{provider} or the direct percept path /v1/embodiment/percept/{provider}. TARS persists the Percept in the channel inbox first, then routes self-sensory Percepts through the embodiment gate and agent runtime. Successful percept intake also publishes an ephemeral live Console companion signal so camera and microphone providers can make the pet react without creating desktop notifications. Body actions map to provider capabilities (speak → speech, express → expression, move → motion, led → led); unsupported capabilities are dropped gracefully instead of failing the cognition loop. MCP providers receive actions through their existing MCP server, so this does not add any built-in LLM tool surface.

Remote Access

TARS can expose the local console to your phone or another trusted device through Tailscale without binding the server to 0.0.0.0.

# Create or rotate console passwords
tars auth init
tars auth passwd admin
tars auth passwd user

# Publish the loopback console through Tailscale Serve
tars remote status
tars remote enable
tars remote url

Remote Access requires api_auth_mode: required, configured admin/user passwords, and a logged-in Tailscale client. The Settings page shows both the saved YAML value and the effective runtime value when environment variables override config, so a local dev launch such as TARS_API_AUTH_MODE=off is visible before enabling remote access.

Computer Use

computer_use is enabled by default and drives a desktop app toward a one-sentence goal. Each step reads the window's accessibility tree through cua-driver, asks the existing LLM router's computer_use role (default: light) for one structured action, validates it, and observes the next screen after acting. It reuses your configured provider credentials; calls count toward that provider's billing or subscription limits. No separate Jev key is needed. Text to type is passed as named inputs; only the key names reach the model. Risky actions and secure-field typing pause with needs_confirmation until you answer. Screen text goes to the configured LLM provider. Install and start cua-driver and grant its OS permissions; without a driver the tool returns unavailable with setup guidance. tars doctor checks the driver and selected backend. The native driver path is supported on macOS; other platforms still need verification.

Set tools.computer_use.enabled: false to disable it. To use Jev instead, set tools.computer_use.backend: jev and configure jev.base_url plus jev.api_key for hosted Jev (or a local compatible server). Jev keeps its probability-based gates; LLM decisions use schema validation, confirmation, and post-action observation rather than generated confidence numbers. Override llm.role_defaults.computer_use to select a different tier. The antigravity-cli provider cannot disable its built-in tools for decision-only calls and is unavailable for this role; use another tier/provider or Jev.

Extensibility

TARS favors on-demand extension over always-resident tool registrations. Domain-specific capabilities are shipped as skills (plus optional companion CLIs) from the Skill Hub rather than compiled into the TARS binary — this keeps the chat system prompt small no matter how many capabilities a user installs.

• Skill Hub — Public registry of skills, plugins, MCP servers, and domain packs. Install individual packages with tars skill install <name>, tars plugin install <name>, tars mcp install <name>, or install a reviewed bundle with tars pack install <name>. Skill, plugin, MCP, and pack member installs/updates are first materialized in a temporary workspace and sandbox-validated before the real workspace/skills/<name>/, workspace/plugins/<name>/, workspace/mcp-servers/<name>/, or skillhub.json changes. Hub entries can publish quality metadata such as score, last update, passing tests, required tools, permissions, companion CLI presence, and install count; the Extensions console renders these trust signals before install. Update commands report updated, skipped, and failed entries so failed package refreshes are visible. The hub is the first place to look before writing a new capability, and the only place to publish one.
• External skill hubs (federation) — tars skill also federates across external MIT-compatible hubs. Pass --from <hub> to install from openclaw (steipete/openclaw), hermes (NousResearch/hermes-agent), or anthropic (anthropics/skills). External installs always preview first (--dry-run or the console hub-selector + dry-run modal showing per-file sha256, adapter warnings, and the ATTRIBUTION notice), generate an ATTRIBUTION.md carrying the source's license body and copyright, and refuse to materialize source-available content (Anthropic's docx/pdf/pptx/xlsx skills are blocked at the attribution layer). Both tars skill search (no --from) and the console Hub Skills list span every registered source. See docs/tutorials/14-skill-hub.md for the federation architecture.
• Skills — Markdown instruction files (YAML frontmatter + body) with optional companion scripts. A skill's frontmatter can set recommended_tools: [bash], slash: /name, aliases: [...], and smoke_tests: [...]; users can invoke eligible skills directly from chat via /name autocomplete. Companion CLIs keep their interface out of the system prompt until the skill itself is picked. The Chat Skill Inbox extracts reusable candidates and preserves provenance, evidence, and success/failure/dead-end/correction signals, but it no longer writes an active skill on approval. Candidates advance through sandbox, offline, shadow, human approval, and canary gates; only an explicit promotion atomically activates workspace/skills/<name>, and one action restores the previous known-good version. The Extensions console can also draft, sandbox-test, and save explicitly authored local skills before publishing to the hub, and shows sandbox pass/fail reports for hub skill installs. See daily-briefing in the hub for the canonical pattern.
• Plugins — Advanced packages that bundle skill directories and optional MCP server declarations with manifest metadata and runtime gating. Plugin-declared MCP servers are disabled by default and require extensions.plugins.allow_mcp_servers: true before they can launch. Built-in Go plugins and plugin HTTP routes are not an active extension surface.
• MCP — Configured, hub-installed, or plugin-declared local stdio and remote HTTP/SSE/WebSocket servers with bearer or OAuth auth. Use MCP for third-party integrations that cannot be expressed as a CLI the bash tool can call. The Extensions console can draft, stdio-test, save, diagnose, and repair local workspace/mcp-servers/<name>/ MCP packages before you publish them to the hub.
• Browser — Playwright-based automation for web interaction (shipped as a hub plugin).
• Per-project overrides (.tars/) — Run tars init local --cwd <project> or drop a .tars/settings.json (team-shared, commit it) plus .tars/settings.local.json (per-user, gitignore it) under the chat session's active working directory and TARS will fold those values into the session's tool_config / prompt_override for chats run in that directory. A sibling .tars/skills/<name>/SKILL.md adds full project-only skills that the LLM can select automatically, while .tars/commands/<name>.md adds standalone slash-command prompts that only run when the user explicitly invokes /name. The project_skill built-in tool can create both forms in the active cwd, and the Session Config panel reloads, enables, disables, and persists session-local choices to .tars/settings.local.json; custom local tool, skill, command, and MCP lists replace inherited project allowlists so per-user narrowing is effective. The active cwd is shown as an amber chip in the chat header (or via /cwd); merged values render with a shared / local source badge in the Session Config panel. The whitelist is narrow on purpose — credentials, hooks, and arbitrary binary paths are blocked at load time. See CLAUDE.md for the full schema.

The Extensions console validates MCP draft names before requesting generated files, so incomplete drafts stay local to the form instead of sending avoidable server requests.

When to build a hub skill vs. a core feature: if the capability is domain-specific (one site's logs, one vendor's API, one workflow), it belongs in tars-skills as a skill + CLI. Builtin tools inside this repo are reserved for universal surfaces (file ops, memory, agent runtime, channels) that every session uses.

Install

Homebrew:

brew tap devlikebear/tap
brew install devlikebear/tap/tars                  # server + CLI
brew install --cask devlikebear/tap/tars-desktop   # desktop app (macOS); pulls in the server too

On macOS, choose Start server from the desktop tray menu when the server is not running. This installs the service and starter workspace if needed. Version 0.43.4 fixes server discovery on case-insensitive volumes, where the app could mistake its own TARS executable for the tars server.

The setup wizard detects locally installed Claude Code and Codex sign-ins. A single ready provider fills the empty first-run form automatically; when both are ready, choose one. Claude model tiers use opus / sonnet / haiku, and Codex recommendations come from the live provider catalog with cached fallback. The setup model-source label identifies live provider catalogs, cached recommendations, bundled fallbacks, and Claude CLI aliases. Missing tools show installation or sign-in instructions. Existing settings and manual entries are preserved, and changes are saved only after review. Codex currently requires credentials readable from its file-based login; a keychain-only CLI login is shown as needing a compatible sign-in.

Curl:

curl -fsSL https://raw.githubusercontent.com/devlikebear/tars/main/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/devlikebear/tars/main/install.ps1 | iex

This installs tars.exe into %LOCALAPPDATA%\Programs\TARS and adds that folder to your user PATH. No administrator rights are needed. To install the desktop app into the same folder as well, and start it in the tray when you sign in, pass options:

& ([scriptblock]::Create((irm https://raw.githubusercontent.com/devlikebear/tars/main/install.ps1))) -Desktop -StartAtLogin

Both archives are checked against the release's checksums.txt first. Running the script again updates an install in place, even while the server or the app is running; restart them to use the new version. Windows has no tars service, so the desktop app starts tars serve for you, or run it yourself.

Updating: tars update replaces an install.ps1 or install.sh install with the latest release, checks it against checksums.txt, and restarts the server running on --server-url onto it (--check only reports, --yes skips the question, --admin-api-token is needed when the server requires auth). The desktop app does this by itself on Windows and macOS: it checks every six hours and updates the server only while no chat is running and nothing waits on an approval. When a newer app is out, it tells you; click the notification to install it. Homebrew installs update with brew upgrade, which the macOS desktop app runs for you and then restarts the service.

Quick Start

# Initialize workspace and config
tars init

# Start the server (it boots in setup-only mode if no LLM is configured yet)
tars serve

# Open the web console — the onboarding wizard runs automatically when needed
tars

On first run, if ~/.tars/config/config.yaml has no llm_providers / llm_tiers, the server boots in setup-only mode: only the wizard endpoints + /console are active and tars api serving on … (setup-only mode) is printed to stdout. Open http://127.0.0.1:43180/console, the SPA detects needs_setup=true from /v1/healthz, and walks you through provider setup, heavy/standard/light tier binding, optional Tailscale Remote Access, then save & restart. The wizard is also re-runnable later from the Settings page (/console/config → "Re-run setup wizard") if you need to swap providers, tweak tier bindings, or enable remote access later.

To skip the wizard and edit by hand, set credentials directly and validate:

export ANTHROPIC_API_KEY="your-key"   # or OPENAI_API_KEY, etc.
# Edit ~/.tars/config/config.yaml under llm.providers / llm.tiers
tars doctor --fix
tars serve --config-check              # exits 1 in setup-only mode

On macOS, tars service install && tars service start manages tars serve as a LaunchAgent. Once a plist exists, tars service start, stop, and status keep working from the plist and launchctl state even if the config needs repair.

When TARS is exposed behind a reverse proxy path, pass that base path in --server-url; CLI API calls and the console opener resolve /v1/* and /console from the same base.

For local console development, set TARS_CONSOLE_DEV_URL=http://127.0.0.1:5173 while Vite is running. The dev proxy keeps Vite assets, HMR, and favicon requests mounted under /console.

Console Pages

The console runs at http://127.0.0.1:43180/console. The sidebar groups daily pages under Work, Build, and System (regrouped on main after v0.37.1; tagged v0.37.1 and earlier still show Work / Operate / Setup). Mission Control remains the landing route. The footer keeps server, Pulse, Reflection, and active session status visible with direct jumps to each detail page. ⌘K opens the command palette for every route, including ones hidden from the sidebar.

These routes stay reachable through ⌘K and in-context links (not listed in the sidebar):

The narrowing is recorded as normative policy in frontend/console/DESIGN.md (Console Purpose & Surface Policy). Detailed console behavior, panel inventory, localization, usage budget chips, and frontend API type policy live in docs/console.md and docs/frontend-api-types.md.

Screenshots

Captured from a running tars serve built from an August 2026 snapshot of main — one per sidebar page, in the order the sidebar lists them. The workspace is a throwaway one, so the counters are small. (The sidebar footer in that snapshot still showed v0.35.0; current VERSION.txt is 0.53.0.)

Chat — /console/chat

Panel tabs across the top dock Sessions, Files, Git, Tasks, Health and the rest beside the transcript; the header carries session health and the active working directory.

Approvals — /console/approvals

The review queue, with what puts something in it and what each decision does. Remote execution sits on the same page, reporting disabled because it is off by default.

Logs — /console/logs

File, level, component, and line count are all filters; any line expands to the raw JSON record behind it.

Pulse — /console/pulse

What the watchdog watches and what it is allowed to do about it. The counters are live: this run classified a disk-pressure signal as notify rather than autofix.

Settings — /console/config

Quick Start, and only Quick Start. Each card is one gate between you and a working install, with a readiness badge and a note when the change needs a restart.

Requirements

• Go 1.25.6+ (for building from source)
• LLM provider credentials (Anthropic, OpenAI, Gemini, or Claude Code CLI)
• Optional: Gemini API key for semantic memory embeddings
• Optional: Node.js for Playwright browser automation

Build

make build-bins
bin/tars version

For development with hot-reload:

make dev-console    # Vite (5173) + Go API (43180), open http://127.0.0.1:43180/console

For pull-request preflight checks:

make ci-static-analysis-check
make lint-diff
make test-cover-diff
cd frontend/console && npm run check && npm run test:ci

Documentation

• Project homepage
• Getting Started
• Console Guide
• Plugin and MCP Packaging Guide
• Contributing
• Changelog

Status

Development resumed. TARS is no longer archived and development has resumed. Latest tagged release is v0.54.0. TARS is pre-1.0; see the stability policy for the public pkg/ API guarantees.

Module path: github.com/devlikebear/tars. MIT licensed. Contributions are welcome; see Contributing.