Skip to content

Features

Every capability of the product as one object of the layer: what it is made of, the interfaces it is exposed through, the rules that hold it and the guarantees behind it. Each card is a file; every mark beside it is derived.

One registry, every interface

A feature is on an interface because a capability module, a shell command or an object kind it names is projected there. The number under each is counted from that, at build time.

What the product is

One card per feature file under the layer. The words are editorial; every mark, count and link beside them is derived from what that file names.

  1. Declare once, derive every interface

    One typed declaration per capability, one file per object of the layer; every interface, generated document and page is derived from the registry those declarations build, and a stale projection fails the build.

    capabilities
    9
    objects
    197
    rules
    5
    moments
    15
    What it is, and what it does not do →

  2. One registry over the command line, HTTP, OpenAPI, Swagger UI and MCP

    The Rust executable serves the layer read-only over stdio MCP, MCP over HTTP, routes under /api/v1/, an OpenAPI document with a Swagger UI, and a command line, all derived from the capability registry; one shared server per repository, and every attached client is a peer the others can see.

    capabilities
    8
    rules
    4
    moments
    31
    What it is, and what it does not do →

  3. Several agents on one repository, without stepping on each other

    A task claims its scope before the first edit; check and finish refuse a file outside it and report another worktree's overlapping claim; every client of the shared server is a peer that can announce its intent and paths; and each branch has exactly one worktree, derived from git.

    capabilities
    6
    rules
    5
    moments
    14
    What it is, and what it does not do →

  4. One branch, one worktree, at a path derived from git

    The container is the primary checkout's sibling named with -wt, a branch's worktree is the branch name under it with its hierarchy kept, both derived from git identity and registered nowhere; a pre-commit guard refuses a feature branch committed from anywhere else, and migration moves a misplaced worktree with its uncommitted work, fingerprinted before and after.

    capabilities
    4
    rules
    2
    moments
    3
    What it is, and what it does not do →

  5. Sessions, prompts and handovers that outlive the conversation

    Task state, checkpoints, handovers, decisions and open questions live in files outside every conversation; a session opens and closes into an immutable record; the person's prompts are captured by the provider's own hooks; and the next episode is briefed from those records, labelled by how far git has moved since.

    capabilities
    1
    objects
    15
    rules
    8
    moments
    20
    What it is, and what it does not do →

  6. Decisions and knowledge that compound instead of evaporating

    Decisions are recorded with their reason and their task, open questions block acceptance until resolved, architecture decision records carry typed references to the rules, claims, files and tests they put in force, and the graph of all of it is derived from those references rather than drawn.

    capabilities
    2
    objects
    244
    rules
    4
    moments
    17
    What it is, and what it does not do →

  7. Rules a machine decides, wired, tested and CI-blocking

    Every rule is a portable Markdown object with front matter; a rule the tool enforces names its validator, the commands that dispatch it and the tests that prove it, and doctor walks that chain from the source, refusing a validator nobody declares and a declaration nothing runs; a blocking violation stops the command and an advisory one is reported.

    capabilities
    3
    objects
    109
    rules
    5
    moments
    31
    What it is, and what it does not do →

  8. Done is a contract, evaluated line by line and refused when unmet

    A task starts with a declared scope and a profile; check reports whether the task is consistent with policy, scope and state; finish evaluates the policy's contract — scope respected, verification ran, state updated, no open blockers, a note present — and refuses with the reproducing command when any line fails.

    rules
    7
    moments
    20
    What it is, and what it does not do →

  9. One policy, projected into every tool's instruction file

    A provider-neutral policy and four execution profiles are the one source; majordomus update renders each provider bootstrap from its template, stamps it with the policy hash and the hash of its own content, and doctor fails a bootstrap that was hand-edited, that carries a rule corpus of its own, or that exceeds the always-loaded budget.

    objects
    5
    rules
    7
    moments
    20
    What it is, and what it does not do →

  10. The Cockpit: the registry rendered for a person

    At /cockpit the shared server lays out what a capability answered — the registry explorer, every object of the layer, the derived graphs, the directory contracts, the continuity of this checkout, the worktree topology, one health report naming the engine behind every check — and every page is complete HTML before any script runs.

    capabilities
    3
    rules
    1
    moments
    11
    What it is, and what it does not do →

  11. Every record names the commit, the branch and the episode that made it

    The ledger records every durable event with its task and its head; identity fields on any record are computed from git and refused when authored; a closed session is an immutable record of what one episode produced; the person's prompts are captured by the provider's hooks; and retention is capped by policy rather than by forgetting.

    objects
    11
    rules
    4
    moments
    15
    What it is, and what it does not do →

  12. One command to install, one to initialise, nothing else to trust

    One distribution model owns every platform, artifact name and URL; the installer, the release build matrix, the installation guide, the website's install block and the public release metadata are generated from it, and a release publishes an artifact for every supported target or it is not published.

    capabilities
    5
    objects
    1
    rules
    3
    moments
    2
    What it is, and what it does not do →

  13. Milestones and issues as data; status derived, never stored

    Milestones are outcome specifications and issues are execution contracts, one YAML file each; the dependency graph decides execution waves and the next ready issue; a milestone whose dependencies are not accepted is blocked whatever its own issues say; and the GitHub projection is rendered offline from the same model.

    capabilities
    3
    objects
    219
    rules
    3
    moments
    6
    What it is, and what it does not do →

  14. Every directory of the layer carries its contract, and a worker reads what applies

    Every README under .ai/ is a context document with an identity, a scope, the providers and audience it addresses and how it composes with its ancestors; the repository scope declares what a worker reads and what it never reads; and the briefing a worker gets is assembled from durable state within a line budget with every exclusion named.

    capabilities
    4
    objects
    28
    rules
    6
    moments
    20
    What it is, and what it does not do →

  15. Every use case is executed against the tool, not described

    A use case names the commands, rules, claims and applications it relies on and carries a scenario as data; usecase run executes it in a disposable repository and records normalised evidence; maturity is observed from the evidence; coverage of commands, guaranteed claims and MCP tools is tallied and the policy says which gaps fail.

    objects
    57
    rules
    3
    moments
    3
    What it is, and what it does not do →

  16. Skills are procedures as data, discovered and checked, never registered

    A skill is a provider-neutral procedure for one bounded kind of work, front matter under a schema over a body with a purpose, a procedure and an output contract; the source class discovers it, skills check holds every one to its contract, and nothing loads a skill unless the task is about it.

    objects
    3
    rules
    1
    What it is, and what it does not do →

  17. The failure modes it answers are objects, not marketing pages

    Moments, audiences and areas are kinds of the layer; a moment names the commands, capabilities, claims, rules and use cases that answer it, each reference validated; the catalogue, the questionnaire, the diagnosis and every page and filter are derived from those files.

    capabilities
    6
    objects
    55
    rules
    1
    What it is, and what it does not do →

  18. Every claim about speed is a recorded measurement

    The benchmark targets are derived from the registry, so a capability nothing times cannot be merged; runs are compared with a tracked baseline per platform under a regression policy; the shell tool reports where every command's time went; and derived state is computed once per state version rather than per call.

    capabilities
    1
    rules
    6
    moments
    6
    What it is, and what it does not do →

  19. CI planned from one model, the site deployed from its verified run

    The gate model names every validation gate and which classes of paths select it; the workflow is a thin adapter over that plan; the publication path proves the committed derived data current by its input hash and renders it; and the tool supervises its own repository with its own hooks.

    rules
    4
    moments
    18
    What it is, and what it does not do →

The product, composed

the features of the layer, the capability registry and the command registry

Select a node to see what it is and what it touches.

Every stable feature of the product, the capability modules, shell commands and object kinds it is made of, and the interfaces those project onto: the command line, the HTTP API, MCP, the Cockpit and the documentation. Every edge is derived from a feature's typed references and the registry's exposures; a feature that named something the repository does not have would fail validation rather than draw an edge to nothing.
The same graph as text — 90 nodes, 270 edges

  • majordomus adr command · conclude

    The repository's architecture decisions as objects: list, show, propose one with provenance, and validate the whole set.

    • exposed_through surface:cli

  • majordomus bench command · inspect

    Time every public command of the registry, cold and warm, and compare with the baseline.

    • exposed_through surface:cli

  • majordomus capture command · work

    Record the person's raw prompts from a provider hook as a record with its renderings, draw the episode boundary from the provider's own lifecycle hooks, install those hooks, and report what each provider actually does here.

    • exposed_through surface:cli

  • majordomus check command · verify

    Is the current task still consistent with its policy, its scope and this checkout?

    • exposed_through surface:cli

  • majordomus checkpoint command · work

    Record compact progress inside the active task, so the next worker does not start over.

    • exposed_through surface:cli

  • majordomus context command · work

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

    • exposed_through surface:cli

  • majordomus decision command · work

    Record a decision that was made between real alternatives, with its reason, and read them back.

    • exposed_through surface:cli

  • majordomus doctor command · inspect

    Is Majordomus itself healthy, and is every enforcement it declares actually wired here?

    • exposed_through surface:cli

  • majordomus doctrine command · inspect

    What rules are enforced, by what, and whether each one is actually wired.

    • exposed_through surface:cli

  • majordomus finish command · conclude

    Evaluate the finish contract and refuse the outcome if any line of it is unmet.

    • exposed_through surface:cli

  • majordomus handover command · conclude

    Write an append-only continuation record, and resolve the most relevant prior one.

    • exposed_through surface:cli

  • majordomus history command · inspect

    Read the append-only ledger back, filtered by task, event or time.

    • exposed_through surface:cli

  • majordomus init command · setup

    Create the .ai/ layer in this repository, and refuse to overwrite an existing one.

    • exposed_through surface:cli

  • majordomus knowledge command · inspect

    The compiled index over what this repository states.

    • exposed_through surface:cli

  • majordomus migrate command · setup

    Move pre-.ai project data from .majordomus/ into .ai/, explicitly and backed up.

    • exposed_through surface:cli

  • majordomus plan command · begin

    The milestone and issue model — validate it, read it, and move one issue through it.

    • exposed_through surface:cli

  • majordomus prompt command · work

    List, show and render the repository's own prompt assets, substituting known tokens only.

    • exposed_through surface:cli

  • majordomus question command · work

    Open a question that blocks acceptance, resolve it, and list what is still open.

    • exposed_through surface:cli

  • majordomus rules command · inspect

    The effective rule set, vendored baseline plus project rules.

    • exposed_through surface:cli

  • majordomus search command · inspect

    Find a durable record without reading all of them, in authority order.

    • exposed_through surface:cli

  • majordomus session command · begin

    Open, inspect and close one execution episode.

    • exposed_through surface:cli

  • majordomus skills command · work

    The repository's skills — provider-neutral procedures under the skills section — listed, shown and checked from the one catalogue every surface reads.

    • exposed_through surface:cli

  • majordomus start command · begin

    Begin one scoped task under a profile, and refuse while another is active.

    • exposed_through surface:cli

  • majordomus update command · setup

    Regenerate every provider instruction file from the one policy, deterministically.

    • exposed_through surface:cli

  • majordomus usecase command · verify

    The executable use cases: list, show, validate, run against the real tool, coverage, impact, scaffold.

    • exposed_through surface:cli

  • majordomus version command · inspect

    Print the version, without needing a repository or an installation.

    • exposed_through surface:cli

  • majordomus watch command · inspect

    What has drifted since the last update — policy, projections, state, retention.

    • exposed_through surface:cli

  • Benchmarks feature · stable

    The benchmark targets are derived from the registry, so a capability nothing times cannot be merged; runs are compared with a tracked baseline per platform under a regression policy; the shell tool reports where every command's time went; and derived state is computed once per state version rather than per call.

    • made_of command:bench
    • related_to feature:ci
    • related_to feature:declare-once
    • made_of module:perf
    • exposed_through surface:docs

  • CI feature · stable

    The gate model names every validation gate and which classes of paths select it; the workflow is a thin adapter over that plan; the publication path proves the committed derived data current by its input hash and renders it; and the tool supervises its own repository with its own hooks.

    • made_of command:doctor
    • made_of command:watch
    • related_to feature:benchmarks
    • related_to feature:doctrine
    • exposed_through surface:docs

  • Cockpit feature · featured

    At /cockpit the shared server lays out what a capability answered — the registry explorer, every object of the layer, the derived graphs, the directory contracts, the continuity of this checkout, the worktree topology, one health report naming the engine behind every check — and every page is complete HTML before any script runs.

    • related_to feature:declare-once
    • related_to feature:interfaces
    • made_of module:health
    • exposed_through surface:docs

  • Context feature · stable

    Every README under .ai/ is a context document with an identity, a scope, the providers and audience it addresses and how it composes with its ancestors; the repository scope declares what a worker reads and what it never reads; and the briefing a worker gets is assembled from durable state within a line budget with every exclusion named.

    • made_of command:context
    • related_to feature:continuity
    • related_to feature:policy
    • made_of kind:context
    • made_of kind:scope
    • made_of module:directories
    • made_of module:repository
    • exposed_through surface:docs

  • Continuity feature · featured

    Task state, checkpoints, handovers, decisions and open questions live in files outside every conversation; a session opens and closes into an immutable record; the person's prompts are captured by the provider's own hooks; and the next episode is briefed from those records, labelled by how far git has moved since.

    • made_of command:capture
    • made_of command:checkpoint
    • made_of command:context
    • made_of command:handover
    • made_of command:prompt
    • made_of command:session
    • related_to feature:coordination
    • related_to feature:knowledge
    • related_to feature:provenance
    • made_of kind:prompt
    • made_of kind:session
    • made_of module:continuity
    • exposed_through surface:docs

  • Coordination feature · featured

    A task claims its scope before the first edit; check and finish refuse a file outside it and report another worktree's overlapping claim; every client of the shared server is a peer that can announce its intent and paths; and each branch has exactly one worktree, derived from git.

    • made_of command:check
    • made_of command:finish
    • made_of command:start
    • related_to feature:continuity
    • related_to feature:worktrees
    • made_of module:peers
    • made_of module:worktree
    • exposed_through surface:docs

  • Declare once feature · featured

    One typed declaration per capability, one file per object of the layer; every interface, generated document and page is derived from the registry those declarations build, and a stale projection fails the build.

    • made_of command:doctor
    • made_of command:update
    • related_to feature:cockpit
    • related_to feature:interfaces
    • made_of kind:claim
    • made_of kind:command
    • made_of kind:feature
    • made_of module:artifacts
    • made_of module:capabilities
    • made_of module:product
    • exposed_through surface:docs

  • Doctrine feature · featured

    Every rule is a portable Markdown object with front matter; a rule the tool enforces names its validator, the commands that dispatch it and the tests that prove it, and doctor walks that chain from the source, refusing a validator nobody declares and a declaration nothing runs; a blocking violation stops the command and an advisory one is reported.

    • made_of command:check
    • made_of command:doctor
    • made_of command:doctrine
    • made_of command:rules
    • made_of command:watch
    • related_to feature:finish-contract
    • related_to feature:policy
    • made_of kind:rule
    • made_of module:health
    • exposed_through surface:docs

  • Finish contract feature · featured

    A task starts with a declared scope and a profile; check reports whether the task is consistent with policy, scope and state; finish evaluates the policy's contract — scope respected, verification ran, state updated, no open blockers, a note present — and refuses with the reproducing command when any line fails.

    • made_of command:check
    • made_of command:finish
    • made_of command:question
    • made_of command:start
    • related_to feature:coordination
    • related_to feature:doctrine
    • exposed_through surface:docs

  • Install feature · stable

    One distribution model owns every platform, artifact name and URL; the installer, the release build matrix, the installation guide, the website's install block and the public release metadata are generated from it, and a release publishes an artifact for every supported target or it is not published.

    • made_of command:init
    • made_of command:migrate
    • made_of command:version
    • related_to feature:policy
    • made_of kind:distribution-model
    • made_of module:distribution
    • exposed_through surface:docs

  • Interfaces feature · stable

    The Rust executable serves the layer read-only over stdio MCP, MCP over HTTP, routes under /api/v1/, an OpenAPI document with a Swagger UI, and a command line, all derived from the capability registry; one shared server per repository, and every attached client is a peer the others can see.

    • related_to feature:coordination
    • related_to feature:declare-once
    • made_of module:objects
    • made_of module:repository
    • made_of module:web
    • exposed_through surface:docs

  • Knowledge feature · featured

    Decisions are recorded with their reason and their task, open questions block acceptance until resolved, architecture decision records carry typed references to the rules, claims, files and tests they put in force, and the graph of all of it is derived from those references rather than drawn.

    • made_of command:adr
    • made_of command:decision
    • made_of command:history
    • made_of command:knowledge
    • made_of command:question
    • made_of command:search
    • related_to feature:continuity
    • related_to feature:doctrine
    • made_of kind:adr
    • made_of kind:document
    • made_of kind:knowledge
    • made_of module:graph
    • exposed_through surface:docs

  • Planning feature · stable

    Milestones are outcome specifications and issues are execution contracts, one YAML file each; the dependency graph decides execution waves and the next ready issue; a milestone whose dependencies are not accepted is blocked whatever its own issues say; and the GitHub projection is rendered offline from the same model.

    • made_of command:plan
    • related_to feature:finish-contract
    • related_to feature:worktrees
    • made_of kind:issue
    • made_of kind:milestone
    • made_of module:trace
    • exposed_through surface:docs

  • Policy feature · stable

    A provider-neutral policy and four execution profiles are the one source; majordomus update renders each provider bootstrap from its template, stamps it with the policy hash and the hash of its own content, and doctor fails a bootstrap that was hand-edited, that carries a rule corpus of its own, or that exceeds the always-loaded budget.

    • made_of command:doctor
    • made_of command:init
    • made_of command:update
    • related_to feature:declare-once
    • related_to feature:doctrine
    • made_of kind:policy
    • made_of kind:profile
    • exposed_through surface:docs

  • Provenance feature · featured

    The ledger records every durable event with its task and its head; identity fields on any record are computed from git and refused when authored; a closed session is an immutable record of what one episode produced; the person's prompts are captured by the provider's hooks; and retention is capped by policy rather than by forgetting.

    • made_of command:capture
    • made_of command:history
    • made_of command:session
    • made_of command:watch
    • related_to feature:continuity
    • related_to feature:knowledge
    • made_of kind:session
    • exposed_through surface:docs

  • Skills feature · stable

    A skill is a provider-neutral procedure for one bounded kind of work, front matter under a schema over a body with a purpose, a procedure and an output contract; the source class discovers it, skills check holds every one to its contract, and nothing loads a skill unless the task is about it.

    • made_of command:skills
    • related_to feature:context
    • related_to feature:declare-once
    • made_of kind:skill
    • exposed_through surface:docs

  • Use cases feature · stable

    A use case names the commands, rules, claims and applications it relies on and carries a scenario as data; usecase run executes it in a disposable repository and records normalised evidence; maturity is observed from the evidence; coverage of commands, guaranteed claims and MCP tools is tallied and the policy says which gaps fail.

    • made_of command:usecase
    • related_to feature:doctrine
    • related_to feature:why
    • made_of kind:application
    • made_of kind:taxonomy
    • made_of kind:use-case
    • exposed_through surface:docs

  • Why feature · stable

    Moments, audiences and areas are kinds of the layer; a moment names the commands, capabilities, claims, rules and use cases that answer it, each reference validated; the catalogue, the questionnaire, the diagnosis and every page and filter are derived from those files.

    • related_to feature:declare-once
    • related_to feature:use-cases
    • made_of kind:area
    • made_of kind:audience
    • made_of kind:moment
    • made_of module:why
    • exposed_through surface:docs

  • Worktrees feature · featured

    The container is the primary checkout's sibling named with -wt, a branch's worktree is the branch name under it with its hierarchy kept, both derived from git identity and registered nowhere; a pre-commit guard refuses a feature branch committed from anywhere else, and migration moves a misplaced worktree with its uncommitted work, fingerprinted before and after.

    • related_to feature:continuity
    • related_to feature:coordination
    • made_of module:worktree
    • exposed_through surface:docs

  • adr kind

    33 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • application kind

    5 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • area kind

    9 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • audience kind

    8 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • claim kind

    148 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • command kind

    29 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • context kind

    27 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • distribution-model kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • document kind

    210 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • feature kind

    20 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • issue kind

    202 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • knowledge kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • milestone kind

    17 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • moment kind

    38 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • policy kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • profile kind

    4 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • prompt kind

    4 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • rule kind

    109 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • scope kind

    1 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • session kind

    11 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • skill kind

    3 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • taxonomy kind

    10 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • use-case kind

    42 object(s) of the layer

    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • artifacts module · behaviorally_verified

    Generated artifacts

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • capabilities module · behaviorally_verified

    Capabilities

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • continuity module · behaviorally_verified

    Continuity

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • directories module · behaviorally_verified

    Directory contracts

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • distribution module · behaviorally_verified

    Distribution

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • graph module · behaviorally_verified

    Graphs

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • health module · behaviorally_verified

    Health

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • objects module · behaviorally_verified

    Objects

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • peers module · behaviorally_verified

    Peers

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • perf module · behaviorally_verified

    Performance

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • product module · behaviorally_verified

    Product

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • repository module · behaviorally_verified

    Repository

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • trace module · behaviorally_verified

    Traceability

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • web module · behaviorally_verified

    Web surfaces

    • exposed_through surface:api
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • why module · behaviorally_verified

    Why

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • worktree module · behaviorally_verified

    Worktree topology

    • exposed_through surface:api
    • exposed_through surface:cli
    • exposed_through surface:cockpit
    • exposed_through surface:mcp

  • HTTP API surface

  • Command line surface

  • Cockpit surface

  • Documentation surface

  • MCP surface

The tools this answers

The set is the adapters the distribution ships, agents and orchestrators alike. What this repository does with each — the instruction files its policy renders, the client configuration at its root — is read from the policy and the tree, never listed here; what the tool declares about each — its name, the configuration it reads, the scratch roots it creates checkouts under — is read from one declaration beside the templates.

  • Any tool that reads AGENTS.md agents
    • AGENTS.md · always loaded
  • bb bb
    • .bb/AGENTS.md

    scratch: ${BB_DATA_DIR:-~/.bb}/plugins/environment-git-worktree/host-data/worktrees

  • Claude Code claude-code
    • CLAUDE.md

    .mcp.json

    2 hook(s) wired

    scratch: <primary>/.claude/worktrees

  • Codex codex

    .codex/config.toml

  • Gemini CLI gemini

    .gemini/settings.json

  • A worker with no convention of its own generic

Every fact on this page came from majordomus product list, majordomus product matrix and majordomus product providers — the same answers this repository serves over HTTP and over MCP. How that derivation works →