Best for
- Use when configuring parallel agent sessions, authoring awman workflows, driving the awman api server, managing worktrees, migrating from amux, or troubleshooting awman container runs.
vinnie357/claude-skills/plugins/tools/awman/skills/awman/SKILL.md
Guide for using awman to run AI coding agents in isolated containers with multi-step workflows and a REST API. Use when configuring parallel agent sessions, authoring awman workflows, driving the awman api server, managing worktrees, migrating from amux, or troubleshooting awman container runs.
Decision brief
awman is a Rust CLI and TUI for running AI coding agents (Claude Code, Codex, OpenCode, and others) in isolated Docker or Apple Containers sandboxes. It coordinates parallel agent sessions, executes multi-step workflows, and exposes a REST API for headless programmatic control.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/vinnie357/claude-skills --skill "plugins/tools/awman/skills/awman"Inspect the Agent Skill "awman" from https://github.com/vinnie357/claude-skills/blob/258ac739a89d44fc78ad40e5724eb0526ff11d75/plugins/tools/awman/skills/awman/SKILL.md at commit 258ac739a89d44fc78ad40e5724eb0526ff11d75. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Workflows are TOML (.toml) or YAML (.yml/.yaml) files authored via awman new workflow [--interview] and executed via awman exec workflow . Markdown (.md) workflows are no longer supported as of 0.9.1.
A container runtime, set via the global-only runtime config key (awman config set --global runtime , then awman ready):
Mise is the recommended install path. It manages the version, pins reproducibly, and uses the GitHub releases backend — no extra dependencies.
The rename is automatic for existing users:
awman is pre-1.0 and ships frequently. Run these before trusting that docs match the installed binary:
Permission review
The documentation asks the agent to create, modify, or delete local files.
Containers run `--rm` and auto-remove at session end. Only the Git repository is bind-mounted; `/workspace` inside the container is ephemeral beyond what lands in the Git tree.Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 94/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 24 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
awman is a Rust CLI and TUI for running AI coding agents (Claude Code, Codex, OpenCode, and others) in isolated Docker or Apple Containers sandboxes. It coordinates parallel agent sessions, executes multi-step workflows, and exposes a REST API for headless programmatic control.
awman is not a tmux wrapper. The name invites that assumption. awman ships its own tab-based TUI with its own keybindings. Tmux is not a dependency.
awman was previously named amux. See "Migrating from amux" below.
Source: https://github.com/prettysmartdev/awman (accessed 2026-07-13) License: Apache-2.0 | Latest at research time: v0.11.0 (2026-07-13)
A container runtime, set via the global-only runtime config key (awman config set --global runtime <value>, then awman ready):
runtime value | Platforms | Requirements |
|---|---|---|
docker (default) | Linux, macOS, Windows | Docker daemon |
apple-containers | macOS 26+ | native container CLI |
docker-sbx-experimental | macOS arm64, Windows x86_64 | sbx CLI (brew install docker/tap/sbx + sbx login) |
docker-sbx-experimental (new in 0.10.0) runs each session in a dedicated microVM — private kernel, filesystem, and Docker daemon. It does not honor dir(), skill, or context overlays; networking goes through an HTTP/HTTPS proxy (raw TCP/UDP blocked); sandboxes persist between sessions. The runtime must be running and healthy before any awman session starts. This runtime requires a free Docker account; sbx login is a one-time authentication step that must complete before awman ready reports the runtime healthy.
Mise is the recommended install path. It manages the version, pins reproducibly, and uses the GitHub releases backend — no extra dependencies.
A ready-to-copy pin lives at templates/0.11.0/mise.toml in this skill — copy it into the target repo's mise.toml (or merge under [tools]) and run mise install.
Global pin (one-time, any project):
mise use -g github:prettysmartdev/[email protected]
Per-project pin (recommended for repos that run awman):
cp templates/0.11.0/mise.toml <your-repo>/mise.toml # then: cd <your-repo> && mise install
The template's contents:
[tools]
"github:prettysmartdev/awman" = "0.11.0"
Verify:
mise which awman && awman --version
Fall back to the upstream installer (curl -s https://prettysmart.dev/install/awman.sh | sh) only when mise is unavailable (locked-down CI image, no GitHub release network access). State the reason explicitly when doing so. Building from source requires Rust 1.94+ and make (git clone https://github.com/prettysmartdev/awman.git && cd awman && make install). Do not use Homebrew, asdf, or mason — none are documented by upstream.
The rename is automatic for existing users:
AMUX_* environment variables to AWMAN_* and you are done.awman; the installer offers to clean up old amux binaries.headless.* are now under api.* (e.g. headless.workDirs → api.workDirs).amux headless start is now awman api start.aspec/.amux.json to GITROOT/.awman/config.json (see Config below)..md) are no longer supported — use TOML or YAML.awman is pre-1.0 and ships frequently. Run these before trusting that docs match the installed binary:
awman --version
awman config show
awman config show prints the merged effective config (global + per-repo). Use it to verify runtime, default_agent, and overlay state rather than reading JSON files directly.
| Command | Purpose |
|---|---|
awman init [--aspec] [--agent <name>] | Scaffold project: writes .awman/config.json and per-agent Dockerfiles |
awman ready [--refresh] | Verify environment; --refresh re-audits and rebuilds the agent Dockerfile |
awman chat [--agent <name>] [--auto] [--yolo] | Interactive agent session in a TUI tab |
awman exec prompt "<text>" [--issue <ref>] | One-off prompt without a persistent session |
awman exec workflow <path> [--work-item <nnnn> | --issue <ref>] [--yolo] [--worktree] [--max-concurrent <n>] | Run a multi-step workflow file |
awman exec workflow --dynamic --work-item <N> [--leader <agent::model>] | Leader agent designs and runs a workflow (0.11.0) |
awman clean [--dry-run] [--yes] | Remove stopped containers, dangling images, completed-workflow data (0.11.0) |
awman new spec|workflow|skill [--interview] [--issue <ref>] | Scaffold a work item, workflow, or custom skill |
awman specs amend <nnnn> | Update an existing work item |
awman status [--watch] | Session/workflow dashboard |
awman config show|get|set [--global] | Inspect/modify merged config |
awman api start|status|logs|kill | Manage the REST API server (default port 9876) |
awman remote run|session | Drive a remote awman api server |
awman (no args) | Open the TUI |
See templates/0.11.0/commands.md for the full v0.11.0 command surface with flags and examples.
--issue <ref> on new spec, exec workflow, and exec prompt fetches a GitHub issue and injects it. Reference forms: bare number (--issue 84, requires a GitHub origin remote), shorthand (--issue owner/repo#84), or full URL. Auth resolution: gh CLI → GITHUB_TOKEN → unauthenticated REST (public repos, 60 requests/hour). For exec workflow the issue populates the {{work_item_*}} template variables exactly as --work-item does; --issue and --work-item are mutually exclusive.
awman exec workflow --dynamic --work-item <N> launches a leader agent that reads the work item, designs a workflow.toml, and executes it — no hand-authored workflow file. --dynamic auto-enforces --yolo, --worktree, and the context(workflow) overlay; passing them explicitly is a no-op, and --dynamic rejects a workflow path, --plan, or a missing --work-item.
Leader resolution (highest wins): --leader <agent::model> flag → dynamicWorkflows.defaultLeader config → --model on the project default agent → project default agent and model. The dynamicWorkflows config section constrains the plan: agentsToModels (approved agent→model map; empty falls back to Dockerfile discovery), maxConcurrentSteps (advisory, not runtime-enforced), and guidance (project instructions injected into the leader prompt, max 50 × 1,000 chars). An invalid generated workflow triggers a repair agent up to 3 times. See references/config.md for the key schema.
Workflow steps with identical depends_on sets form a parallel group and run concurrently. Cap simultaneous containers with maxConcurrentAgents; precedence: --max-concurrent flag → AWMAN_MAX_CONCURRENT_AGENTS env → repo config → global config → unlimited. 1 disables parallelism; 0 is rejected. A failed step without abort_on_failure lets siblings continue; abort_on_failure = true kills all active peers. Stuck detection (30 s) and yolo countdowns (60 s) track per container. See references/config.md for the maxConcurrentAgents key schema and references/workflows.md for full parallel-group grammar and worked examples.
TUI: Ctrl-S rotates focus between parallel containers; Ctrl-G toggles a git sidebar (per-file +/- counts, ~2 s refresh, compact +X -Y in the status bar when closed); Ctrl-, opens the config dialog (Ctrl+N adds nested dynamicWorkflows entries).
awman clean [--dry-run] [--yes] removes stopped containers, dangling awman-labeled images, and completed-workflow data (repo .awman/workflows/ state, ~/.awman/context/workflows/ dirs). In-progress workflows and active containers are preserved. Failed step output (~100 lines) lands in ~/.awman/logs/{workflow-id}-{step-name}-{container-name}.log — created on demand, never auto-cleaned (not even by awman clean). Teardown on_failure remediation agents receive the failed command's output as a readable file; setup on_failure agents do not. See references/workflows.md.
Supported agents: claude, codex, opencode, maki, antigravity, copilot, crush, cline.
geminiis deprecated by Google upstream. Migrate toantigravity(awman chat --agent antigravityorawman config set agent antigravity). Thegeminiagent name remains accepted but logs a deprecation warning and has degraded system-prompt-injection support.
Each agent has a Dockerfile in .awman/Dockerfile.<agent> (seeded from upstream templates). Customize the Dockerfile to add tools or environment configuration for that agent. The project base image path is configurable via the per-repo dockerfile config key (default Dockerfile.dev) as of 0.10.0.
Selection precedence (highest wins):
agent: field in the workflow file--agent <name> flag on the CLI invocationagent key in per-repo .awman/config.jsondefault_agent key in ~/.awman/config.json (global default; factory default: "claude")Opt-in via --worktree on awman chat / awman exec. All steps in a single workflow run share one worktree.
Worktrees are never auto-deleted. At session end, awman prompts: merge / discard / keep. On abort, the worktree is preserved for manual inspection. Monitor disk use when running repeated --yolo --worktree workflow runs.
Containers run --rm and auto-remove at session end. Only the Git repository is bind-mounted; /workspace inside the container is ephemeral beyond what lands in the Git tree.
awman reads one config.json per scope:
| File | Scope | Created by | Commit? |
|---|---|---|---|
~/.awman/config.json | Global | Manually or awman config set --global | No |
GITROOT/.awman/config.json | Per-repo | awman init | Yes |
Per-repo takes precedence on overlapping scalar keys. The overlays string array merges additively across all sources (global config, repo config, AWMAN_OVERLAYS, --overlay flags, workflow steps); other list fields replace. The repo .awman/ directory also holds per-agent Dockerfiles seeded by awman init. XDG base-directory environment variables are honored as of 0.10.0. Always use awman config show to see merged values rather than hand-editing the JSON.
See references/config.md for the full per-key schema (type, default, scope, merge behavior).
Overlay specs grant agent containers access to host resources: dir(HOST:CONTAINER[:ro|rw]), ssh(), env(VAR), skill(*)/skill(NAME), and — new in 0.10.0 — context(global|repo|workflow[:ro]). Context overlays combine a persistent host directory (~/.awman/context/...) with automatic system-prompt injection, giving agents a durable shared workspace across sessions; they default to rw so agents accumulate knowledge — pass :ro to lock them. On host-path conflicts, :ro always overrides :rw. See references/config.md for the full overlay grammar.
To make an agent use a local provider or custom endpoint, forward the relevant vars via env() overlays:
{
"overlays": [
"env(ANTHROPIC_BASE_URL)",
"env(ANTHROPIC_API_KEY)"
]
}
Or one-off via CLI flag (repeatable, or comma-separated in a single flag):
awman chat --overlay "env(ANTHROPIC_BASE_URL)" --overlay "env(ANTHROPIC_API_KEY)"
# or
awman chat --overlay "env(ANTHROPIC_BASE_URL),env(ANTHROPIC_API_KEY)"
If ANTHROPIC_BASE_URL is not set on the host, awman silently omits it — not an error.
envPassthroughis removed in 0.10.0. The oldenvPassthrougharray config key no longer works;awman config get envPassthroughreturns a removal notice. Express env forwarding asenv()overlay entries in theoverlaysarray (config file,AWMAN_OVERLAYS, or--overlayflag) instead. Seereferences/config.mdfor the migration table.
awman api start runs a REST server on port 9876 (configurable via --port). It serves HTTPS with a self-signed certificate by default — pass --dangerously-skip-tls for plain HTTP in trusted local setups. It accepts bearer-token auth. Sessions are restricted to directories in api.workDirs (global config) or passed via --workdirs.
FIFO queue per session. Submitting a second command while one is in flight enqueues it — submission never blocks and returns immediately with a command_id. Poll GET /v1/commands/:id or stream /v1/commands/:id/logs/stream (Server-Sent Events) to track progress. A POST /v1/sessions with a workdir outside the allowlist returns HTTP 403.
Prefer awman remote over raw curl when driving the server from the CLI — it carries auth and the session header per the operator-tooling-first convention.
See references/api.md for the full endpoint table and curl examples.
Workflows are TOML (.toml) or YAML (.yml/.yaml) files authored via awman new workflow [--interview] and executed via awman exec workflow <path>. Markdown (.md) workflows are no longer supported as of 0.9.1.
Step fields are lowercase only: name and prompt are required; depends_on, agent, model, and overlays are optional. Template variables available in prompts: {{work_item_number}} (zero-padded 4-digit), {{work_item}} (bare number), {{work_item_content}} (full file or fetched issue), {{work_item_section:[Name]}} (named section).
New in 0.10.0, workflows support setup and teardown phases with typed steps (clone_repo, checkout_create_branch, run_shell, commit_changes, push_branch, create_pull_request, …), including poll_ci (block until the branch's GitHub Actions run completes; interval_secs/max_retries) and per-step on_failure blocks that launch a remediation agent and retry the step up to max_attempts times.
See references/workflows.md for grammar in both formats and worked examples.
--dangerously-skip-tls (server side) or trusting the self-signed cert.runtime is global-only. No per-repo runtime selection.docker-sbx-experimental skips all overlays. dir(), skills, and context mounts are not honored; networking is proxy-only; sandboxes persist between sessions and lose port mappings on stop.--issue and --work-item are mutually exclusive. Bare --issue <N> requires a GitHub origin remote — use owner/repo#N or a URL otherwise.rw. Use context(SCOPE:ro) to stop agents from modifying accumulated knowledge.envPassthrough is removed. The old config key returns a removal notice. Use env() overlay entries in the overlays array instead.gemini is deprecated. Use antigravity as the replacement (awman config set agent antigravity).--dynamic force-enables --yolo, --worktree, and context(workflow). There is no supervised dynamic mode.maxConcurrentAgents means unlimited parallelism. 1 disables it; 0 is rejected.~/.awman/logs/ grows unbounded. awman clean does not remove failure logs.on_failure gets no automatic output capture. Only teardown steps hand the failure output to the remediation agent.awman --version when output looks unexpected. Pin in mise to control when you upgrade.references/api.md — REST endpoint table, bearer auth, curl examplesreferences/workflows.md — Workflow grammar in TOML and YAMLreferences/config.md — Per-key config schema for both scopesreferences/command-reference.md — Full CLI surface with flags and examplestemplates/0.11.0/commands.md — Immutable v0.11.0 command snapshottemplates/0.10.0/commands.md — Immutable v0.10.0 command snapshot (previous version)templates/0.9.1/commands.md — Immutable v0.9.1 command snapshotRun awman --version and awman config show before asserting that any documented behavior matches the installed binary. awman is pre-1.0 and minor bumps carry breaking changes. Every command form in this skill traces to upstream docs sourced from https://github.com/prettysmartdev/awman (accessed 2026-07-13). Mark any behavior not confirmed by that source as "requires verification against awman v0.11.0 source." Apply /core:anti-fabrication rules to all outputs produced with this skill active.
Frequently asked questions
awman is a Rust CLI and TUI for running AI coding agents (Claude Code, Codex, OpenCode, and others) in isolated Docker or Apple Containers sandboxes. It coordinates parallel agent sessions, executes multi-step workflows, and exposes a REST API for headless programmatic control.
The source record exposes this install command: npx skills add https://github.com/vinnie357/claude-skills --skill "plugins/tools/awman/skills/awman". Inspect the command and pinned source before running it.
Static rules flagged write-files in the source; the page lists the matching lines and excerpts.
Alternatives
garrytan/gbrain
End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.
alirezarezvani/claude-skills
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
dotnet/skills
Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing
oaustegard/claude-skills
Generate hierarchical _FEATURES.md files that describe what a codebase DOES from a user/consumer perspective, anchored to source symbols via tree-sitting. Supports large complex codebases through feature-driven decomposition into sub-feature files. Uses a multi-pass synthesis: orientation → detail → overview rewrite. Use when someone says "what does this do", "document features", "feature inventory", "_FEATURES.md", or needs to understand a codebase's purpose before modifying it. Complements tre