Menu
Coordinate changes that touch both the aweb OSS repo and the aweb-cloud repo. OSS lands first, releases to PyPI, cloud pins and deploys.
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 | cross-repo-change |
| description | Coordinate changes that touch both the aweb OSS repo and the aweb-cloud repo. OSS lands first, releases to PyPI, cloud pins and deploys. |
Changes that affect both aweb (OSS) and aweb-cloud must be coordinated carefully because the cloud embeds aweb as a PyPI package.
The cloud imports aweb. Both deploy in the same Docker image. There is no transition period — when the cloud pins a new aweb version, both the old and new code deploy atomically.
Design — agree on the contract change between OSS and cloud. Identify which side goes first.
OSS first — land the OSS change on aweb main. Run all tests.
Release — bump version, tag, push. Wait for PyPI to publish. Verify with:
curl -s https://pypi.org/pypi/aweb/<VERSION>/json | python3 -c "import sys,json; print(json.load(sys.stdin)['info']['version'])"
Cloud pins — update backend/pyproject.toml to aweb>=<VERSION>,
run uv lock, run tests.
Cloud change — land the cloud-side change in the same commit or immediately after the pin bump.
Verify — cloud tests pass against the real aweb package (not editable/sibling source).
aweb-cloud maintains its own copy of the OSS schemas. The cloud's
migration_paths.py points at backend/src/aweb_cloud/migrations/aweb/
and migrations/server/ — NOT at the OSS package's migrations in the
installed .venv. So when an OSS release adds or alters a schema the
cloud uses, the cloud needs a paired mirror migration with a matching
ALTER/CREATE.
The migrations to mirror can live in DIFFERENT OSS tree subdirectories within the same release. Easy to miss the second one when walking commit by commit:
awid/src/awid_service/migrations/*.sql → mirror in cloud as
migrations/aweb/.server/src/aweb/migrations/aweb/*.sql → also mirror in cloud as
migrations/aweb/ (same target dir, different OSS source dir).When reviewing a cross-repo bundle, grep ALL OSS migration trees touched in the bundle, not just the first one you find. Pattern-blindness on the second mirror is the failure mode.
Each mirror file should be a one-statement ALTER/CREATE matching the OSS content, with a header comment naming the OSS source path so the lineage is explicit.
../aweb-cloud relative to the aweb
workspace.