Skip to content

Repository files navigation

my

my is a small, dependency-free CLI that bootstraps an AI agent's working environment from a single organization manifest. One command turns a fresh machine into one where installed AI harnesses — Claude Code, Codex, OpenCode, Antigravity, Grok, and Cursor — share the same company context, manifest-defined launch profiles, and local tooling.

It is built for a world where agents are the primary operators. Humans own intent — goals, products, decisions — and express it as content in a Git repo. my is the deterministic, machine-friendly bridge that gets that content and those capabilities onto every agent surface, the same way, every time.

Documentation: https://my-cli.com/

Prerequisites: Git, curl, tar, and either sha256sum or shasum, plus one installed and authenticated agent harness. Install the agent first so it can guide the rest of first-machine setup. The GitHub CLI (gh, logged in) is required for any manifest or mount hosted on github.com and when my publish creates repositories; the installer and my doctor report it, and the guide checks it before attempting private Git operations. Windows users should run the Linux CLI and Git together inside WSL, with the umbrella under the WSL home directory.

curl -fsSL https://my-cli.com/install.sh | sh

On a fresh interactive install, that command installs the release binary, persists ~/.local/bin in the shell profile, installs the bundled agent skill, and starts guided onboarding. It does not require Go or Node. For CI or an automation-only install, add --no-onboarding after sh -s --.

An organization can give a new teammate one complete bootstrap command:

curl -fsSL https://my-cli.com/install.sh | sh -s -- --manifest acme <manifest-git-url>

The agent resumes from whatever is missing: GitHub CLI installation/login, manifest sync, setup, role selection, required organization tools, verification, and first launch. An authenticated gh session is supplied to HTTPS Git only for the current invocation; My AI does not rewrite global Git configuration. Creating a new organization remains a guided my init path. my onboarding can be rerun at any point and starts a split-pane walkthrough where the operator runs small sets of validated my commands while the model explains and pauses. Use my onboarding --no-agent for the deterministic walkthrough that explains the model and points at my setup --interactive. my setup remains the scriptable machine configurator. my ai codex resolves the umbrella, verifies the generated guidance, and starts Codex in the base umbrella. Agents that need isolated content work opt in with my ai --new-session codex or resume a known session with my ai -r <id> codex.

my init creates two local repos — a private manifest repo (the control plane: manifest, product/repo catalog, skills) and a content repo at ~/acme/workspace (the actual workspace, including customer records) — registers them, and works offline. When ready to share, my publish creates the private remotes, points the manifest at the published content repo, and pushes both; teammates join with a single my manifests add acme <manifest-url>. Run my update to update an install from the latest GitHub release; re-running install.sh still works as a fallback. Developers can still install from source with go install github.com/fluxinc/my-cli/cmd/my@latest, but Go is not a user installation prerequisite. The installer also installs My AI's bundled my-cli skill into existing harnesses so agents know how to use the CLI itself.

The Model

my has eight concepts. Everything in the CLI is one of these:

Concept What it is
Manifest An organization's configuration, stored in its own private Git repo — the control plane. Declares skills, mounts, data bindings, catalog, services, roles, and tool hints. The single source of truth; it is not the workspace, and day-to-day work never touches it.
Skill A capability exposed to harnesses. Organization skills are static (a directory in the manifest repo) or tool-provided (materialized by an external tool's own installer); my ai composes them into the launch root for harnesses with a project-local skill seam. The CLI also ships one public, organization-neutral self-skill named my-cli, embedded in the binary, that teaches harnesses how to use my itself.
Umbrella A per-user operating envelope (e.g. ~/acme): a .my-cli/ identity namespace plus mounts and local scratch as peers. When initialized for sync publishing, this is the Gnit control workspace so multi-repo commits and pushes have one substrate.
Mount A Git-backed content folder cloned into the umbrella (handbook, customers, meeting notes, policy, docs). Can be path-scoped so only the relevant subtree lands.
Session An isolated unit of work under sessions/<id>: a git worktree per content mount on a fresh my/session/<id> branch, plus session-local scratch and generated guidance with concrete startup context. Create one with my session start or my ai --new-session; add another harness with my session join <id> <harness>; inspect it with my session status or my session list; work leaves only through my session finish --land|--publish|--discard.
Catalog JSON inventories for products (business entities, which may link repos) and repos (the organization's repositories). Users opt specific repos into their umbrella on demand. Customer identities are mounted workspace records, not manifest catalog rows.
Guidance Generated root AGENTS.md instructions for agents, built from a public baseline plus manifest-declared and role-specific fragments. CLAUDE.md points to the same file.
Tool An external executable the org depends on. my reports presence and install hints — it never silently installs tools.

Skills arrive from two places, split by a public/private line. The my-cli self-skill is public and travels inside the CLI binary — it is organization-neutral, carries no company content, and the binary keeps it current on its own. Organization skills are private to a manifest repo you control and appear only once you add and sync that manifest, so they can carry guidance specific to your team. Nothing organization-specific is ever baked into the public CLI.

Commands

Run my --help for the authoritative surface. The essentials:

Onboarding

my onboarding [--harness codex]
                               # model-driven onboarding; auto-detects a harness when unambiguous
my onboarding --no-agent       # deterministic walkthrough; offers interactive setup
my setup [harness...] | --all # create umbrella, write guidance/MCP config, install self-skill, sync mounts
                                    # [--manifest NAME] [--umbrella DIR] [--role ROLE] [--copy] [--link] [--print]
                                    # [--interactive] [--no-refresh] [--no-update-check]

setup is the normal machine path: idempotent, non-interactive, safe to re-run. Use setup --interactive when you want prompts for manifest and role selection. Use my onboarding when you want a harness to run the adaptive AUTHOR/JOIN onboarding flow; my onboard remains a compatibility alias. Publish still requires my publish --print and explicit human approval.

Startup

my root [--repo ID] [--no-refresh] [--no-update-check]
                                             # print the umbrella or repo path
my ai [--new-session|--session ID|--resume [ID]|--no-session] [--repo ID] [--skills all|none|ID,...] [--profile ID] [--setup] [--no-refresh] [--no-update-check] [harness]
                                             # verify guidance, then start a harness
my ai codex --model gpt-5              # pass harness flags after the harness name
my ai --new-session codex
my ai --session 2026-06-11-ab12 codex
my ai -r codex                         # resume the only active session, or pick in a TTY
my ai -r 2026-06-11-ab12 codex
my ai --repo sample-service codex
my ai --print codex                    # print cd <umbrella> && codex
my session leftovers                   # raw worktrees not owned by an active session
my session close-worktree <path> --yes # close a clean leftover; preserve its branch

ai refuses to start against missing or stale generated guidance. Pass --setup to reconcile first, or run my setup directly. By default it launches from the base umbrella, or from the current active session when run inside sessions/<id>. Use --new-session to create a fresh isolated session, --session or -r <id> to launch into a known active session, -r <harness> to resume the single active session or pick one interactively, and --no-session to ignore a current session for base inspection/admin/debug. root, ai, and setup also run a best-effort, TTL-gated refresh of clean manifest/content checkouts so startup sees current context without touching dirty, diverged, repo, or remote-unknown checkouts. Use --no-refresh for one command, MYCLI_NO_AUTO_REFRESH=1 globally, or MYCLI_REFRESH_TTL=30m to tune the default six-hour refresh window.

Startup commands also print stderr notice lines for dirty, ahead, behind, or diverged checkouts, each with the remediation command, keeping stdout clean. They additionally check, at most once per day, whether a newer My AI release exists, using GitHub's public release redirect rather than the rate-limited REST API. Notices are stderr-only so cd "$(my root)" stays path-pure. Use --no-update-check for one command, MYCLI_NO_UPDATE_CHECK=1 globally, or MYCLI_UPDATE_CHECK_TTL=12h to tune the check window.

Updating My AI

my update --check                  # compare this binary with the latest release
my update                          # download, verify, and replace this binary
my update --version 0.5.0          # install a specific release

my update verifies the release tarball against checksums.txt before replacing the binary. It refuses package-managed or non-writable installs and prints the matching follow-up, such as brew upgrade my, go install github.com/fluxinc/my-cli/cmd/my@latest, or re-running install.sh.

Manifests

my init <org-id> [--name NAME] [--path DIR] # create manifest + content repos locally
my publish [--manifest NAME] [--print]      # publish remotes and reviewed manifest control-plane edits
my manifests add <name> <git-url>          # register an org manifest
my manifests sync [name...] | --all        # refresh checkout and derived artifacts
my manifests list                          # list registered manifests
my manifests validate <name|path>          # schema + reference checks

When --manifest is omitted, my uses the manifest recorded by the current umbrella (or --umbrella DIR) first. Outside an umbrella it uses the registry default, which is initialized to the first manifest you add. my manifests list marks that default.

When a non-print manifest sync pulls or clones exactly one manifest, my reconciles derived workspace artifacts for an existing matching umbrella: generated guidance, umbrella MCP config, and launch-scoped skill reconciliation notices. Pass --no-derived for a cache-only refresh or --umbrella DIR when the intended umbrella is not the current one.

Services and roles

my services list [--json]
my services get <id> [--json]
my roles list [--json]
my roles get <id> [--json]
my admin services add|edit|remove ...
my admin roles add|edit|remove ...
my setup --role operator
my compile --role operator [--manifest NAME] [--home DIR]

Manifest data_bindings map stable data nouns (customers, meetings, support, fleet) to an existing mount:<id> or service:<id>. Manifest services describe remote organization surfaces such as HTTP APIs and MCP servers. Manifest roles are local loadouts: they select services and optional role-specific guidance without granting authority or pruning mounts. my setup --role <id> stores the local role selection in .my-cli/state.json, appends that role's guidance fragments to AGENTS.md, and materializes umbrella-root .mcp.json for locally described MCP services visible to the role. my compile --role <id> is the read-only Mode B handoff: it prints a deterministic manifest-to-Clawdapus launch projection as JSON, without launching containers or resolving credentials. A role is required when the manifest declares roles; manifests with no roles compile unscoped. Governed projections include universal plus exact-role policies[] references and fail if an applicable policy mount is outside the selected role.

Contract rules

my contract list [--json]
my admin contract add "RULE TEXT" [--manifest <name>] [--umbrella <root>]
my admin contract remove <index|"RULE TEXT"> [--manifest <name>] [--umbrella <root>]

Manifest contract entries are short, binding organization rules rendered into generated AGENTS.md. Reads stay top-level; edits go through the admin review flow. The registered-manifest form resolves the current umbrella and opens an isolated governed pull request without dirtying the sync-managed manifest cache. --manifest-dir <checkout> remains available for maintainers who intentionally want a local-only edit followed by my publish --manifest.

Skills

my skills self status [--json]            # installed/absent status for the bundled my-cli skill
my skills self install [harness...] | --all
my skills list [--json]                   # manifest/source skills available to install
my skills show <id|slug> [--json]         # one skill's metadata and source path
my skills status [--skill ID_OR_SLUG]     # installed/absent status across harnesses
my skills install [harness...] | --all    # explicit user-global materialization
my skills uninstall <harness...> | --all  # remove materialized skills
my skills sync [harness...] | --all       # install/update and prune stale My AI-managed skills
my skills purge <harness...> | --all      # remove My AI-managed materializations

my skills self ... manages the bundled, public-safe my-cli CLI skill. It is installed by install.sh, refreshed during my setup, ensured for the selected filesystem harness before my ai execs it, and quietly kept current for already-installed file-based harness copies when a newer binary runs.

Use --skill ID_OR_SLUG on manifest skill install, uninstall, sync, purge, or status to target a single declared skill. These commands are explicit manual user-global materialization surfaces; managed launches get organization skills from my ai in the launch root when the harness supports that. OpenCode is currently compatibility-global: present or explicit OpenCode setup/launch keeps org skills in ~/.config/opencode/skills, and my ai opencode --skills/--profile is rejected until OpenCode has a proven project-local seam. Manual manifest skills install as symlinks by default (--copy to vendor a copy). my records provenance and refuses to clobber a directory it did not place. skills sync prunes stale My AI-managed manual manifest skills by default, but does not remove the bundled my-cli self-skill; pass --no-prune to only install/update. Skill commands only refresh harness skill directories; run my setup when manifest guidance or the generated umbrella AGENTS.md should change without a manifest sync.

Organization skill source directories are immutable. Mutable credentials, cookies, caches, and downloads belong under ~/.local/state/my-cli/skills/<manifest>/<install-slug>/. my doctor warns about unexpected files under every declared skill source, and publish/sync holds unadopted skill-source files unless a reviewed source change was staged.

Manifest authoring is explicit admin work:

my admin skills add <skill-dir> --id org:name --manifest-dir <checkout> [--require TYPE:ID]
my admin skills remove <id|slug> --manifest-dir <checkout> [--prune-orphans]
my admin tools add <id> --manifest-dir <checkout> --mode required|optional --purpose "..."
my admin tools edit <id> --manifest-dir <checkout> [--purpose "..."]
my admin tools remove <id> --manifest-dir <checkout>
my admin repos add <id> --manifest-dir <checkout> --git-url <url> [--description "..."] [--default]
my admin services add <id> --manifest-dir <checkout> --kind http|mcp --purpose "..." --auth-ref REF
my admin services edit <id> --manifest-dir <checkout> [--purpose "..."]
my admin services remove <id> --manifest-dir <checkout> [--prune-roles]
my admin roles add <id> --manifest-dir <checkout> --purpose "..."
my admin roles edit <id> --manifest-dir <checkout> [--purpose "..."]
my admin roles remove <id> --manifest-dir <checkout>
my admin contract add "RULE TEXT" [--manifest <name>] [--umbrella <root>]
my admin contract remove <index|"RULE TEXT"> [--manifest <name>] [--umbrella <root>]
my admin policy add <id> --title TEXT --mount ID --path PATH --version VERSION \
  --acceptance required|optional [--summary TEXT] [--topic TEXT] [--role ID]
my admin policy remove <id> [--manifest <name>] [--umbrella <root>]

Admin commands other than registered contract and policy authoring write a maintainer checkout, not the synced cache. Those commands refuse dirty git checkouts unless --force is supplied, never commit or push, and require explicit flags for duplicate-prone or destructive cleanup such as --keep-original, --remove-original, --delete-source, or product related_skills pruning. Removing a skill reports now-orphaned tools and allowed namespaces; --prune-orphans removes those too. Tool removal refuses manifest skills that still reference the tool. After a write they print the relevant git status and git diff follow-up commands.

my admin is the home for shared/workspace configuration. Mutating or configuration commands are reachable there too, with the top-level forms retained as quiet compatibility aliases:

my admin setup ...                 # alias of my setup
my admin manifests add|sync|validate  # alias of my manifests ...
my admin mounts add|remove|sync       # alias of my mounts ...
my admin meetings add                # alias of my meetings add
my admin support add                 # alias of my support add
my admin tools add|edit|remove       # edit manifest tools[]
my admin repos add                   # edit catalog/repos.json
my admin contract add|remove         # edit manifest contract[]

Admin aliases are intentionally limited to those mutating/configuration subcommands. Operational reads (list/show/status/search/get) stay under their top-level commands.

Umbrella mounts

my mounts list                             # manifest content mounts
my mounts add <kind:id|id>                 # opt an optional content mount in
my mounts sync <mount...> | --all          # clone or fast-forward mounts
my mounts remove <mount...> [--force]

Repo clones are managed with my repos add <id> and land under repos/<id> in the umbrella; legacy products/ checkouts migrate automatically at my setup.

Sync

my sync                                   # pull/reconcile only; never publishes local changes
my sync --print                           # plan the pull-only default
my sync --push --print                    # preview explicit publish work
my sync --push                            # publish eligible local changes per policy
my sync --publish auto|never|direct|pr    # governed organizations force PR mode
my sync --scope all|local|content|manifest|repos  # limit to one repo class; repos = catalog repo clones
my sync --no-derived                      # skip derived guidance/MCP/skill reconcile after manifest changes

my sync is the routine reconciliation command. Bare my sync pulls inbound updates and never publishes local changes. Use my sync --push to publish eligible local changes according to the manifest policy, or --publish to choose an explicit mode. My AI classifies changes, handles private/public and content/admin policy, and blocks duplicate checkouts of the same remote until they are collapsed to one canonical checkout. Exact Gnit roster members use coordinated multi-repo Change creation, ordered push, and resume; unrostered checkouts use My AI's guarded built-in publisher. A partial Gnit migration does not change unrelated checkout behavior, and a scoped My AI publish never delegates when Gnit would also publish an unselected member. --backend remains an expert diagnostic escape hatch, not part of the employee workflow. --publish direct can publish existing local commits directly in an ungoverned organization. Governed organizations refuse direct publication and route outbound changes through a dedicated branch and pull request. Before the branch is pushed, the CLI builds the prospective commit with a temporary Git index and runs the same trusted-base governance validator used in CI. After it proves both the remote branch and the pull request author's immutable GitHub id, it attaches the checkout to the dedicated topic branch without changing working-tree bytes and restores the local protected base ref to its proven upstream commit. Ignored and unrelated local files remain in place. Optional auto-merge is requested only when sync.pull_request_auto_merge is true, and GitHub's required checks and reviews still gate the merge. For reviewed manifest control-plane edits under manifest.json, catalog/, skills/, guidance/, and agent-guidance/, prefer my publish --manifest NAME; the equivalent low-level sync form is my sync --publish direct --scope manifest. Default --push remains policy-driven, auto mode is still content-only, and unrelated dirty files stay held. Held-back rows carry reason_code and, when the next step is unambiguous, next_command; text output prints that as next=.... Dirty-behind checkouts point first at the local status command, diverged checkouts point at my doctor, and clean behind checkouts point at my sync. A manifest can set top-level sync.publish_policy to auto, never, or pr as the mode for --push. Governed manifests always select pr for outbound sync and reject an explicit direct override. Set sync.pull_request_auto_merge only when auto-merge after required checks and human approvals is intended. Non-print syncs write .my-cli/last-sync.json so my doctor can show the last sync/publish audit. When sync pulls or publishes a manifest checkout, it reconciles generated guidance, umbrella MCP config, and launch-scoped skill reconciliation notices unless --no-derived is passed.

Governed organizations keep the human interaction inside the ordinary product surface. An employee runs my ai. If a required policy is new or changed, the CLI displays the exact committed document, asks whether it is accepted, records the answer, starts durable publication of the evidence, and then launches the AI. Declining or reaching EOF leaves the policy unaccepted and does not launch. Non-interactive callers fail closed so an agent or harness cannot silently accept for a person.

Generated guidance gives every launched agent a compact, role-scoped ## Organization Policies index: title, id, version, summary, consultation topics, and the exact digest-verifying my policy show <id> action. Policy text is authoritative over summaries and other guidance. Before every real launch, my ai locally verifies every applicable required or optional committed policy blob before writing launch context or executing the harness.

The same launch performs a read-only live GitHub access check when the optional revocation system has not been activated. That check writes no baseline and does not install or enable a monitor. my root and my ai --print never prompt or pollute command output; they put a short policy/access notice on stderr and leave policy review to the next ordinary my ai launch.

Policy setup, inspection, publication recovery, supersession, and GitHub audits remain available as agent/admin automation under my policy, my admin policy, my record, and my governance. They are implementation controls, not an employee onboarding checklist. Acceptance and supersession evidence are append-only and bound to exact committed document bytes and an immutable GitHub user id. Restoring a superseded acceptance requires a new policy version. Acceptance publication deliberately does not refresh the manifest-freshness TTL: its manifest commit is provenance, and every later governed operation must independently pass its own manifest freshness gate. Registered policy authoring proposes an isolated manifest pull request without modifying the sync-managed cache. add fetches the policy mount and hashes the committed upstream blob, never dirty working-tree bytes. The compatibility --manifest-dir path requires an explicit --sha256 because it has no registered mounted-policy context. CI builds my from an explicitly configured 40-character trusted commit and runs my governance check against every commit-parent edge in the complete proposal history and reads its protections only from the trusted manifest base revision. CI enforces universally required policies; role-scoped requirements remain local until the manifest has authoritative identity-to-role mapping. See examples/governance/ for the pinned base-owned workflow, CODEOWNERS pattern, ruleset baseline, and immutable PR-author inputs.

Governed manifests can also opt generic additive records into exact mount paths:

{
  "governance": {
    "record_domains": [
      {
        "id": "decisions",
        "title": "Decisions",
        "mount": "handbook",
        "path": "decisions",
        "retention": "no-delete",
        "admin_override": true,
        "review": "codeowner",
        "publish": "auto-pr"
      }
    ],
    "change_record_rules": [
      {
        "mount": "handbook",
        "paths": ["projects"],
        "record_domain": "decisions"
      }
    ]
  }
}
my record domains
my record add decisions choose-safe-default --source git:OWNER/REPO@SHA
my record list decisions
my record get decisions 2026-07-17-choose-safe-default
my record outbox
my record reconcile
my record flush [--include-manual]
my sync --push --record decisions/2026-07-17-choose-safe-default

add durably creates an intent-to-add Markdown record, then appends a local queue event before trying publication. auto-pr submits through the governed PR path immediately; manual-pr waits for an explicit flush with --include-manual. Offline, access, review-policy, or provider failures append an attempt-failed event and leave the record in place. Reconciliation can rebuild a missing queue item from unpublished Git state after a crash. A verified remote branch and PR move an item to submitted, not merged; the outbox never claims repository acceptance prematurely and never copies record content outside its governed mount. When change_record_rules covers a source path, my sync --record writes a My-Record: <domain>/<id> trailer into the proposed commit. CI uses the authoritative pull-request number and accepts the source change only after the named record is merged and reciprocally cites github-pr:<owner>/<repository>#<number> in sources.

Experimental access-revocation plane

Repository access enforcement and automatic quarantine are endpoint-security mechanisms with a separate activation and release gate from policy acceptance and linked records:

my access check --dry-run
my access activate --yes
my access status
my access monitor install|uninstall|run

Policy or record dogfood never activates this plane. my access activate --yes is an explicit per-machine action that records positive baselines before the monitor can quarantine anything. "Immediate" quarantine means immediately after revocation is detected and positively confirmed; detection itself is not instantaneous and is bounded by the monitor interval, the positive-access TTL, and the configured denial-confirmation count and interval. Ambiguous provider results such as 404, SSO, scope, or network failures block use after the TTL but do not authorize quarantine.

Do not recommend activation for a real umbrella until a separate drill passes against disposable private repositories with a second identity. The drill must prove dirty, untracked, ahead-of-upstream, and active-session recovery; repeated denial handling; lossless quarantine; recovery-capsule restore; and that no path ever falls back to purge or recursive deletion.

Catalog and customer records

my products list [--json]         # the org's product inventory
my customers list [--json]        # mounted customer identity records
my customers list --identity --json  # portable least-privilege ID projection
my customers add  <domain|slug> [--name TEXT] [--domain DOMAIN]
                     [--domain-confirmed] [--alias TEXT] [--partner ID]

Meeting notes

my meetings list   [--since DATE] [--customer ID] [--partner ID] [--product ID] [--json]
my meetings search <text> [--customer ID] [--partner ID] [--product ID] [--json]
my meetings get    <id|path> [--json]
my meetings add    <slug> [--date DATE] [--title TEXT] [--customer ID]
                     [--attendees NAME] [--partner ID] [--source-id ID]

Bare my meetings performs the same safe list action and accepts list filters.

A markdown-first operational record (YAML frontmatter), resolved against the umbrella by default, including the configured umbrella from the registered manifest when the command is run outside the umbrella. Search uses qmd when it is present and falls back to built-in token-AND markdown search.

Support records

my support list   [--since DATE] [--customer ID] [--product ID] [--area TEXT] [--tag TEXT] [--feature-candidate] [--json]
my support search <text> [--customer ID] [--product ID] [--area TEXT] [--tag TEXT] [--feature-candidate] [--json]
my support get    <id|path> [--json]
my support add    <slug> [--date DATE] [--title TEXT] [--customer ID]
                    [--product ID] [--area TEXT] [--tag TEXT]
                    [--status open|workaround|resolved] [--feature-candidate]
                    [--print] [--json]

Bare my support performs the same safe list action and accepts list filters.

An anonymized problem-solving record under support/. Use optional canonical customer IDs in frontmatter when recurrence evidence matters, and keep the body free of identifying details. Search uses qmd when present and falls back to built-in token-AND markdown search.

Fleet registry

my fleet list   [--status TEXT] [--customer ID] [--partner ID] [--identifier ID]
                  [--branch NAME] [--where KEY=VALUE] [--json]
my fleet search <text> [same filters] [--json]
my fleet get    <id|identifier|path> [--json]
my fleet add    <id> [--customer ID] [--partner ID] [--status TEXT]
                  [--device TEXT] [--serial TEXT] [--identifier ID]
                  [--config-repo NAME] [--config-branch NAME]
                  [--deployed-site TEXT] [--ship-to TEXT] [--contact TEXT]
                  [--install-date DATE] [--print] [--json]
my fleet set    <id|identifier> KEY=VALUE... [--json]

A registry record per deployed instance under fleet/<id>.md, keyed by a stable id (hostname or node name) and updated in place. get resolves any entry in the record's identifiers list — a sales order, functional location, or serial — and lists support records sharing an identifier. set updates scalar frontmatter fields while preserving everything else, and suggests an my sync --push --message command so workflow transitions stay readable in git history. The status vocabulary is organization-defined.

Diagnostics

my tools list                             # declared tools across selected manifests
my tools info <name>                      # install hints for a declared tool
my doctor [--no-fetch] [--fix]            # git freshness, sessions, services, derived drift, last sync, manifests, tools

Data-returning commands expose --json where shown. Structured errors use a machine-readable {error, message, remediation} with a concrete next command, so an agent that hits a wall can recover without a human. my doctor fetches refs before reporting behind/ahead counts by default; use --no-fetch for an offline view labeled as of the last fetch. It also reports service materialization health, active work sessions, missing session worktrees, unregistered leftover worktrees, and archived session counts. --fix only fast-forwards clean stale manifest/content checkouts and reconciles derived guidance, MCP config, and skills; dirty, diverged, repo, remote-unknown checkouts, and session work are reported rather than touched. It never removes, prunes, merges, or force-cleans worktrees. Use my session leftovers for exact path-bound remediation. Sync also prints a non-blocking informational row when a content-mount leftover has commits absent from its base checkout; it never turns that row into a pull or publish hold.

Supported Harnesses

Harness Install path
Claude Code ~/.claude/skills/<skill>
Codex ~/.codex/skills/<skill>
OpenCode ~/.config/opencode/skills/<skill>
Antigravity ~/.agents/skills/<skill>
Grok ~/.grok/skills/<skill>
Cursor ~/.cursor/skills/<skill>

Managed org-skill launches use the project-local seam where available: Claude Code receives a launch-root .claude/skills mirror, Grok receives a launch-root .grok/skills mirror, Codex and Antigravity read launch-root .agents/skills, Cursor also reads launch-root .agents/skills, and OpenCode stays on its global path as a compatibility exception.

Missing harnesses are skipped silently — my configures what is present and never fails because a harness is absent.

The Toolchain Around my

my is the organization layer of a broader agentic toolchain. Each piece is its own project with one job, and they compose without depending on each other's internals:

  • my (this repo) — org tooling, primarily for agents: the manifest defines the organization; umbrellas and workspaces materialize it so humans and AI operators work from the same context with the same commands.
  • gnit — git-native multi-repo workspaces. The umbrella's publish substrate for mounts: cross-repo changes, ordered push, reproducible pins.
  • clawdapus — materialization: governed agent containers ("claws") compiled from declarative pod files. The compile target for turning manifest roles into contained fleet agents, with the my CLI inside as a governed work surface.
  • cllama (part of clawdapus) — containment: the governance proxy that holds real provider credentials and mediates every model and tool call. Agents get scoped bearer tokens, never keys.
  • Policy and audit sit behind that proxy: behavioral rules compiled from the organization's manifest, enforced outside the agent process, with every intervention auditable.
  • Gated organization services — credential brokers and human-reviewed communication pipelines — are declared in the manifest and consumed identically by human and AI operators: gating is a property of the service, not of who is asking.

The shared design principle: external, inward-facing mechanisms (directories, mounts, proxies, repos) govern agents at boundaries they cannot avoid — never through any harness's internal machinery.

Public/Private Boundary

This repository is the generic mechanism and is public-safe. It must never contain organization content.

  • my (this repo, public) — the CLI: onboarding, manifest, skill, mount, catalog, and meeting mechanics. Generic. No customer data, no proprietary skills, no internal strategy.
  • <org>-manifest (private, control plane) — the org's definition layer: manifest.json, proprietary skills, product/repo catalog JSON, tool declarations, and agent guidance fragments. Admin-writable.
  • <org>-workspace (private, data plane) — the org's operating content: customers, meetings, support, fleet, decisions, policy, projects, people. Pushed by the whole organization.

The manifest repo stays outside the umbrella entirely; the workspace a user or agent browses is a mount of the content repositories the manifest defines. See docs/ARCHITECTURE.md for the full design rationale.

Roadmap

my is pre-alpha and evolving quickly. The phases, with detailed plans indexed in docs/plans/:

  • Shipped (v0.41.0) — open-issue simplicity sweep. This release adds push/PR CI, refreshes manifest-derived reads before serving them, handles deliberately local Gnit control roots without blocking member publication, makes session/base conflict checks path-aware, documents the work-session versus harness-chat boundary, and adds a deterministic least-privilege customer identity projection for detached CI. Older feature and refactor requests without demonstrated operational value were closed instead of expanding the CLI. Plan: open-issue simplicity sweep.

  • Shipped (v0.40.0; evidence corrected v0.40.1; sync auth corrected v0.41.1) — one-command, agent-guided first-machine bootstrap. A stable https://my-cli.com/install.sh entrypoint installs the release without Go, persists the user-local binary path, optionally registers an existing private manifest in the same command, and hands fresh interactive installs to an already-installed agent. Registered-but-unsynced manifests are now a resumable JOIN state; the guide walks GitHub authentication, setup, and required organization tools one issue at a time. GitHub HTTPS Git commands use the authenticated gh credential helper per invocation without global Git configuration changes, never prompt for passwords, and explain authentication failures. The v0.41.1 follow-up carries that same invocation-local credential environment through routine built-in sync fetches, pulls, and pushes. my setup and my onboarding --no-agent clone a registered-but-unsynced manifest themselves, and my doctor gains a prereq section (git, gh login, PATH, harness). Proven end to end on clean containers and against an authenticated macOS HTTPS mount. Plan: first-run bootstrap.

  • Shipped (v0.39.0) — leftover worktree detection and complete first run. my session leftovers and doctor now find raw harness-created worktrees through Git porcelain across content mounts and retained catalog clones. close-worktree can explicitly remove only a clean, named-branch leftover while preserving its branch; My AI never auto-prunes, force-removes, merges, or deletes it. Public Quickstart now covers prerequisites, WSL, both manifest creation and existing-manifest registration, setup, first launch, sessions, and publication. Plan: worktree leak detection and first run.

  • Shipped (v0.38.0) — Grok and Cursor CLI harnesses. Grok and Cursor remain distinct products and are integrated as distinct harnesses: both read generated AGENTS.md, receive launch-scoped organization skills through their proven project seams, support onboarding and My AI sessions, and get the bundled my-cli self-skill in their native user skill directories. Cursor launch resolution avoids the shared agent executable collision. Plan: Grok and Cursor harness integration.

  • Shipped (v0.37.0, beta) — governed organizations. The reviewed security core includes: provider-backed authorization, lossless revocation quarantine, digest-bound policy acceptance, launch gates, PR-only publication, trusted-base CI, and live GitHub enforcement audits. Manifest-routed generic records and the retryable publication outbox are hardened, and policy attestations now keep manifest commits as provenance without racing unrelated manifest advances. Acceptance evidence now has isolated durable PR publication, local/submitted/merge-proven reporting, trusted-branch CI enforcement for universal policies, and append-only administrative supersession. Umbrella-root contract authoring now proposes isolated manifest PRs without dirtying the sync-managed cache. Reciprocal linked-record CI is implemented. The documentation truth pass is complete: automatic revocation quarantine is explicitly an experimental endpoint-security plane with separate activation and real-world drill gates. Policy/record dogfood does not activate it. The final operator-package review also closed the original policy-authoring gap with digest-safe isolated policy proposals. A subsequent product review restored the intended human surface: employees use my ai, which handles exact-document policy review and acceptance inline; the detailed governance verbs remain agent/admin plumbing. Repeated live authorization work is now collapsed inside each launch to one actor lookup and one bounded-concurrent check per distinct repository, without adding an employee-facing control. The completed 2026-07-31 release plan added bare my meetings/my support list defaults, a safe runtime-state boundary for organization skills, policy-at-invocation guidance and projection, session refresh, and an approachable site walkthrough centered on the employee's my ai command. Sandbox BDD plus independent live read-only checks proved governed behavior, fail-closed digest drift, role scoping, and non-governed zero noise. Automatic revocation quarantine stays experimental behind its own unmet drill gate and is not part of the recommended beta surface. Plans: governed organizations, completion gates, and policy at invocation.

  • Shipped (v0.36.0) — target-aware coordinated publishing. Automatic sync and session publication route each exact Gnit roster member through coordinated publish while leaving unrostered checkouts on the guarded built-in path. The shared planner, scope preflight, dry-run parity, and doctor topology report were jointly reviewed and dogfooded. Plan: target-aware Gnit publishing.

  • Shipped (v0.35.0) — dogfood ergonomics audit. A reviewed two-agent audit of real operator transcripts produced small self-healing CLI fixes: clearer held-back sync reasons, publish-path warnings, session dead-end recovery, manifest control-plane publish paths, customer-record creation, and duplicate guidance dedupe. Plan: my-cli footgun audit.

  • Shipped — control/data-plane split (v0.13.x). A private manifest repo (the control plane) separate from workspace content repos (the data plane); my publish creates the private remotes; auto-publishing is gated on record adoption (my record adopt, Git intent-to-add). Plans: single-checkout workspace, execution plane (safety patch).

  • Shipped — work sessions, Mode A (v0.14.0–v0.17.0). my work start|status|list|resume|finish: visible work/<id> git worktrees per session, a session registry consulted by my sync and my doctor, session-aware content commands, and opt-in launches via my ai --new-session, --session, and -r/--resume (base umbrella remains the default). Session guidance now includes concrete startup context and is refreshed on resume. Plan: execution plane, Mode A.

  • Shipped — session command/layout consolidation (v0.34.0). my session start|join|resume|status|list|finish is the primary noun; my work remains a deprecated compatibility alias. New sessions use sessions/<id> and my/session/<id> with noun-free default ids; active legacy work/<id> sessions migrate lazily through session commands or my doctor --fix. Creating a session now prints id/path plus join and finish hints. Plan: session command ergonomics.

  • Shipped — products/repos split (v0.15.0). Catalog products are pure business entities (no git_url) that may link implementing repos; organization repositories live in catalog/repos.json with an my repos noun and --repo launch flags, cloned under repos/<id>. Plan: products/repos split.

  • Shipped — roles and services, Mode A (v0.18.0). Manifest roles and services sections describing the organization's remote surfaces (APIs, MCP servers, gated brokers), my services/my roles inspection verbs, my setup --role, umbrella-root .mcp.json materialized from checked-in or inline connection data — references only, never secrets or network fetches — and doctor service-health checks. Plans: execution plane, v0.18 scope.

  • Shipped — CLI package refactor (v0.19.0). The internal/cli package and its tests are split into cohesive per-domain files, leaving cli.go as a small app core/dispatcher/update shell and cli_test.go as shared helpers plus cross-cutting tests. Plan: CLI package refactor.

  • Shipped — contract rules and verbs (v0.20.0-v0.21.0). A built-in Fleet Work Contract in generated guidance and the bundled self-skill (start fleet work from my fleet get, record it in support records, carry identifiers), a support-record next-step hint in my fleet get output, a manifest contract list of short, binding org rules rendered as an ## Organization Contract section in AGENTS.md, and my contract list plus my admin contract add|remove for the standard inspect/review-commit-push workflow. Plan: contract rules.

  • Shipped — customer records move to the data plane (v0.22.0). my customers list now reads mounted customers/*.md records, customer alias resolution still feeds meetings/support/fleet filters, and my admin customers add|edit plus manifest catalog/customers.json loading/validation are removed. Plan: data surfaces, Slice 1.

  • Shipped — data bindings over surfaces (v0.23.0). Manifest data_bindings maps stable operational data nouns (customers, meetings, support, fleet) to existing mount:<id> or service:<id> surfaces. Mount-backed bindings narrow today's local record commands; service-backed domain invocation remains deferred. Plan: data surfaces, Slice 2.

  • Shipped — domain notes over bound surfaces (v0.24.0). Data bindings can carry labeled guidance fragments for their backing surfaces without changing the top-level org contract. This completes the near-term data-surface scope; service-backed domain invocation and contained runners remain future/YAGNI. Plan: data surfaces, Slice 3.

  • Shipped — contained runner launch projection (v0.25.0). Org-side launch-artifact projection (my compile): manifest + role + skills + mounts compile into a deterministic Clawdapus-facing JSON artifact for governed fleet agents, with baseline and manifest contract blocks preserved as enforce-level inputs. The Clawdapus pod/context emitter and descriptor fetch/cache remain later phases. Plans: compile launch projection, execution plane.

  • Shipped (v0.26.0) — human onboarding walkthrough. my onboard introduced a minimal human tour; my setup stays the deterministic machine configurator, with explicit my setup --interactive for prompting. Tour completion is stored umbrella-local; no new top-level verbs such as configuration, configure, or tour. Plan: onboarding walkthrough.

  • Shipped (v0.27.0) — launch-scoped skill composition. my ai composes manifest profile/skill selectors into disposable .agents/skills state under the launch root, with harness mirrors where a launch-root seam exists. Automatic setup/sync/doctor paths stop installing organization skills globally for launch-root-capable harnesses; OpenCode remains compatibility-global until a project-local skill seam is proven; the global my-cli self-skill remains during migration. Gemini harness support was removed entirely in favor of Antigravity (agy). Plans: launch-scoped skill composition, ADR 0001.

  • Shipped (v0.29.0), refined after dogfood — model-driven onboarding. my onboarding [--harness NAME] launches a harness with the bundled my-cli self-skill's Agent-Operated Onboarding guidance, and my onboard remains a compatibility alias. The launcher chooses AUTHOR vs JOIN from manifest state, uses direct harness exec for zero-manifest bootstrap, reuses my ai --setup when a manifest exists, and now teaches through split-pane command sets instead of an OK handshake. Onboarding stays focused on basic human workflows: launch harnesses, start/resume/finish sessions, check sync/doctor, and paste raw context into harness chat for agents to operate deeper record and admin commands. Publish remains behind my publish --print plus explicit human approval. Plan: model-driven onboarding.

  • Shipped (v0.33.0) — default manifests and self-skill rename. With multiple registered manifests, commands resolve explicit --manifest, then the current umbrella's manifest, then the registry default; my manifests default [<name>] [--clear] inspects or repoints that fallback. The bundled public self-skill install slug is now my-cli, while canonical id my:self remains stable and managed legacy my installs migrate automatically. Plan: skill rename.

  • Later — substrate upgrades. Managed read-only base mounts for contained launches. Target-aware Gnit publishing for sessions and ordinary sync is now implemented in the active issue #32 plan above. Plan: execution plane.

This section is kept current with every release and direction change; the per-plan status lives in docs/plans/README.md.

Design Documentation

  • docs/ARCHITECTURE.md — the design: concepts, the manifest schema, umbrella shape, mount scoping, skill resolution, the agents-primary philosophy, and the public/private boundary.
  • docs/PLAN.md — public-safe implementation plan: current baseline, active direction, and non-goals.
  • docs/plans/ — long-form design plans with a status index (active / shipped / superseded). Start with the execution plane for where the CLI is headed: sessions, contained runners, and organization services.
  • examples/acme-workspace — neutral split manifest/content fixture for local development.

Dependencies

Go standard library only. No third-party Go dependencies, by policy — supply chain surface is part of the threat model for a tool that installs things.

Contributing

The public repo carries the generic CLI and its tests only. Fixtures and examples use neutral placeholders (acme, example, sampleco). If a change would require organization-specific data to test, the test belongs against a private manifest, not here. go test ./... and go vet ./... must pass.

License

MIT — see LICENSE.

About

Manifest-backed AI workspace bootstrap CLI

Resources

Stars

1 star

Watchers

1 watching

Forks

Releases

Packages

Contributors

Languages