Your repo stays the record
Plans, tickets, feature contracts, quality scores, release notes, and docs live in the repo. Runtime state lives locally under MARS-owned paths.
MARS docs
MARS is a local AI product engineering team you can inspect, govern, and improve.
Give MARS a git repo and it turns product intent into plans, tickets, code, checks, reviews, releases, docs, and quality signals. It is designed for local ownership: you decide what it can read, what it can write, when it can act, and what evidence is good enough.
- Foundation runtimePlans, routes, and governs the work.
- Deployed harnessCarries project policy and role context.
- Target repositoryStores changes and durable evidence.
- Evidence feedbackImproves the next bounded delivery loop.
Why Teams Can Trust The Work
MARS is not just an agent runner. It is an operating model for an AI product team: strategy, execution, review, evidence, release, and improvement all leave durable records in git and local state.
Actions are bounded
Repo policy, role tool allowlists, blast-radius checks, secret scanning, and trust levels shape what agents can do.
Claims need proof
Commits, checks, traces, validation reports, release notes, and DocSync metadata show what changed and why it is believed safe.
You can pause or eject
Run dry checks first, pause or stop active loops, review generated files, and remove a deployed harness with an explicit dry-run first.
Ideas become plans
Goals, one active exec plan, BDD contracts, tickets, and role handoffs keep work small and inspectable.
The team learns
Scores, trust changes, telemetry, intervention work, and reusable skills turn outcomes into better future behavior.
What To Check Before You Run It
Do not choose a docs path by company type. Start with the thing you need to prove: where data lives, what agents can change, what counts as evidence, and how you stay in control.
Data boundary
What stays local?
Check runtime state, repo files, telemetry, model routes, and optional integrations.
Control
What can agents read or write?
Review role tool allowlists, guardrails, trust levels, and safe action types.
Evidence
How do you know work is done?
Follow goals, plans, BDD contracts, tickets, checks, traces, and releases.
Ownership
Which files belong to the repo?
See target harness files, local databases, logs, traces, release assets, and eject cleanup.
Safe trial
How do you try it without surprise writes?
Start read-only, use a disposable target, inspect the diff, then run one bounded slice.
Source of truth
Where is the canonical rule?
Open goals, plans, BDD contracts, tickets, design docs, runbooks, and validation reports.
Start With The Smallest Safe Action
Commands below are grouped by what they can change. If you are evaluating MARS for a team, start read-only and move to writes only after you have inspected the generated files and guardrails.
| Action type | Command | What can change | Use when | Next page |
|---|---|---|---|---|
| Read-only inspection | mars doctor --repo /path/to/repo --json | No expected target writes. | You want machine, model, database, and repo health. | Quickstart |
| Read-only inspection | mars run engineer --repo /path/to/repo --dry-run --no-init | No harness scaffold and no model call. | You want to see role context before trusting a run. | Safe inspection |
| Local machine write | mars setup | MARS local config, model, binary, and cache paths. | You are preparing the local runtime. | Install and setup |
| Target-file write | mars init --repo /path/to/repo | .harness/, AGENTS.md, docs, tickets, release files. | You are ready to add a repo-owned harness. | Target lifecycle |
| Autonomous action | mars start --repo /path/to/repo --execution-profile host --acknowledge-host-execution | May scaffold, queue roles, and later write target files with the current OS user's authority; this is not containment. | You want one repo run through the local lifecycle. Bare agent entry points default to non-mutating observer. | Operations |
| Recovery action | mars eject --repo /path/to/repo | Dry-run by default; apply removes harness files and per-repo DB. | You want to preview removal or cleanly exit. | Files and state |
Public Docs Explain. Harness Docs Decide.
This site is the front door. The durable source of truth remains in repo documents used by maintainers and agents: product specs, design docs, BDD feature contracts, goals, active plans, tickets, validation reports, runbooks, and generated references.
Source of truth:
use the documentation map when
you need to know which doc owns a rule. Entries are labelled as
public guide, product spec, design decision, BDD contract,
validation evidence, generated reference, runbook, or canonical
system record.
Start
Quickstart
Install the command, run setup, inspect the repo, and start one target safely.
Install and setup
Understand PATH setup, private-release auth, local inference, machine state, and doctor checks.
Workflows
Follow task-oriented flows for install, first target, safe inspection, review, release, and recovery.
Operate
Target lifecycle
Register, initialize, upgrade, scan, start, serve, and eject target harnesses deliberately.
Operations and observability
Run the dashboard, read status, collect evidence, inspect logs and traces, and recover from failures.
CLI reference
Use the full command reference after you know what kind of action you want to take.
Govern
Security and governance
Review local-first boundaries, credentials, guardrails, trust levels, evidence, rollback, and DocSync.
Safety, trust, and quality
Understand role autonomy, quality scores, trust progression, intervention debt, and recovery.
Files and state
See what MARS writes, owns, stores, preserves, and removes in target repos and local state.
Maintain And Extend
Planning and delivery
Follow the chain from idea to goal, plan, BDD contract, ticket, evidence, review, and release.
Tools and MCP
Expose the same MARS tool surface to agents and MCP-compatible clients with explicit trust levels.
Models and inference
Understand local model defaults, optional providers, evaluation, and explicit routing overrides.