feat: create profile based on workspace

[christso]

Problem

Creating a reusable agent profile for a workspace currently requires imperative, user-specific setup. For example, setting up a Compound Engineering OMP profile requires:

omp --profile compound-engineering --alias omp-compound
omp --profile compound-engineering plugin marketplace add EveryInc/compound-engineering-plugin
omp --profile compound-engineering plugin install compound-engineering@compound-engineering-plugin

This creates a shell function in ~/.bashrc:

omp-compound() {
    command omp --profile=compound-engineering "$@"
}

The profile's isolated state is stored at:

~/.omp/profiles/compound-engineering/agent

The command must then be made available by restarting the shell or sourcing ~/.bashrc. The workspace declaration does not currently describe this named profile, its generated launcher command, or the fact that the Compound Engineering plugin must be installed natively into that OMP profile. Users must discover and run the setup steps separately.

Feature request

Precise terminology

This issue uses the following terms deliberately:

• Workspace profile: a named declarative configuration in workspace.yaml; it is not necessarily a native profile object in the target runtime.
• Native runtime profile: a first-class profile mechanism provided by the runtime, such as OMP --profile or Codex --profile.
• Isolated configuration root: a separate user-state directory selected through a runtime environment variable or equivalent when no native profile API exists, such as COPILOT_HOME or CLAUDE_CONFIG_DIR.
• Launcher: the generated command that selects the runtime target and forwards arguments. AllAgents should generate an executable wrapper/launcher for the target, not a shell alias. For OMP, omp-compound should be an executable wrapper that invokes omp --profile=compound-engineering "$@"; OMP's --alias option is an existing OMP-specific shell-function shortcut, not the generic AllAgents command surface.
• Native installation: invoking the target runtime's own plugin/package installation commands in the selected native profile or isolated configuration root. It is distinct from copying files into a project client directory.

Allow a profile to be created from a workspace declaration, with support for these runtimes:

• Pi
• OMP (Oh My Pi)
• GitHub Copilot CLI
• OpenAI Codex CLI
• Claude Code

A workspace should be able to define the complete agent composition for each declared runtime target, including:

• runtime and profile/configuration-root selection;
• generated CLI launcher command;
• skills and their discovery/enabling rules;
• plugins/extensions/packages to install, link, or enable, with installation scoped to the selected profile where appropriate;
• MCP servers, transports, configuration, and secret references;
• runtime-specific instructions and settings.

The Compound Engineering profile is the canonical example:

• profile: compound-engineering;
• OMP launcher command: omp-compound;
• plugin: EveryInc/compound-engineering-plugin;
• installation mode: OMP native marketplace/plugin installation, not file-copy sync.

For OMP, the native installation flow documented by the plugin is:

omp --profile compound-engineering plugin marketplace add EveryInc/compound-engineering-plugin
omp --profile compound-engineering plugin install compound-engineering@compound-engineering-plugin

The generated omp-compound command must invoke that same named profile and preserve normal OMP argument pass-through.

This must be an adapter-based feature, not an assumption that all five runtimes share the same config format or profile primitive. The implementation must read official documentation and, where behavior is not fully documented, inspect upstream source before selecting paths, precedence, installation, or cleanup behavior.

Explicit scope boundary

Pi does not provide MCP in its core runtime. The supported Pi MCP path is the external pi-mcp-adapter, installed as a Pi package (for example, pi install npm:pi-mcp-adapter) and configured through the adapter's documented MCP files. AllAgents must not extend or fork Pi to add MCP.

Adding AllAgents support for Pi extensions and automatic pi-mcp-adapter installation/configuration is deferred to a later PR. This issue should define the capability boundary and an adapter seam, but the current profile-installation work must treat those Pi capabilities as unsupported until that follow-up lands.

Current allagents gap

The current workspace.yaml model supports top-level clients, plugin clients, and file/native install modes, but it does not model named profiles as first-class installation targets. In particular:

• ClientTypeSchema does not currently include omp;
• client entries do not carry a named profile/configuration-root or generated launcher command;
• plugin entries can select clients and install mode, but cannot bind native installation to a named profile;
• the existing plugin-stack example performs project-scoped file sync for Codex, Copilot, and Claude, not native OMP installation into an isolated OMP profile.

The workspace YAML schema must be extended so profile-based installation is distinct from the existing default/client installation path while preserving backward compatibility for current workspaces. An illustrative shape (schema to be designed) is:

profiles:
  compound-engineering:
    clients:
      - name: omp
        install: native
        launcher: omp-compound
    plugins:
      - source: EveryInc/compound-engineering-plugin
        install: native

The final schema may differ, but it must express the profile name, runtime, profile-scoped installation mode, launcher command, plugin source/ref, and profile-specific skills/MCP/settings without making the default client profile implicit.

OMP support PR

AllAgents currently does not support omp as a client/runtime. Add OMP support in a separate PR linked to this issue. That PR should at minimum:

• add omp to the supported client schema and validation;
• implement OMP project/file synchronization where that is the selected mode;
• implement OMP native installation through the OMP CLI, including marketplace registration and plugin installation;
• ensure native commands target the selected OMP profile rather than the default profile;
• support the Compound Engineering plugin as a real integration fixture;
• add focused schema, command, and reconciliation tests;
• document OMP-specific paths, trust behavior, reload requirements, and uninstall/cleanup behavior.

The profile-based installation work should link to and consume that PR rather than silently treating OMP as another file-copy client.

Research baseline

The runtimes have materially different isolation models and terminology:

Runtime	Confirmed profile/config model	Capability sources to map
Pi	No documented named-profile command. Project/user settings and session directories can be redirected, but that is directory isolation rather than a native profile API.	Agent Skills (SKILL.md), TypeScript extensions, and installable Pi packages. Pi core does not provide MCP; MCP integration requires the pi-mcp-adapter.
OMP	First-class --profile <name> / OMP_PROFILE; native user state moves under ~/.omp/profiles/<name>/agent. --profile <name> --alias <command> generates a shell shortcut.	Native skills/extensions, marketplace plugins, and project/profile MCP configuration.
GitHub Copilot CLI	No documented named-profile command. COPILOT_HOME relocates the user configuration root and can provide disposable directory isolation.	SKILL.md, plugin.json plugins, user/project MCP configuration, instructions, agents, and hooks.
Codex CLI	First-class codex --profile <name> config overlay. CODEX_HOME is separate state-root isolation and must not be confused with the profile TOML overlay.	.agents/skills, .codex-plugin/plugin.json plugins, config.toml MCP servers, and project/user config layers.
Claude Code	No documented named-profile command. CLAUDE_CONFIG_DIR relocates user settings/history/plugins and can provide disposable directory isolation.	CLAUDE.md, .claude/skills, .claude-plugin/plugin.json plugins, project/user MCP configuration, and hooks.

Primary documentation and source starting points:

• AllAgents workspace schema
• AllAgents plugin-stack example
• Pi settings, skills, extensions, and packages, and pi-mcp-adapter, and pi-mcp-adapter
• OMP repository, configuration discovery, MCP, and marketplace plugins
• GitHub Copilot CLI configuration directory, skills, MCP, and plugins
• Codex configuration, skills, MCP, and plugins
• Claude Code settings, skills, plugins, and MCP
• Compound Engineering installation instructions

These links are evidence for the capability map, not a claim that the runtimes have identical semantics. Supported versions and behavior must be pinned or tested.

Desired workflow

From a workspace containing the declaration, a user should be able to run one setup command that:

1. reads and validates the workspace's profile definitions;
2. creates or updates each declared runtime target, using a native runtime profile when available and an isolated configuration root when it is not;
3. installs or links the declared plugins/extensions/packages using the selected native runtime profile or isolated configuration-root scope;
4. enables the declared skills and MCP configuration;
5. creates the runtime-specific CLI entry points;
6. allows each generated command to be launched from any directory while retaining the declared profile configuration;
7. passes arbitrary runtime arguments through to the selected profile.

A repeat run should be idempotent and reconcile changes to the workspace declaration. Secrets must be referenced through environment variables or an existing credential store; credentials must not be copied into the workspace declaration.

Dogfood requirement

The feature must be dogfooded against a real workspace before being considered complete. Use a disposable profile name or configuration root and exercise the same flow a user will use:

1. create each runtime target from the workspace declaration;
2. launch each supported runtime through its generated CLI command from a fresh shell;
3. verify that the declared skills, plugins/extensions/packages, MCP servers, instructions, settings, and runtime arguments are actually loaded;
4. verify target isolation by checking that the default runtime profile/configuration root and unrelated profiles are unchanged;
5. change the declaration and repeat setup to verify reconciliation/idempotence;
6. stop all test processes;
7. remove the generated commands, profile-local state, profile-scoped installations, temporary project resources, and test MCP registrations.

Cleanup must be explicit and observable. Prefer each runtime's native remove/uninstall command so registries, locks, symlinks, and OAuth records are updated. Only delete a disposable profile/configuration root after no process owns it. Cleanup must not delete the user's default profile, unrelated profiles, shared package caches, committed workspace files, or credentials outside the disposable scope.

The initial dogfood fixture is the Compound Engineering OMP profile: create compound-engineering, install the plugin natively with the two OMP commands above, generate an executable omp-compound launcher in the user's PATH (for Linux, preferably an XDG user bin directory such as ~/.local/bin), verify omp-compound --version and profile-specific configuration in a fresh shell, verify that Compound Engineering skills are loaded, then remove the plugin, marketplace registration, profile state, and generated launcher. The test must leave no compound-engineering profile or omp-compound launcher behind.

Acceptance criteria

• A workspace can declare named runtime targets for Pi, OMP, Copilot CLI, Codex CLI, and Claude Code in a documented YAML format; native runtime profiles are used only where the target runtime supports them.

• Profile declarations express runtime, profile/configuration-root selection, launcher command, skills, plugins/extensions/packages, MCP servers, runtime instructions, and settings.

• Existing top-level/default client and plugin declarations remain backward compatible.

• Native runtime profiles are used where supported; isolated configuration roots are used where a runtime has no native named-profile API.

• Native installation is executed in the selected profile scope. For OMP, Compound Engineering is installed through the native marketplace/plugin commands rather than file-copy synchronization.

• AllAgents validates and supports omp as a client/runtime in a separate linked PR.

• Generated commands pass through arbitrary arguments to the selected runtime/profile.

• The default Linux launcher is an executable wrapper discoverable through PATH; setup must not mutate ~/.bashrc or depend on an interactive shell startup file. OMP's --alias may remain an explicitly documented compatibility option, but it is not the AllAgents launcher implementation.

• Profile state remains isolated from each runtime's default profile and from other named profiles.

• Re-running setup is safe and reconciles changes to the workspace declaration.

• The dogfood flow verifies real startup/loading behavior in fresh shells for every supported runtime available in the test environment.

• Cleanup removes all disposable profile artifacts, registrations, profile-scoped installations, and generated launchers while preserving unrelated user state.

• Setup reports actionable errors for invalid declarations, unavailable runtimes/plugins, unsupported capabilities, or unavailable MCP servers.

• Documentation explains the workspace declaration, generated commands, runtime-specific limitations, secret handling, dogfood procedure, and cleanup procedure.

Open design questions

• Which workspace file and schema should own the profile declarations?
• Is one normalized declaration with runtime-specific sections preferable to separate manifests per runtime?
• Should profile declarations be keyed by profile name or represented as an array to allow duplicate runtime targets?
• Should plugins/extensions/packages be copied, linked, or installed into profile-local storage?
• Which capabilities can be shared across runtimes, and which require adapters?
• How should version pinning and upgrades be represented?
• How should secrets in MCP configuration be referenced without committing credentials?
• On Linux, should the default launcher location be ~/.local/bin or $XDG_BIN_HOME, and how should other platforms provide an equivalent executable wrapper?
• What is the supported deletion operation for each runtime, and how can cleanup be made safe and reversible?