Menu
Release awid as a Docker image to GHCR. Tags awid-vX.Y.Z which triggers the Docker build workflow.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Add a teammate — one command (`aw team add … --start`) materializes an instance's home from a blueprint profile, sets up its isolated git worktree, and launches it. Use when a human asks for a teammate or assigned work needs one.
Check and set up the aweb channel connection. Verifies workspace binding, team-certificate bootstrap, and Claude Code plugin setup.
This skill should be used when staffing a team — instantiating, starting, onboarding, or retiring an agent built from a shipped blueprint profile. Covers materializing the agent home, running it live on the aweb channel, confirming the development-channel prompt deterministically, and handing it its first task over mail. The mechanics that turn a profile into a working teammate.
This skill should be used when recognizing or manually recovering legacy bootstrap-era `agents/` directories, or when migrating old bootstrap template repos toward primitive-first setup and resource packs. The `aw agents` command family is retired; do not recommend running it.
This skill should be used when joining or being added to an aweb team, picking the correct invite/add-member path for the team's authority model (hosted vs BYOT), accepting invites, fetching team certificates, switching the active team across multiple memberships, distinguishing hosted from Bring Your Own Team (BYOT) authority, running the fresh BYOT setup into aweb cloud, or diagnosing team-certificate and active-team failures. Use this whenever the question is about WHICH TEAM the agent acts in or how it became a member.
Remove a teammate — delete an instance's aweb identity and workspace, then its home, worktree, and branch. Use when an instance's job is done (a developer whose branch merged, a reviewer that gave its verdict).
| name | release-awid-docker |
| description | Release awid as a Docker image to GHCR. Tags awid-vX.Y.Z which triggers the Docker build workflow. |
| argument-hint | ["version"] |
The Docker release is triggered by pushing an awid-vX.Y.Z tag.
GitHub Actions runs .github/workflows/awid-release.yml, which
builds Dockerfile.release and pushes to GHCR.
Determine the version.
Use awid/pyproject.toml as the source of truth.
Sync uv.lock.
The Docker build uses uv sync --locked. If uv.lock is stale
the build fails with "The lockfile at uv.lock needs to be updated."
cd awid && uv lock
Run tests.
cd /path/to/aweb && uv run --project awid pytest awid/tests -q
Run Docker build check.
make release-awid-check
Bump version, commit, tag.
git add awid/pyproject.toml awid/uv.lock
git commit -m "release: awid-service <VERSION>"
git tag awid-v<VERSION>
git tag awid-service-v<VERSION>
Push.
git push origin main
git push origin awid-v<VERSION>
git push origin awid-service-v<VERSION>
If you bump the version in pyproject.toml without running uv lock,
the Docker build will fail. This happened with awid 0.2.5. Always
run uv lock after version bumps.
PyPI is immutable. If you tag awid-service-vX.Y.Z, it publishes. If you then force-push the tag to a different commit, PyPI rejects the second publish (version already exists). Bump the version instead (e.g., 0.2.5 -> 0.2.6). This happened with awid 0.2.5/0.2.6.
awid-vX.Y.Z) and PyPI tag (awid-service-vX.Y.Z)
are separate workflows but usually created together.make release-awid-check runs tests, builds the package, and does
a local Docker build to verify.