Skip to content

majordomus context

What the next worker needs to know now, in authority order and within a budget.

What the next worker needs to know now, in authority order and within a budget.

  • read-only
  • continuity
  • active task optional
  • --json

Names everything it excluded and why. Exits 10 only when the sections that cannot be dropped already exceed the budget.

Syntax

majordomus context [--for <provider>] [--prompt <name>] [--budget-lines <n>] [--json]

Lifecycle

  1. Set up
  2. Begin
  3. Work
  4. Verify
  5. Conclude
  6. Inspect

Other commands at this stage:checkpoint, decision, question, prompt, evidence, skills, capture.

Reads

  • git identity
  • .ai/local/state/current.yaml
  • .ai/repo/profiles/
  • .ai/local/state/open-questions.md
  • .ai/local/state/decisions.md
  • .ai/local/state/checkpoints/
  • .ai/local/state/handovers/
  • .ai/local/state/ledger.jsonl
  • .ai/repo/prompts/

Writes

Nothing. This command is read-only.

Exit codes

Only the codes this command can produce. The full contract is on the commands index.

  • 0 ok
  • 2 usage
  • 10 contract unmet
  • 11 drift found
  • 12 missing artifact

What the next worker needs to know now

context assembles durable state in authority order and within a line budget, and names everything it excluded. It writes nothing, records nothing, and calls no model.

With an active task and records behind it

active task
yes

Given this repository

# An active task that has already produced a checkpoint, a decision and an open question.
. "$FIXTURE_SETUP/active-task.sh"
printf 'the parser now refuses tabs\n' | "$MJ" checkpoint >/dev/null
"$MJ" decision add "refuse tabs in the parser" --why "two encodings for one token" >/dev/null
"$MJ" question add "should tabs be an error or a warning?" >/dev/null

Run

$ majordomus context

Output contains

  • ## GIT
  • ## TASK
  • narrow the parser

exit 0

Git identity comes first because it is the only section that is not a projection. Everything below it is evidence, and the header says so in as many words.

With no active task

active task
no

Given this repository

# A repository with Majordomus installed and projections generated, and one commit of work.
"$MJ" init >/dev/null
"$MJ" update >/dev/null
mkdir -p lib docs
echo a > lib/a
echo d > docs/d
git add . && git commit -qm base

Run

$ majordomus context

Output contains

  • ## GIT

exit 0

Absence is reported rather than guessed at. A worker who is told there is no active task knows to start one; a worker handed a stale record does not.

Reference

What does whoever works next need to know? Read-only. Assembles durable state into one briefing and prints it. Nothing is persisted, no model is called, and the output is a projection: every line is recomputed from the records and git each time it runs.

Section order is authority order. Git first, because it is the only thing that cannot be stale; then the task and the profile that constrains it; then blockers, which change what may be accepted; then authored records; then event history last, because it is the weakest evidence about the present.

SectionSourceIncluded when
GITgitalways
TASKstate/current.yamla task is active and the profile's context.task is not false
PROFILEprofiles/<name>.yamlthe task names a profile that exists
CONTEXT DOCUMENTS.ai/**/README.md (the context contract)a task is active; the effective chain is listed for each of its scope paths
OPEN QUESTIONSstate/open-questions.mdany unresolved entry names this task
DECISIONSstate/decisions.mdcontext.decisions: true (this task) or context.architecture_notes: true (the repository)
LATEST CHECKPOINTstate/checkpoints/a checkpoint resolves for this task
LATEST COMPATIBLE HANDOVERstate/handovers/a handover resolves for this worktree and branch
FILES TOUCHED IN SCOPEgitcontext.relevant_files: true
RECENT HISTORYstate/ledger.jsonlcontext.recent_history_depth is above zero
PROMPTprompts/<name>.md--prompt <name> was given

This is the only code that reads a profile's context block, which is what makes those fields state rather than documentation.

Budget. context.builder_budget_lines in the policy, or --budget-lines. When the assembled text exceeds it, sections are dropped in a fixed order — history, files, decisions, then the bodies of the checkpoint and the handover, which degrade to a pointer rather than disappearing. Git, task, profile and blockers are never dropped. Every drop is named under EXCLUDED with its reason, so an under-filled context is debugged from the exclusion list instead of guessed at. Exit 10 if what cannot be dropped is already over budget.

--for <provider> wraps the same body with a header naming the provider and its always-loaded file. The body does not change: the canonical context is provider-neutral, and a provider that needed different facts would be a different policy, not a different rendering.

--json emits one object: git, task, sections[] (each with id, lines and text), excluded[] (each with item and reason), and budget. The same selection as the text form, because both are assembled once and rendered twice.

$ majordomus context
# Majordomus context — 2026-09-03T19:41:02Z
# a projection of durable state, not a source of truth: validate every line against git

Evidence

Every case below runs in CI on Linux and macOS. The site refuses to build if a public command has no behavioural case, no negative case, or no demonstration.

Guarantees this command carries