Build.
Start local. Install the CLI, claim one bounded work item, attach evidence, release it, and inspect the close record. Then see how that same packet survives handoff, review, and later reuse.
From concept to one portable packet.
Motus is not asking you to learn random commands. Each command pins one part of the work packet so the work can survive handoff, retry, review, and later inspection.
I understand the concept. Now I want to know what each step buys me.
Use the site in this order.
If you are new to Motus, do not try to memorize every term at once. Start with the first loop on this page, then use the other pages when you need more precision.
I need to know where to start, what to read next, and what each page is for.
What you need.
Python 3.9+, git, and a repo. That is it.
Motus does not replace your stack. It does not require a hosted account, a service boundary, or a new database. Contracts live in your repo. Receipts export as JSON. The CLI runs locally.
You choose where data lives. You choose what to surface. You choose how to integrate. This is ownership by design, not missing features.
Get the CLI.
Install the CLI, install Motus defaults, then init in your repo. If it is not useful, you can stop here without unwinding a hosted tooling decision.
One command. If it breaks, I have not lost anything.
# install the CLI $ pip install motusos $ motus --help # install Motus defaults $ motus install # init in your repo $ cd your-repo $ motus init --lite --path . $ motus doctor
Claim, evidence, release.
One workflow end to end. This is the pattern you will repeat for every bounded unit of work whether the actor is you, CI, or an agent.
I want to see the full loop before I customize anything.
# set your agent ID
$ export MC_AGENT_ID=you-local
# claim work (day1 ad hoc)
$ LEASE_ID=$(motus work claim ADHOC-DAY1-001 --intent "Day1 smoke" | awk -F': ' '/^Lease ID:/ {print $2}')
# make your change, then attach evidence
$ motus work evidence "$LEASE_ID" test_result --passed 1 --failed 0
# inspect the active packet before close
$ motus work status "$LEASE_ID" --json
# release
$ motus work release "$LEASE_ID" success
Lease means temporary ownership, not bureaucracy.
The lease is the active handle for one attempt at one work item. It prevents hidden parallel ownership and gives evidence and close decisions one place to attach.
If the work changes hands, the handoff moves with it. If the work closes, the lease ends and the close record is explicit. That is what keeps the packet portable instead of fragile.
# what claim gives back
{
"decision": "GRANTED",
"reason_code": "GRANTED_OK",
"lease_id": "lease-20260403-360e8b5e",
"message": "Access granted."
}
Motus leaves concrete local surfaces behind.
The first run should produce visible state you can point to. If you cannot show the lease, the evidence, and the close result, do not scale the workflow yet.
I need to know what actually appears on my machine after each step.
# what changes after the first loop
$ ls -d ~/.motus .motus
~/.motus
.motus
$ motus work status "$LEASE_ID" --json
{
"lease_id": "lease-20260403-360e8b5e",
"lease_status": "active",
"evidence": [
{
"evidence_type": "test_result",
"test_results": {"passed": 1, "failed": 0, "skipped": 0}
}
]
}
See what actually happens from first claim to accepted close.
Use one concrete task: align the onboarding docs for new operators. The work starts with one lease and accumulates evidence. It can hand off without changing scope and closes with a receipt the next actor can trust.
I do not just want the nouns. I want to know what the work looks like while it moves.
# example work item
$ LEASE_ID=$(motus work claim DOCS-ONBOARDING-001 --intent "Clarify first-run path" | awk -F': ' '/^Lease ID:/ {print $2}')
# attach proof while the work happens
$ motus work evidence "$LEASE_ID" test_result --passed 3 --failed 0
# inspect the active packet
$ motus work status "$LEASE_ID" --json
# if another actor needs to continue, handoff says:
# - objective
# - scope
# - required validation
# - expected receipt
# - failure route
# when accepted, the close record becomes the next starting point
$ motus work release "$LEASE_ID" success --json
# what the next actor trusts handoff: objective: clarify first-run path scope: docs + build page only required_validation: smoke + website gates expected receipt: released close with accepted source state evidence_required: smoke transcript + gate report failure_route: stop and open follow-up CR if CLI must change receipt: work_item_id: DOCS-ONBOARDING-001 target_ref: refs/heads/main verified_source_state: refs/heads/main @ <accepted-commit-sha> evidence_run_hash: sha256:<evidence-bundle-hash> verified_by: ci@gate-public-surface verified_at: 2026-04-06T13:46:00Z
See the actual close surface.
Day 1 starts with a small local close response. Governed workflows add richer receipts that bind source state, evidence hashes, and verifier identity. Start with the small loop, then add the heavier receipt when another actor or promotion step needs the result.
I need proof I can point to. For myself, first.
# day-1 JSON surfaces
$ motus work claim ADHOC-DAY1-001 --intent "Day1 smoke" --json
{
"decision": "GRANTED",
"reason_code": "GRANTED_OK",
"lease_id": "lease-20260403-360e8b5e",
"message": "Access granted."
}
$ motus work status "$LEASE_ID" --json
{
"lease_id": "lease-20260403-360e8b5e",
"lease_status": "active",
"outcomes": [],
"evidence": [
{
"evidence_id": "evidence-20260403-61fb7d8e",
"evidence_type": "test_result",
"test_results": {"passed": 1, "failed": 0, "skipped": 0}
}
],
"decisions": []
}
$ motus work release "$LEASE_ID" success --json
{
"decision": "GRANTED",
"reason_code": "RELEASED_OK",
"message": "Lease released successfully.",
"lease_status": "released"
}
# governed receipt shape
{
"version": "0.1.0",
"work_item_id": "CR-MOTUS-ONBOARDING-ALIGN-1",
"to_state": "released",
"target_ref": "refs/heads/main",
"verified_source_state": {
"vcs": "git",
"commit_sha": "<accepted-commit-sha>",
"dirty": false
},
"evidence_run_id": "run-20260406-onboarding-align",
"evidence_run_hash": "sha256:<evidence-bundle-hash>",
"verified_by": "ci@gate-public-surface",
"verified_at": "2026-04-06T13:46:00Z"
}
The example uses placeholders on purpose. A real receipt stores the accepted commit and evidence hash, but the shape matters more than a copied literal.
Define what must be true.
A work contract specifies scope, required checks, required evidence, and ownership before execution begins. The contract locks the decision so execution can move without reopening what was already settled.
I need to define what done looks like before anyone starts.
# example work contract work_id: TASK-042 scope: paths: ["src/auth/**", "tests/auth/**"] checks: - pytest tests/auth - ruff check src/auth evidence: - test_result: passed > 0, failed = 0 - coverage: >= 80% owner: @security-team
Keep the handoff small and explicit.
The handoff is not a second contract. It is the execution envelope for the current actor or attempt. It says what the objective is, what is in scope, and what must pass. It also says what a valid close looks like and what to do if the work blocks.
You do not need this for every solo day-1 run. You add it when another person, CI job, or agent must continue the work without guessing.
A good handoff should let the next actor continue without opening a DM, a ticket thread, or your scratchpad. If they still have to guess, the handoff is too weak.
# starter handoff Objective: - align the onboarding surfaces so a zero-context operator can install Motus, run doctor, claim work, and close it with a receipt In scope: - packages/cli/docs/implementation/README.md - site/build.html Required validation: - clean-home smoke: install -> init -> doctor -> claim -> evidence -> release - python -m pytest packages/cli/tests/test_work_cmd.py - bash scripts/run_gates.sh Expected receipt: - local day-1 close: JSON release response with decision=GRANTED and lease_status=released - governed close: receipt with accepted source state, evidence bundle, verifier, and verification time Evidence required: - clean-home smoke transcript - passing CLI test output - website gate report Failure route: - if the docs require a CLI or schema change, stop and open a follow-up CR
# decorative handoff (too weak) "Continue the onboarding docs and run the normal checks." # useful handoff "Align the onboarding docs and build page so a zero-context operator can run install -> init -> doctor -> claim -> evidence -> release. Only docs and website copy are in scope. Run the clean-home smoke, pytest packages/cli/tests/test_work_cmd.py, and bash scripts/run_gates.sh. Successful close must include a released lease response, smoke transcript, and website gate report. If the docs require a CLI or schema change, stop and open a follow-up CR."
Two options to start.
Gates are userland policy. You have two practical paths: use the built-in policy runner or create a custom script.
I need checks that cannot be bypassed.
# Option A: Motus policy gate $ motus policy plan --repo . --files README.md --json $ motus policy run --repo . --files README.md --json # deterministic evidence bundle output
# Option B: Custom gate script # scripts/gates/gate-001-no-todo.sh #!/usr/bin/env bash set -euo pipefail if grep -RInE 'TODO|FIXME' . --exclude-dir=.git --exclude-dir=.motus --exclude='*.md' >/dev/null; then echo "FAIL: TODO/FIXME markers found in code." exit 1 fi echo "PASS: no TODO/FIXME markers in code."
Wire gates into your pipeline.
Gates run in CI like any other check. The verifier runs from a pinned reference so execution cannot modify the rules it is judged by.
I need this wired into my existing pipeline, not a new system.
# .github/workflows/gate-001.yml
name: gate-001
on:
pull_request:
branches: [main]
jobs:
gate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run gate-001
run: ./scripts/gates/gate-001-no-todo.sh
# commit your gate + workflow $ git add scripts/gates/gate-001-no-todo.sh .github/workflows/gate-001.yml $ git commit -m "gate: add no-todo gate and CI workflow"
Leverage GitHub correctly.
Motus complements GitHub governance. It does not replace it. Configure these controls in your repo settings.
I need Motus to work with what I already have, not replace it.
What Motus secures. What you secure.
Motus is open source and local-first. Local acceptance is authoritative. You own security and controls. Motus gives workflow discipline and evidence structure. It is not a security appliance.
I need to know what is my job and what is Motus's job.
Open the implementation guide and run the loop.
The implementation guide takes the same path shown here and expands it into the exact command flow, examples, and next-step logic.