@awebai/claude-skills 0.2.10 → 0.2.12

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "aweb-skills",
3
- "version": "0.2.10",
3
+ "version": "0.2.12",
4
4
  "description": "aweb agent coordination skills: teach your Claude Code agent how to use the aw CLI for mail, chat, tasks, and team coordination.",
5
5
  "author": {
6
6
  "name": "awebai"
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@awebai/claude-skills",
3
- "version": "0.2.10",
3
+ "version": "0.2.12",
4
4
  "description": "Content-only Claude Code plugin shipping the canonical aweb agent-coordination skills: aweb-coordination, aweb-messaging, aweb-team-membership, aweb-bootstrap, aweb-identity.",
5
5
  "license": "MIT",
6
6
  "homepage": "https://aweb.ai",
@@ -1,267 +1,448 @@
1
1
  ---
2
2
  name: aweb-bootstrap
3
- description: This skill should be used when helping a human create or join an aweb team from a template (aw team bootstrap), choosing a template and team source (hosted new team, BYOT, API key, invite, or current workspace forwarding), selecting work-directory vs work-repo-url, provisioning optional worktree agents, and validating/re-running bootstrap safely.
3
+ description: This skill should be used when helping a human create, provision, add, or remove repo-local aweb agents with the `aw agents` lifecycle from a template, choosing a team source (hosted new team, BYOT, API key, invite, or current workspace forwarding), using the project-local agents/ layout, provisioning optional worktree-bound agents, and validating/re-running safely.
4
4
  allowed-tools: "Bash(aw *)"
5
5
  ---
6
6
 
7
7
  # aweb Bootstrap
8
8
 
9
- Use this skill when a human wants to create or extend an aweb team from a reusable template, and you need to guide them through `aw team bootstrap` decisions and validation.
9
+ Use this skill when a human wants to create or extend a repo-local
10
+ aweb agent team from a reusable template, and you need to guide them
11
+ through `aw agents` decisions and validation.
10
12
 
11
- This skill is about **mental model + decision policy + safe execution**, not memorizing flags.
13
+ This skill is about **mental model + decision policy + safe
14
+ execution**, not memorizing flags.
12
15
 
13
16
  Related skills:
14
17
 
15
18
  - For day-to-day coordination once the team exists: `aweb-coordination`
16
19
  - For mail/chat response policy: `aweb-messaging`
17
- - For joining an existing team, multi-team membership, custody, addressability, and contacts: `aweb-team-membership`
20
+ - For joining an existing team, multi-team membership, custody,
21
+ addressability, and contacts: `aweb-team-membership`
18
22
 
19
23
  Long-form reference: docs/team-bootstrap.md in the aweb repo.
20
24
 
21
25
  ## Mental model: what bootstrap is assembling
22
26
 
23
- `aw team bootstrap` combines four separate things that are easy to confuse:
27
+ `aw agents bootstrap` combines five separate things that are easy to
28
+ confuse:
24
29
 
25
30
  1) Template repo — the blueprint.
26
31
 
27
- - Contains `team.yaml`, role playbooks, shared instructions, and `agents/<responsibility>/AGENTS.md` files.
28
- - The template says what responsibilities should exist and which `role_name` each should use.
29
-
30
- 2) Work directory or work repo — the thing agents work on.
31
-
32
- - `--work-directory` points at an existing folder.
33
- - `--work-repo-url` clones a repo into `<template>/worktrees/<derived-name>/` and uses that clone as the work directory.
34
- - Each responsibility workspace gets this directory symlinked as `./work`.
32
+ - Contains `team.yaml`, role playbooks, shared instructions, and
33
+ `home/<responsibility>/AGENTS.md` files.
34
+ - The template says what responsibilities should exist and which
35
+ `role_name` each should use.
36
+ - The template is identity-free. Do not put final aliases, DIDs,
37
+ global addresses, certs, or per-human state in committed
38
+ `team.yaml`.
39
+
40
+ 2) Generated project-local agents directory — where humans start agents.
41
+
42
+ - By default, run bootstrap from the root of the work repo.
43
+ - Bootstrap creates `agents/` in that repo. Every live agent home is
44
+ under `agents/home/<responsibility>/`.
45
+ - The coordinator/global-style home normally has `work -> <repo-root>`.
46
+ - Worktree-bound homes still live under
47
+ `agents/home/<responsibility>/`; their `work` symlink points at
48
+ `agents/worktrees/<worktree-name>/`.
49
+ - Use `--agents-dir <name>` only when the repo already uses `agents/`
50
+ for something else. If the target directory exists, bootstrap must
51
+ fail before side effects.
35
52
 
36
53
  3) Team source — the authority/context the generated agents join.
37
54
 
38
- - Hosted new team, existing hosted team via `AWEB_API_KEY`, explicit `--invite-token`, current workspace forwarding, or BYOT.
39
- - Exactly one explicit source is allowed. If no explicit source is set and cwd is already an aw workspace, bootstrap forwards that current team. If no current workspace exists and the run is interactive, bootstrap creates a hosted team. Non-interactive runs need an explicit source.
40
-
41
- 4) Generated workspaces the identities that will act.
42
-
43
- - Each `agents/<responsibility>/` directory becomes an aw workspace with its own identity and team certificate.
44
- - The **first generated plan** is the anchor: bootstrap connects it first, installs roles/instructions from that workspace's team context, then invites/connects the rest.
45
- - Do not assume a responsibility named `implementation` is special. The anchor is the first plan the CLI generated.
55
+ - Hosted new team, existing hosted team via `AWEB_API_KEY`, explicit
56
+ `--invite-token`, current workspace forwarding, or BYOT.
57
+ - Exactly one explicit source is allowed. If no explicit source is set
58
+ and cwd is already an aw workspace, bootstrap forwards that current
59
+ team. If no current workspace exists and the run is interactive,
60
+ bootstrap creates a hosted team. Non-interactive runs need an
61
+ explicit source.
62
+
63
+ 4) Per-human naming — how shared layouts avoid collisions.
64
+
65
+ - Use `--identity-prefix <slug>` for shared repos. Examples: `juan`,
66
+ `maria`, `acme-dev`.
67
+ - Canonical multi-human templates use patterns such as
68
+ `{user}-{classic-name}` for local aliases and
69
+ `{user}-{responsibility}` for global address names.
70
+ - Never commit the final planned alias/address to `team.yaml`; it
71
+ belongs in ignored `.aw/` state under each agent home.
72
+
73
+ 5) Generated workspaces — the identities that will act.
74
+
75
+ - Each `agents/home/<responsibility>/` directory becomes an aw
76
+ workspace with its own identity and team certificate.
77
+ - The **first generated plan** is the anchor: bootstrap connects it
78
+ first, installs roles/instructions from that workspace's team
79
+ context, then invites/connects the rest.
80
+ - Do not assume a responsibility named `implementation` is special.
81
+ The anchor is the first plan the CLI generated.
46
82
 
47
83
  Aweb team source terms:
48
84
 
49
85
  - Hosted new team: aweb.ai creates/hosts the team.
50
- - API key: joins the hosted team represented by `AWEB_API_KEY`; `--aweb-url`/`AWEB_URL` is optional and defaults to hosted aweb.ai.
86
+ - API key: joins the hosted team represented by `AWEB_API_KEY`;
87
+ `--aweb-url`/`AWEB_URL` is optional and defaults to hosted aweb.ai.
51
88
  - Invite token: first generated workspace accepts an existing invite.
52
- - Current workspace forwarding: caller cwd already has `.aw`; bootstrap creates a one-use invite from that active team.
53
- - BYOT: bring your own team. This includes bringing your own domain/namespace and controller key. Do not describe a separate domain-only bootstrap mode.
89
+ - Current workspace forwarding: caller cwd already has `.aw`;
90
+ bootstrap creates a one-use invite from that active team.
91
+ - BYOT: bring your own team. This includes bringing your own
92
+ domain/namespace and controller key. Do not describe a separate
93
+ domain-only bootstrap mode.
54
94
 
55
- ## Bootstrap vs join (first decision)
95
+ ## Bootstrap vs provision vs add
56
96
 
57
- Bootstrap when:
97
+ Use `aw agents bootstrap` when:
58
98
 
99
+ - You are creating the committed `agents/` layout for a repo.
59
100
  - You are creating a brand-new team from a template.
60
- - You are extending an existing team with a template-defined set of agent workspaces, roles, and instructions.
61
- - You want reproducible setup for multiple agents/workspaces.
62
- - You want a “one command resolves the team source + installs roles + provisions agent dirs” flow.
101
+ - You are extending an existing team with a template-defined set of
102
+ agent homes, roles, and instructions.
103
+
104
+ Use `aw agents provision` when:
105
+
106
+ - The repo already has a committed `agents/` layout.
107
+ - Another human needs their own local `.aw/` state for the same
108
+ responsibilities.
109
+ - They have an invite, API key, BYOT authority, or current workspace
110
+ context for the same team.
111
+
112
+ Use `aw agents add` or `aw agents add-worktree` when:
113
+
114
+ - The layout already exists and you need one more responsibility.
115
+ - You want a repo-root agent (`add`) or isolated git worktree agent
116
+ (`add-worktree`).
63
117
 
64
118
  Do NOT bootstrap when:
65
119
 
66
- - The team already exists and you just need to add yourself: use `aweb-team-membership` and the `aw id team ...` commands.
67
- - You only need another workspace for yourself: use `aw workspace add-worktree` (git worktree) or create another directory and `aw init` it.
120
+ - The team already exists and you just need to add yourself: use
121
+ `aweb-team-membership` and the `aw id team ...` commands.
122
+ - You only need another workspace for yourself outside the repo-local
123
+ convention: use `aw workspace add-worktree` or create another
124
+ directory and `aw init` it.
68
125
 
69
- ## Pick a template (what team shape are we creating?)
126
+ ## Pick a template
70
127
 
71
128
  Canonical templates:
72
129
 
73
- - awebai/aweb-team-dev-review (2 agents)
74
- Use when you want the smallest meaningful team: implementation + review.
75
-
76
- - awebai/aweb-team-company-surfaces (6 agents)
77
- Use when you want a cross-functional team: direction/engineering/operations/support/outreach/analytics.
130
+ - awebai/aweb-team-coord-worktrees
131
+ Use when you want a coordinator plus isolated developer/reviewer git
132
+ worktrees in the current repo.
133
+ - awebai/aweb-team-company-surfaces
134
+ Use when you want a cross-functional team: direction/engineering/
135
+ operations/support/outreach/analytics.
78
136
 
79
137
  Fork/edit vs use-as-is:
80
138
 
81
139
  - Use as-is to learn the flow or to run a standard team.
82
- - Clone or fork when you want to customize roles, responsibilities, or instructions before provisioning.
83
- - It is safe to edit the template checkout before applying it; `aw team bootstrap` reads `team.yaml`, `roles/`, `docs/`, and `agents/` from the local template directory at run time.
140
+ - Clone or fork when you want to customize roles, responsibilities, or
141
+ instructions before provisioning.
142
+ - It is safe to edit the template checkout before applying it;
143
+ `aw agents bootstrap` reads `team.yaml`, `roles/`, `docs/`, and
144
+ `home/` from the local template directory at run time.
84
145
 
85
146
  ## Customizing a template before applying it
86
147
 
87
- When the human wants different agents, role playbooks, names, or instructions, do not try to patch the generated workspaces after bootstrap. Clone/edit the template first, then bootstrap the edited local directory.
148
+ When the human wants different agents, role playbooks, names, or
149
+ instructions, do not patch generated workspaces after bootstrap.
150
+ Clone/edit the template first, then bootstrap the edited local
151
+ directory.
88
152
 
89
153
  Typical safe flow:
90
154
 
91
155
  ```bash
92
- git clone https://github.com/awebai/aweb-team-dev-review.git my-team-template
156
+ git clone https://github.com/awebai/aweb-team-coord-worktrees.git my-team-template
93
157
  cd my-team-template
94
- # edit team.yaml, roles/*.md, docs/team.md, agents/<responsibility>/AGENTS.md
95
- aw team bootstrap . --dry-run --work-directory /path/to/work
96
- aw team bootstrap . --work-directory /path/to/work
158
+ # edit team.yaml, roles/*.md, docs/team.md, home/<responsibility>/AGENTS.md
159
+ cd /path/to/project-repo
160
+ aw agents bootstrap /path/to/my-team-template --dry-run --identity-prefix juan
161
+ aw agents bootstrap /path/to/my-team-template --username alice --identity-prefix juan
97
162
  ```
98
163
 
99
164
  What to edit:
100
165
 
101
- - `team.yaml` roles: add/remove role names and point each to a role file.
102
- - `team.yaml` agents: add/remove responsibility workspaces and set each `role_name`, `default_name`, and `default_alias`.
103
- - `team.yaml` worktrees: add/remove local git-worktree agents for code work.
104
- - `roles/*.md`: change operational playbooks installed with `aw roles`.
105
- - `docs/team.md`: change shared team instructions installed after the anchor connects.
106
- - `agents/<responsibility>/AGENTS.md`: change per-workspace startup context.
166
+ - `team.yaml` roles: add/remove role names and point each to a role
167
+ file.
168
+ - `team.yaml` agents: add/remove responsibility workspaces and set
169
+ each `role_name`, optional `identity_scope`, optional
170
+ `home_template`, and optional `work`.
171
+ - `team.yaml` naming: for shared repos, prefer
172
+ `naming.local_alias.pattern: "{user}-{classic-name}"`.
173
+ - Use `work: repo_root` for an agent whose `work` symlink points to
174
+ the project repo root.
175
+ - Use `work: git_worktree` for an agent whose `work` symlink points
176
+ to a generated git worktree under `agents/worktrees/`.
177
+ - `roles/*.md`: change operational playbooks installed with
178
+ `aw roles`.
179
+ - `docs/team.md`: change shared team instructions installed after the
180
+ anchor connects.
181
+ - `home/<responsibility>/AGENTS.md`: change per-workspace startup
182
+ context.
183
+
184
+ Do not use `default_name` or `default_alias` in current templates.
185
+ Those are legacy hints only and must not become committed identity
186
+ state.
187
+
188
+ ## Before running bootstrap
189
+
190
+ 1) For the default layout, run bootstrap from the root of the project
191
+ git repo.
192
+
193
+ - Bootstrap creates `agents/` there.
194
+ - If `agents/` exists, stop. Do not ask bootstrap to adopt, merge, or
195
+ overwrite it.
196
+ - If the project already has a different `agents/` directory, ask the
197
+ human for a different `--agents-dir <name>`.
198
+
199
+ 2) Decide the team source. This affects whether bootstrap creates a
200
+ new hosted team, joins an API-key/invite team, forwards the current
201
+ team, or uses BYOT.
202
+
203
+ 3) Decide the identity prefix. Shared repos should always pass
204
+ `--identity-prefix <human-slug>` explicitly.
205
+
206
+ ## Default layout: project-local agents/
207
+
208
+ New bootstrap runs should normally use the default layout:
107
209
 
108
- Default agent names are accepted automatically. Only use `--ask-for-agent-names` when a human specifically wants an interactive rename prompt during bootstrap.
109
-
110
- ## Before running bootstrap (safety checks)
111
-
112
- 1) Run bootstrap from a directory that is NOT already inside a git repo/worktree.
113
-
114
- - If you are inside a git repo/worktree and you are using a remote template ref, bootstrap will refuse to clone by default.
115
- - Use `--template-cache-dir` as the explicit escape hatch when you must run from inside a repo.
210
+ ```bash
211
+ cd /path/to/project-repo
212
+ aw agents bootstrap https://github.com/awebai/aweb-team-coord-worktrees.git \
213
+ --username alice \
214
+ --identity-prefix juan
215
+ ```
116
216
 
117
- 2) Decide the “work” directory model (see next section). This affects whether agents share one checkout or get isolated worktrees.
217
+ Expected generated shape:
218
+
219
+ ```text
220
+ agents/
221
+ team.yaml
222
+ docs/
223
+ roles/
224
+ home/
225
+ coordinator/
226
+ .aw/
227
+ AGENTS.md
228
+ work -> ../../..
229
+ developer/
230
+ .aw/
231
+ AGENTS.md
232
+ work -> ../../worktrees/developer
233
+ reviewer/
234
+ .aw/
235
+ AGENTS.md
236
+ work -> ../../worktrees/reviewer
237
+ worktrees/
238
+ developer/
239
+ reviewer/
240
+ ```
118
241
 
119
- ## Exactly one of: work-directory OR work-repo-url (XOR)
242
+ The repo root itself is not an aw workspace. Start Codex, Claude Code,
243
+ or Pi from an agent home:
120
244
 
121
- Bootstrap needs a directory to symlink into each agent workspace as ./work.
245
+ ```bash
246
+ cd agents/home/coordinator
247
+ codex
248
+ ```
122
249
 
123
- You must provide exactly one of:
250
+ Bootstrap writes scoped `.gitignore` entries for
251
+ `agents/home/*/.aw/`, `agents/home/*/work`, and `agents/worktrees/`.
252
+ It must not ignore the whole `agents/` directory.
124
253
 
125
- A) --work-directory PATH
254
+ If an older generated repo tracked `agents/home/*/work`, remove those
255
+ symlinks from git after upgrading:
126
256
 
127
- - Use when you already have a local directory you want agents to use as work.
128
- - For code teams with worktree agents (team.yaml worktrees:), PATH must be a git repo.
257
+ ```bash
258
+ git rm --cached agents/home/*/work
259
+ git add .gitignore agents
260
+ git commit -m "agents: ignore generated work symlinks"
261
+ ```
129
262
 
130
- B) --work-repo-url VALUE
263
+ ## Multi-human shared repo flow
131
264
 
132
- - Use when you want bootstrap to clone a repo for you.
133
- - VALUE can be a URL or a local path; bootstrap runs “git clone VALUE” into:
265
+ First human:
134
266
 
135
- <template-checkout>/worktrees/<derived-name>/
267
+ ```bash
268
+ cd /path/to/project-repo
269
+ aw agents bootstrap https://github.com/awebai/aweb-team-coord-worktrees.git \
270
+ --username alice \
271
+ --identity-prefix juan
272
+ git add agents .gitignore
273
+ git commit -m "agents: add team layout"
274
+ ```
136
275
 
137
- where <derived-name> matches git’s default directory naming (basename, .git stripped).
276
+ Second human:
138
277
 
139
- - That clone destination is then used as the effective work directory (symlinked as ./work in each agent workspace).
278
+ ```bash
279
+ git pull
280
+ aw agents provision --invite-token <token> --identity-prefix maria
281
+ cd agents/home/coordinator
282
+ codex
283
+ ```
140
284
 
141
- If both flags are set, treat it as a user error and stop.
285
+ The second human does not run bootstrap over the existing `agents/`
286
+ directory. Provision reads the committed layout and writes only ignored
287
+ local state.
142
288
 
143
289
  ## Team source policy
144
290
 
145
- Non-dry-run bootstrap needs one coherent team source. This is the most important decision: it determines which team owns the roles, instructions, tasks, mail, chat, and membership certificates created during bootstrap.
291
+ Non-dry-run bootstrap needs one coherent team source.
146
292
 
147
293
  Resolution order:
148
294
 
149
- - If any explicit source is set (`AWEB_API_KEY`, `--invite-token`, `--username`, or `--namespace/--team`), do not set another explicit source.
150
- - If no explicit source is set and cwd is an initialized aw workspace, bootstrap forwards the current active team.
151
- - If no explicit source is set, cwd is not an aw workspace, and the run is interactive, bootstrap creates/uses a hosted team through onboarding prompts.
152
- - If no source can be resolved, stop and ask the human which team source to use.
153
-
154
- The first generated agent workspace is the anchor: bootstrap connects it first, installs roles/instructions from that workspace's team context, then invites/connects the remaining agents and any declared worktree agents.
295
+ - If any explicit source is set (`AWEB_API_KEY`, `--invite-token`,
296
+ `--username`, or `--namespace/--team`), do not set another explicit
297
+ source.
298
+ - If no explicit source is set and cwd is an initialized aw workspace,
299
+ bootstrap forwards the current active team.
300
+ - If no explicit source is set, cwd is not an aw workspace, and the
301
+ run is interactive, bootstrap creates/uses a hosted team through
302
+ onboarding prompts.
303
+ - If no source can be resolved, stop and ask the human which team
304
+ source to use.
155
305
 
156
306
  Supported sources:
157
307
 
158
- 1) Hosted new team (aweb.ai)
308
+ 1) Hosted new team
159
309
 
160
310
  - Best for first-time teams.
161
311
  - Use `--username <name>` or run interactively in a TTY.
162
- - Bootstrap uses the same hosted onboarding path as `aw init` for the first generated workspace.
312
+ - Bootstrap uses the same hosted onboarding path as `aw init` for the
313
+ first generated workspace.
163
314
 
164
315
  2) Existing hosted team via API key
165
316
 
166
317
  - If `AWEB_API_KEY` is set, bootstrap joins the API key's hosted team.
167
- - `--aweb-url`/`AWEB_URL` is optional; when omitted, the hosted aweb.ai default is used. Set it only to target a non-default stack.
318
+ - `--aweb-url`/`AWEB_URL` is optional; when omitted, the hosted
319
+ aweb.ai default is used.
168
320
  - Do not also pass `--username`, `--invite-token`, or BYOT flags.
169
321
 
170
322
  3) Existing team via invite token
171
323
 
172
324
  - Pass `--invite-token <token>`.
173
- - Bootstrap accepts it into the first generated workspace, then creates further invites from that established team context.
325
+ - Bootstrap accepts it into the first generated workspace, then
326
+ creates further invites from that established team context.
174
327
 
175
328
  4) Current workspace forwarding
176
329
 
177
- - If the caller's cwd is already initialized for aw and no explicit source is set, bootstrap creates a one-use invite from the current active team and accepts it into the first generated workspace.
178
- - This is the safe default for adding a template team shape to the team you are already using.
330
+ - If caller cwd is already initialized for aw and no explicit source
331
+ is set, bootstrap creates a one-use invite from the current active
332
+ team and accepts it into the first generated workspace.
179
333
 
180
- 5) BYOT (bring your own team)
334
+ 5) BYOT
181
335
 
182
- - Use `--namespace <domain> --team <slug>` when the team's namespace/domain and controller key live in your environment.
183
- - BYOT includes bringing your own domain; there is no separate supported domain-only bootstrap mode.
184
- - Bootstrap creates/ensures the team in that namespace, invites the first generated workspace, then uses it as the anchor.
336
+ - Use `--namespace <domain> --team <slug>` when the team's namespace/
337
+ domain and controller key live in your environment.
338
+ - Bootstrap creates/ensures the team in that namespace, invites the
339
+ first generated workspace, then uses it as the anchor.
185
340
 
186
341
  Decision recipe:
187
342
 
188
- - Human says make me a new team and has no existing aw context: use hosted (`--username` or interactive prompt).
189
- - Human has a dashboard/API key: use `AWEB_API_KEY=... aw team bootstrap ...`; do not ask for `AWEB_URL` unless they are using a non-default stack.
343
+ - Human says "make me a new team" and has no existing aw context: use
344
+ hosted (`--username` or interactive prompt) plus
345
+ `--identity-prefix`.
346
+ - Human has a dashboard/API key: use
347
+ `AWEB_API_KEY=... aw agents bootstrap ... --identity-prefix <slug>`.
190
348
  - Human pasted an invite: use `--invite-token`.
191
- - Human is already inside the team workspace that should own the new agents: use current workspace forwarding (no explicit source).
192
- - Human controls a namespace/domain and wants the team under that namespace: use BYOT (`--namespace` + `--team`).
193
-
194
- Policy guidance:
349
+ - Human is already inside the team workspace that should own the new
350
+ agents: use current workspace forwarding.
351
+ - Human controls a namespace/domain and wants the team under that
352
+ namespace: use BYOT (`--namespace` + `--team`).
195
353
 
196
- - Prefer hosted for “get a working team now”.
197
- - Prefer API key or invite when the team already exists but the caller is not already inside it.
198
- - Prefer current workspace forwarding when you are already inside the target team.
199
- - Prefer BYOT when you need local control over the team namespace/domain and routing.
200
- - Use `--dry-run` for planning only. It prints the resolved plan (template ref, work directory, team source, generated workspaces) without writing identities, files, or server state. Do not pair it with side-effecting flags expecting partial provisioning.
201
-
202
- ## Worktree agents (team.yaml worktrees:)
354
+ ## Adding agents later
203
355
 
204
- Worktree agents are an OPTIONAL second layer for codebases where multiple agents will edit in parallel.
356
+ Add a repo-root local responsibility:
205
357
 
206
- - Responsibility workspaces live under agents/<responsibility>/.
207
- - Worktree agents live under worktrees/ and each has its own git worktree checkout and its own .aw/ identity state.
358
+ ```bash
359
+ aw agents add support --role support
360
+ ```
208
361
 
209
- Turn worktree agents on when:
362
+ Add a worktree-bound local responsibility:
210
363
 
211
- - The work directory is a git repo.
212
- - Multiple agents will change files in parallel.
213
- - You want each agent’s edits isolated until you merge.
364
+ ```bash
365
+ aw agents add-worktree developer --role developer
366
+ ```
214
367
 
215
- Leave it off when:
368
+ Add a global BYOT responsibility:
216
369
 
217
- - Work is non-code.
218
- - Only one agent edits at a time.
370
+ ```bash
371
+ aw agents add support \
372
+ --global \
373
+ --namespace example.com \
374
+ --team circle \
375
+ --identity-prefix juan
376
+ ```
219
377
 
220
- Operational note:
378
+ Remove explicitly separates layout and identity effects:
221
379
 
222
- - Worktree agents are local-only identities by design; they are for parallel local work, not for global addressability.
380
+ ```bash
381
+ aw agents remove support --remove-layout
382
+ aw agents remove support --deprovision-local
383
+ aw agents remove support --delete-global-address
384
+ ```
223
385
 
224
- ## After bootstrap: validate that the team is actually usable
386
+ `--remove-layout` does not revoke other humans' certs and does not
387
+ delete their ignored `.aw/` state.
225
388
 
226
- For each agent directory under agents/<responsibility>/:
389
+ `--deprovision-local` uses the local team controller key for self-custodial
390
+ teams. For hosted-managed cert-only agents, it can use the agent's own signing
391
+ key and active team certificate to ask the hosted service to deprovision that
392
+ same agent. It must not be described as dashboard authority over BYOT members.
227
393
 
228
- - Run `aw workspace status` to confirm:
229
- - the workspace is initialized
230
- - the active team is correct
231
- - the identity is present
394
+ `--delete-global-address` is opt-in. Self-custodial namespaces require the
395
+ local namespace controller key. Hosted-managed global agents can delete only
396
+ hosted-managed addresses through hosted self-deprovision; BYOT/unmanaged
397
+ addresses remain customer-controller-owned.
232
398
 
233
- - Run `aw whoami` to confirm the identity fields are present.
399
+ Map hosted self-deprovision structured errors to concrete recovery:
234
400
 
235
- - If you use a wake-up path (Pi extension / Claude Code channel plugin), start it inside the agent directory after initialization.
401
+ - `hosted_team_controller_required`: use/restore the self-custodial team
402
+ controller key; this is not a hosted-managed team.
403
+ - `global_address_not_hosted_managed`: delete the address with the customer
404
+ namespace controller; the hosted service must not delete BYOT/unmanaged
405
+ addresses.
406
+ - `delete_global_address_required`: rerun with `--delete-global-address` for a
407
+ hosted-managed global agent.
408
+ - `local_identity_has_no_global_address`: rerun without
409
+ `--delete-global-address`; local identities do not have global addresses.
236
410
 
237
- ## Re-run safety and idempotence (how to avoid making a mess)
411
+ ## Legacy mode
238
412
 
239
- When iterating on templates or recovering from partial setup:
413
+ Legacy out-of-repo mode is still supported for existing scripts that
414
+ pass `--work-directory` or `--work-repo-url`. Do not choose it for a
415
+ new customer unless they explicitly need the old shape.
240
416
 
241
- - Use `--dry-run` first to validate the plan.
242
- - Use `--refresh-template` only when you intend to re-clone over a previous template checkout.
243
- - Treat identity/certificate state under .aw/ as the source of truth; do not delete it casually.
244
- - If you need to create a fresh workspace, do it in a new directory rather than mutating an existing identity in place.
417
+ ## After bootstrap: validate that the team is usable
245
418
 
246
- If bootstrap fails mid-way:
419
+ For each agent directory under `agents/home/<responsibility>/`:
247
420
 
248
- - Capture the first failing command and error.
249
- - Do not keep retrying blindly; first confirm whether some workspaces were already created and connected.
250
- - Prefer completing the remaining agent dirs rather than redoing everything.
421
+ - Run `aw workspace status` to confirm the workspace is initialized,
422
+ the active team is correct, and the identity is present.
423
+ - Run `aw whoami` to confirm identity fields are present.
424
+ - If you use a wake-up path (Pi extension / Claude Code channel
425
+ plugin), start it inside the agent directory after initialization.
251
426
 
252
- ## Adding agents later
427
+ ## Troubleshooting policy
253
428
 
254
- Two common expansions after initial bootstrap:
429
+ If bootstrap fails:
255
430
 
256
- - Add another responsibility workspace: create a new directory and run `aw init` (or extend your template and bootstrap a new repo).
257
- - Add another isolated code workspace on the same repo: use `aw workspace add-worktree`.
431
+ - Stop and capture the first error.
432
+ - Do not retry over an existing `agents/` directory.
433
+ - Prefer explicit recovery with `aw agents provision`, `aw agents add`,
434
+ or `aw agents remove` over deleting `.aw/` state.
435
+ - If you must remove generated state, inspect/back up `.aw/` first.
258
436
 
259
- When in doubt, choose the smallest change that preserves existing identities and avoids rewriting certificates.
437
+ If a multi-human provision hits an alias/address conflict, rerun with a
438
+ different `--identity-prefix` or naming pattern. Invite-only flows may
439
+ discover collisions only when accepting/registering; this is expected
440
+ fail-closed behavior.
260
441
 
261
442
  ## References
262
443
 
263
444
  Read these only when deeper context is needed:
264
445
 
265
- - references/bootstrap-scenarios.md: scenarios, checklists, and troubleshooting.
266
- - https://aweb.ai/docs/team-bootstrap/ : full reference guide.
446
+ - references/bootstrap-scenarios.md: scenarios, checklists, and
447
+ troubleshooting.
267
448
  - docs/team-bootstrap.md (aweb repo checkout): full reference guide.
@@ -1,87 +1,149 @@
1
- # aweb Bootstrap scenarios and checklists
1
+ # aweb agents bootstrap scenarios and checklists
2
2
 
3
- This reference is support material for the aweb-bootstrap skill. Use it when you need concrete examples, troubleshooting checklists, or a quick “what should I run next?” guide.
3
+ This reference is support material for the aweb-bootstrap skill. Use it
4
+ when you need concrete examples, troubleshooting checklists, or a quick
5
+ "what should I run next?" guide.
4
6
 
5
- It is intentionally narrower than docs/team-bootstrap.md: it focuses on common decision points and failure modes.
7
+ It is intentionally narrower than docs/team-bootstrap.md: it focuses on
8
+ common decision points and failure modes.
6
9
 
7
10
  ## Quick mental model
8
11
 
9
- - Template repo = blueprint for roles, instructions, and responsibility directories.
10
- - Work directory/repo = the project/content agents see as `./work`.
12
+ - Template repo = blueprint for roles, instructions, and agent home
13
+ templates.
14
+ - Default generated layout = project-local `agents/` directory
15
+ containing `home/`, `worktrees/`, `roles/`, `docs/`, and `team.yaml`.
16
+ - Work target = what each agent's `work` symlink points at: the repo
17
+ root (`work: repo_root`) or a generated git worktree
18
+ (`work: git_worktree`).
11
19
  - Team source = the authority the generated agents join.
12
- - First generated workspace = bootstrap anchor. It connects first; roles/instructions install through it; all other generated agents join through invites from that established team context.
13
- - BYOT means bring your own team, including your own namespace/domain and controller key. Do not present a separate domain-only bootstrap mode.
20
+ - Identity prefix = the per-human slug used to avoid alias/address
21
+ collisions in shared repos.
22
+ - First generated workspace = bootstrap anchor. It connects first;
23
+ roles/instructions install through it; all other generated agents
24
+ join through invites from that established team context.
25
+ - BYOT means bring your own team, including your own namespace/domain
26
+ and controller key. Do not present a separate domain-only bootstrap
27
+ mode.
14
28
 
15
29
  Team-source precedence:
16
30
 
17
- - Explicit sources conflict: use only one of `AWEB_API_KEY`, `--invite-token`, `--username`, or `--namespace/--team`.
18
- - With no explicit source, an initialized caller cwd forwards its current active team.
19
- - With no explicit source and no caller workspace, an interactive run uses hosted onboarding.
20
- - Non-interactive runs need an explicit source or initialized caller workspace.
31
+ - Explicit sources conflict: use only one of `AWEB_API_KEY`,
32
+ `--invite-token`, `--username`, or `--namespace/--team`.
33
+ - With no explicit source, an initialized caller cwd forwards its
34
+ current active team.
35
+ - With no explicit source and no caller workspace, an interactive run
36
+ uses hosted onboarding.
37
+ - Non-interactive runs need an explicit source or initialized caller
38
+ workspace.
21
39
 
22
- ## Scenario: first-time hosted team from a template (recommended)
40
+ ## Scenario: first-time hosted team from a template
23
41
 
24
- Goal: create a new aweb.ai team and provision agent workspaces from a template.
42
+ Goal: create a new aweb.ai team and provision agent workspaces from a
43
+ template.
25
44
 
26
45
  Checklist:
27
46
 
28
- - Run from a directory that is not inside an existing git repo/worktree.
29
- - Pick a template:
30
- - awebai/aweb-team-dev-review for a minimal 2-agent setup.
31
- - awebai/aweb-team-company-surfaces for a 6-agent cross-functional setup.
47
+ - Run from the root of the project git repo.
48
+ - Confirm the target agents directory does not already exist. Default:
49
+ `agents/`.
50
+ - Pick a template.
51
+ - Pick a human-specific `--identity-prefix`.
32
52
 
33
- Example (using an existing local work directory):
53
+ Example:
34
54
 
35
- aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --username alice --work-directory /path/to/work
55
+ cd /path/to/project-repo
56
+ aw agents bootstrap https://github.com/awebai/aweb-team-coord-worktrees.git \
57
+ --username alice \
58
+ --identity-prefix juan
36
59
 
37
- Example (clone the work repo into the template checkout):
60
+ Example with a non-default agents directory:
38
61
 
39
- aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git --username alice --work-repo-url https://github.com/ORG/REPO.git
62
+ cd /path/to/project-repo
63
+ aw agents bootstrap https://github.com/awebai/aweb-team-coord-worktrees.git \
64
+ --username alice \
65
+ --identity-prefix juan \
66
+ --agents-dir aweb-agents
40
67
 
41
68
  Notes:
42
69
 
43
- - work-directory and work-repo-url are XOR: set exactly one.
44
- - When work-repo-url is used, bootstrap clones into:
70
+ - Bootstrap creates `agents/home/<responsibility>/` for every live
71
+ agent home.
72
+ - Worktree-bound agents get checkouts under
73
+ `agents/worktrees/<worktree-name>/`.
74
+ - The repo root is not an aw workspace; humans should start
75
+ Codex/Claude/Pi from `agents/home/<responsibility>/`.
76
+
77
+ ## Scenario: second human provisions the same repo
78
+
79
+ Goal: another human clones the repo and creates their own ignored
80
+ identity state for the same committed layout.
81
+
82
+ Checklist:
83
+
84
+ - Do not run bootstrap over the existing `agents/` directory.
85
+ - Get an invite token, API key, BYOT authority, or current workspace
86
+ context for the same team.
87
+ - Use a different `--identity-prefix`.
88
+
89
+ Example:
90
+
91
+ git pull
92
+ aw agents provision --invite-token <token> --identity-prefix maria
93
+ cd agents/home/coordinator
94
+ codex
45
95
 
46
- <template-checkout>/worktrees/<derived-name>/
96
+ Expected behavior:
47
97
 
48
- where derived-name is the git-style repo directory name (basename with .git stripped).
98
+ - Committed `agents/team.yaml`, `roles/`, `docs/`, and
99
+ `home/*/AGENTS.md` remain unchanged.
100
+ - Local `.aw/` state and `work` symlinks are regenerated under
101
+ `agents/home/*/`.
102
+ - Worktree directories are under `agents/worktrees/`.
49
103
 
50
104
  ## Scenario: customize the template before applying it
51
105
 
52
- Goal: change roles, agent responsibilities, names, aliases, or instructions before any team state is created.
106
+ Goal: change roles, agent responsibilities, naming policy, or
107
+ instructions before any team state is created.
53
108
 
54
109
  Checklist:
55
110
 
56
111
  - Clone or fork the template first.
57
- - Edit `team.yaml`, `roles/*.md`, `docs/team.md`, and `agents/<responsibility>/AGENTS.md` as needed.
58
- - Run `aw team bootstrap . --dry-run ...` from the template checkout to validate.
59
- - Bootstrap the local directory only after the plan looks right.
112
+ - Edit `team.yaml`, `roles/*.md`, `docs/team.md`, and
113
+ `home/<responsibility>/AGENTS.md` as needed.
114
+ - Run `aw agents bootstrap /path/to/template --dry-run` from the
115
+ project repo root to validate.
116
+ - Bootstrap the local template directory only after the plan looks
117
+ right.
60
118
 
61
119
  Example:
62
120
 
63
- git clone https://github.com/awebai/aweb-team-dev-review.git my-team-template
121
+ git clone https://github.com/awebai/aweb-team-coord-worktrees.git my-team-template
64
122
  cd my-team-template
65
- # edit team.yaml / roles / docs / agents
66
- aw team bootstrap . --dry-run --work-directory /path/to/work
67
- aw team bootstrap . --username alice --work-directory /path/to/work
123
+ # edit team.yaml / roles / docs / home
124
+ cd /path/to/project-repo
125
+ aw agents bootstrap /path/to/my-team-template --dry-run --identity-prefix juan
126
+ aw agents bootstrap /path/to/my-team-template --username alice --identity-prefix juan
68
127
 
69
- ## Scenario: BYOT (bring your own team)
128
+ ## Scenario: BYOT
70
129
 
71
130
  Goal: bootstrap a team under a namespace/domain you control.
72
131
 
73
132
  Checklist:
74
133
 
75
- - Confirm you have a controller identity key for the namespace/domain.
76
- - Remember BYOT includes bringing your own domain; there is no separate supported domain-only bootstrap mode.
77
- - Bootstrap will connect the first generated workspace, install roles/instructions there, then invite/connect the remaining agents.
134
+ - Confirm the namespace is registered and the controller key is
135
+ available locally.
136
+ - Remember BYOT includes bringing your own domain; there is no separate
137
+ supported domain-only bootstrap mode.
138
+ - Bootstrap will connect the first generated workspace, install
139
+ roles/instructions there, then invite/connect the remaining agents.
78
140
 
79
- Example shape (values are placeholders):
141
+ Example shape:
80
142
 
81
- aw team bootstrap https://github.com/awebai/aweb-team-dev-review.git \
143
+ aw agents bootstrap https://github.com/awebai/aweb-team-coord-worktrees.git \
82
144
  --namespace example.com \
83
145
  --team dev \
84
- --work-directory /path/to/work
146
+ --identity-prefix juan
85
147
 
86
148
  If you are also self-hosting the coordination stack, add:
87
149
 
@@ -90,86 +152,179 @@ If you are also self-hosting the coordination stack, add:
90
152
 
91
153
  ## Scenario: existing hosted team via API key
92
154
 
93
- Goal: provision a template into the hosted team associated with an API key.
155
+ Goal: provision a template into the hosted team associated with an API
156
+ key.
94
157
 
95
158
  Checklist:
96
159
 
97
- - Set AWEB_API_KEY.
98
- - Optionally set AWEB_URL or pass --aweb-url to target a non-default stack; otherwise the hosted default is used.
99
- - Do not also pass --username, --invite-token, or BYOT flags.
160
+ - Set `AWEB_API_KEY`.
161
+ - Optionally set `AWEB_URL` or pass `--aweb-url` to target a
162
+ non-default stack; otherwise the hosted default is used.
163
+ - Do not also pass `--username`, `--invite-token`, or BYOT flags.
100
164
 
101
165
  Example:
102
166
 
103
167
  AWEB_API_KEY=aw_sk_... \
104
- aw team bootstrap /path/to/template --work-directory /path/to/work
168
+ aw agents bootstrap /path/to/template --identity-prefix juan
105
169
 
106
170
  ## Scenario: existing team via invite token
107
171
 
108
- Goal: accept an invite into the first generated workspace and use it as the anchor for the rest of bootstrap.
172
+ Goal: accept an invite into the first generated workspace and use it as
173
+ the anchor for the rest of bootstrap.
109
174
 
110
175
  Example:
111
176
 
112
- aw team bootstrap /path/to/template \
177
+ aw agents bootstrap /path/to/template \
113
178
  --invite-token <token> \
114
- --work-directory /path/to/work
179
+ --identity-prefix maria
115
180
 
116
181
  ## Scenario: current workspace forwarding
117
182
 
118
- Goal: run bootstrap from an existing aw workspace and forward that active team into the generated template workspaces.
183
+ Goal: run bootstrap from an existing aw workspace and forward that
184
+ active team into the generated template workspaces.
119
185
 
120
186
  Checklist:
121
187
 
122
188
  - Confirm `aw workspace status` succeeds in the caller cwd.
123
189
  - Do not pass another explicit team source.
124
- - Bootstrap will create a one-use invite from the current active team for the first generated workspace.
190
+ - Bootstrap will create a one-use invite from the current active team
191
+ for the first generated workspace.
125
192
 
126
193
  ## Scenario: dry-run planning
127
194
 
128
- Goal: validate the plan and see generated workspace commands without changing files, identities, or server state.
195
+ Goal: validate the plan and see generated workspace commands without
196
+ changing files, identities, or server state.
129
197
 
130
198
  Example:
131
199
 
132
- aw team bootstrap /path/to/template --dry-run --work-directory /path/to/work
200
+ aw agents bootstrap /path/to/template --dry-run --identity-prefix juan
201
+
202
+ ## Scenario: add a new responsibility later
203
+
204
+ Repo-root local agent:
205
+
206
+ aw agents add support --role support
207
+
208
+ Worktree-bound local agent:
209
+
210
+ aw agents add-worktree developer --role developer
211
+
212
+ Global BYOT agent:
213
+
214
+ aw agents add support \
215
+ --global \
216
+ --namespace example.com \
217
+ --team circle \
218
+ --identity-prefix juan
219
+
220
+ ## Scenario: remove a responsibility
221
+
222
+ Remove the shared blueprint entry:
223
+
224
+ aw agents remove support --remove-layout
225
+
226
+ Remove this human's local ignored state:
227
+
228
+ aw agents remove support --deprovision-local
229
+
230
+ Delete a global address when you have the required namespace authority:
231
+
232
+ aw agents remove support --delete-global-address
233
+
234
+ `--remove-layout` is not a team-wide revocation. Other humans' local
235
+ `.aw/` state and certificates continue until they deprovision or the
236
+ certs expire/revoke separately.
237
+
238
+ `--deprovision-local` uses local team-controller authority for self-custodial
239
+ teams. Hosted-managed cert-only agents may self-deprovision through the hosted
240
+ service using their own signing key and active team certificate. That hosted
241
+ path applies only to the same agent and must not be described as dashboard
242
+ authority over BYOT members.
133
243
 
134
- ## Worktree agents: when to enable and what to expect
244
+ `--delete-global-address` is opt-in. Self-custodial namespaces require the
245
+ local namespace controller key. Hosted-managed global agents can delete only
246
+ hosted-managed addresses through hosted self-deprovision; unmanaged/BYOT
247
+ addresses remain customer-controller-owned.
135
248
 
136
- Use worktree agents when multiple agents will edit code in parallel.
249
+ Hosted self-deprovision errors are actionable:
250
+
251
+ - `hosted_team_controller_required`: use/restore the self-custodial team
252
+ controller key; this is not a hosted-managed team.
253
+ - `global_address_not_hosted_managed`: delete the address with the customer
254
+ namespace controller; the hosted service must not delete BYOT/unmanaged
255
+ addresses.
256
+ - `delete_global_address_required`: rerun with `--delete-global-address` for a
257
+ hosted-managed global agent.
258
+ - `local_identity_has_no_global_address`: rerun without
259
+ `--delete-global-address`; local identities do not have global addresses.
260
+
261
+ ## Legacy mode: old out-of-repo bootstrap
262
+
263
+ Use legacy mode only for existing scripts/templates that still expect
264
+ the old layout.
265
+
266
+ - `--work-directory <path>` selects legacy work-directory mode.
267
+ - `--work-repo-url <url-or-local-path>` selects legacy
268
+ clone-then-bootstrap mode.
269
+ - The two flags are XOR.
270
+ - Do not combine `--agents-dir` with either legacy work flag.
271
+
272
+ ## Worktree-bound agents
273
+
274
+ Use `work: git_worktree` when multiple agents will edit code in
275
+ parallel.
137
276
 
138
277
  Requirements:
139
278
 
140
- - The work directory must be a git repo.
141
- - The template must declare a worktrees: block in team.yaml.
279
+ - The project directory must be a git repo.
280
+ - The template declares `work: git_worktree` for the relevant agent in
281
+ `team.yaml`.
142
282
 
143
- What bootstrap does:
283
+ What bootstrap/add-worktree does:
144
284
 
145
- - It creates template worktrees/ (if missing) and git-excludes it locally.
146
- - It creates one git worktree per entry.
147
- - Each worktree agent gets its own .aw/ state and local-scope identity.
285
+ - It creates `agents/worktrees/` and writes scoped `.gitignore`
286
+ entries.
287
+ - It creates one git worktree per `work: git_worktree` agent.
288
+ - The live agent home remains under `agents/home/<responsibility>/`.
289
+ - Each worktree-bound agent gets its own `.aw/` state and local-scope
290
+ identity.
148
291
 
149
292
  Common pitfall:
150
293
 
151
- - Alias collisions: worktree agent aliases must not collide with existing team aliases.
294
+ - Alias collisions: in shared repos use `--identity-prefix` and a
295
+ template local alias pattern such as `{user}-{classic-name}`.
152
296
 
153
- ## Quick validation after bootstrap
297
+ ## Quick validation after bootstrap/provision
154
298
 
155
- In each generated agent directory (agents/<responsibility>/):
299
+ In each generated agent directory (`agents/home/<responsibility>/`):
156
300
 
157
301
  - aw workspace status
158
302
  - aw whoami
159
303
 
160
304
  If you are using a wake-up integration:
161
305
 
162
- - start the Pi extension or the Claude Code channel plugin in that directory after initialization
306
+ - start the Pi extension or the Claude Code channel plugin in that
307
+ directory after initialization
163
308
 
164
309
  ## Troubleshooting patterns
165
310
 
166
311
  If bootstrap fails:
167
312
 
168
313
  - Stop and capture the first error.
169
- - Identify which directories were already created.
170
- - Prefer completing the remaining steps rather than deleting existing .aw state.
314
+ - Do not retry over an existing `agents/` directory.
315
+ - Inspect/back up `.aw/` state before deleting generated directories.
316
+ - Prefer `aw agents provision`, `aw agents add`, or
317
+ `aw agents remove` recovery commands over hand-editing identity
318
+ state.
319
+
320
+ If a multi-human provision hits a conflict:
321
+
322
+ - Rerun with a different `--identity-prefix` or naming pattern.
323
+ - Invite-only flows may discover existing aliases only at mutation
324
+ time; this is expected fail-closed behavior.
171
325
 
172
- If you see identity_mismatch or unverified messages in live channel metadata:
326
+ If you see identity_mismatch or unverified messages in live channel
327
+ metadata:
173
328
 
174
329
  - Compare with aw chat history output.
175
330
  - Confirm the channel plugin / Pi package version is current.
@@ -67,7 +67,7 @@ The normative E2E contract is `docs/e2e-messaging-contract.md`. Do not invent pr
67
67
 
68
68
  For local E2E messaging, the self-custodial client needs both identity signing material and local encryption private keys. Back up the active encryption private key and archived encryption private keys with the same seriousness as `.aw/signing.key`: losing archived encryption keys makes historical encrypted messages unrecoverable. AC/aweb cannot recover or decrypt old encrypted messages for support.
69
69
 
70
- An identity must publish an identity-signed encryption-key assertion before it can receive E2E messages. Missing, stale, unsigned, or mismatched encryption-key discovery fails closed; do not retry as plaintext unless the human explicitly chooses the separately named legacy plaintext mode from the final CLI. Service signatures may assert route support, but not recipient encryption-key authority. Local identities omit absent `stable_id`/address fields instead of sending empty strings. In non-interactive runs, stop, report the exact `aw doctor` / command error, and ask the human or coordinator to run the approved key setup, backup, or rotation flow.
70
+ An identity must publish an identity-signed encryption-key assertion before it can receive E2E messages. New self-custodial identity and team-install paths create local encryption key material automatically, including `aw id create`, `aw init`, `aw service init`, `aw id team accept-invite`, `aw id team fetch-cert`, and bootstrap/add-worktree flows. Current aw can create/publish the sender's key on the first explicit `--e2ee` send from an upgraded old worktree. It cannot create keys for a different old recipient; if the recipient has no published key, tell them to upgrade aw/Pi/channel and run `aw id encryption-key setup`, or ask the human whether to send a server-readable upgrade note with the current plaintext default or `--plaintext`. Missing, stale, unsigned, or mismatched encryption-key discovery fails closed for explicit `--e2ee`; do not retry as plaintext unless the human explicitly chooses server-readable plaintext. Service signatures may assert route support, but not recipient encryption-key authority. Local identities omit absent `stable_id`/address fields instead of sending empty strings. In non-interactive runs, stop, report the exact `aw doctor` / command error, and ask the human or coordinator to run the approved key setup, backup, or rotation flow.
71
71
 
72
72
  Use the CLI keyring commands for self-custodial E2E readiness:
73
73
 
@@ -79,7 +79,7 @@ aw id encryption-key show # inspect local keyring state
79
79
 
80
80
  `setup` stores the private key locally before publishing the public assertion. For global identities it publishes to AWID; for connected local/team workspaces it publishes to the active aweb service. `rotate` must not delete old private keys. After either command, remind the human to back up `.aw/encryption-keys/`.
81
81
 
82
- Hosted custodial MCP, dashboard-side send/read, and other server-side tools are **server-readable hosted messaging**, not E2E, because plaintext or decryption capability enters AC/aweb. Do not tell users that hosted custodial/server-side messaging is end-to-end encrypted unless a future design keeps plaintext and decryption fully outside AC.
82
+ Hosted custodial MCP, dashboard-side send/read, and other server-side tools are **server-readable hosted messaging**, not E2E, because plaintext or decryption capability enters AC/aweb. Do not use the end-to-end label for hosted custodial/server-side messaging unless a future design keeps plaintext and decryption fully outside AC.
83
83
 
84
84
  AWID controller keys are separate from worktree identity keys. Namespace and team controller keys live under `~/.awid/`; they are authority keys, not app config. Keep that directory safe and backed up. Worktree identity keys (`.aw/signing.key`) remain with the workspace they act from.
85
85
 
@@ -161,7 +161,7 @@ Interpret failures by what's missing (file references assume a self-custodial CL
161
161
 
162
162
  - **No `.aw/` in this directory** — there is no workspace here at all. Run `aw init` or move to a directory that has been initialized.
163
163
  - **`.aw/signing.key` missing** — workspace exists but has no signing key. Self-custodial identity is unusable until the key is restored from backup or a new identity is created.
164
- - **E2E encryption-key check fails** — distinguish the cases the CLI reports: missing local encryption private key, missing published encryption-key assertion, stale/mismatched assertion, or missing archived key for an older message. Do not advise plaintext fallback. Capture the exact error, run `aw doctor` when available, and ask the human to restore keys from backup or run `aw id encryption-key setup` / `aw id encryption-key rotate` as appropriate.
164
+ - **E2E encryption-key check fails** — distinguish the cases the CLI reports: missing local encryption private key, missing published encryption-key assertion, stale/mismatched assertion, or missing archived key for an older message. Do not advise plaintext fallback. Capture the exact error, run `aw doctor` when available, and ask the human to restore keys from backup or run `aw id encryption-key setup` / `aw id encryption-key rotate` as appropriate. Use `--plaintext` only when the human explicitly chooses server-readable plaintext.
165
165
  - **`.aw/workspace.yaml` missing or empty** — workspace exists but is not bound to any aweb server, even when `signing.key` is present. Re-run `aw init`.
166
166
  - **No global identity / no `did:aw` registered** — only a local workspace identity exists. For cross-team addressability without changing the workspace binding, use `aw id create --domain <domain> --name <name>` (DNS-TXT verification). Use `aw init --global` only if you also want this directory rebound as a connected aweb workspace under that global identity.
167
167
  - **Already ran `aw init --byod --global` expecting offline BYOT prep** — that command bootstrapped and connected this directory to the `default:<domain>` team on app.aweb.ai (the team created during BYOD onboarding), leaving `.aw/{identity.yaml,signing.key,teams.yaml,workspace.yaml,team-certs/}` populated. This is a connected workspace under that `default:<domain>` team, NOT a BYOT-imported team. To recover, pick one:
@@ -10,9 +10,11 @@ This skill is the playbook for aweb channel awakenings. When you receive an inje
10
10
 
11
11
  It also covers explicit user requests to send mail or chat through aweb.
12
12
 
13
- E2E messaging boundary: for encrypted v2 messages, AC/aweb servers route ciphertext and local clients decrypt before showing or injecting plaintext. Hosted custodial MCP, dashboard-side send/read, and server-side tools are **server-readable hosted messaging**, not E2E. Do not describe hosted custodial/server-side messaging as end-to-end encrypted.
13
+ E2E messaging boundary: for encrypted v2 messages, AC/aweb servers route ciphertext and local clients decrypt before showing or injecting plaintext. Hosted custodial MCP, dashboard-side send/read, and server-side tools are **server-readable hosted messaging**, not E2E. Do not use the end-to-end label for hosted custodial/server-side messaging.
14
14
 
15
- Legacy plaintext boundary: existing plaintext mail/chat remains legacy/server-readable while retained and must not be described as retroactively E2E. If an intended E2E send fails because keys, capability, route support, or version support is missing/stale/mismatched, stop and report the exact failure. Do not resend as plaintext unless the human explicitly chooses the approved legacy plaintext command/flag.
15
+ Interim plaintext boundary: in the current aw CLI release, mail and chat are server-readable plaintext by default. Do not describe default CLI mail/chat as E2E. Pass `--e2ee` only when the human explicitly wants encrypted send; if that encrypted send fails because keys, capability, route support, or version support is missing/stale/mismatched, stop and report the exact failure. Do not silently retry as plaintext.
16
+
17
+ Mixed-version boundary: old pre-E2E aw/channel/Pi clients may not have published recipient encryption keys yet. A current aw CLI can create/publish the sender's local encryption key for explicit `--e2ee` sends, but it cannot create keys for another recipient. If the recipient lacks a key, report that they need to upgrade aw/Pi/channel and publish a key. Plain default sends and `--plaintext` are server-readable.
16
18
 
17
19
  If the event says to use the aw CLI and the response is not obvious, continue with this skill. For broader work coordination, load `aweb-coordination`. For recipient addressability, inbound-mode policy, team membership, or multi-team identity questions, load `aweb-team-membership`.
18
20
 
@@ -77,15 +79,15 @@ aw chat extend-wait <from> "working on it, 2 minutes"
77
79
 
78
80
  Before replying to a confusing chat, inspect pending/open/history state. Do not use chat for broad FYI updates. Send mail instead.
79
81
 
80
- Encrypted chat is explicit. Use `--e2ee` only when the human or policy asks for E2E chat and every participant has identity-authorized encryption capability:
82
+ Mail and chat are server-readable plaintext by default in the current aw CLI release. Add `--e2ee` only when the human explicitly wants an encrypted send; it fails closed if keys, capability, route support, or version support are missing. `--plaintext` is an explicit clarifier for the current default.
81
83
 
82
84
  ```bash
83
- aw chat send-and-wait <alias-or-address> "..." --start-conversation --e2ee
84
- aw chat send-and-leave <alias-or-address> "..." --e2ee
85
- aw chat extend-wait <from> "working on it" --e2ee
85
+ aw chat send-and-wait <alias-or-address> "..." --start-conversation
86
+ aw chat send-and-leave <alias-or-address> "..."
87
+ aw chat extend-wait <from> "working on it"
86
88
  ```
87
89
 
88
- Read paths such as `aw chat pending`, `aw chat history`, and channel listen/decrypt paths show plaintext only after local decryption. If `--e2ee` fails because a key, capability, route, or version is missing or stale, stop and report the exact error; do not resend as plaintext unless the human explicitly chooses the approved legacy plaintext path.
90
+ Encrypted read paths such as `aw chat pending`, `aw chat history`, and channel listen/decrypt paths show plaintext only after local decryption. If an explicit `--e2ee` send fails because a key, capability, route, or version is missing or stale, stop and report the exact error; do not resend as plaintext unless the human explicitly chooses server-readable plaintext.
89
91
 
90
92
  ## Harness surfaces
91
93
 
@@ -109,7 +111,7 @@ Harness support differs:
109
111
 
110
112
  The channel is inbound only. Use `aw mail` or `aw chat` to respond.
111
113
 
112
- For E2E messages, channel/Pi/`aw run` may show plaintext only after local decryption in the user's workspace or client process. Server notifications and SSE payloads should be metadata-only for encrypted content. Recipient E2E capability and encryption keys must be identity-authorized; a service signature can assert route support only. If an event or tool error says an encryption key/capability is missing, stale, or mismatched, fail closed and report the error. Do not silently resend as plaintext.
114
+ For E2E messages, channel/Pi/`aw run` may show plaintext only after local decryption in the user's workspace or client process. Server notifications and SSE payloads should be metadata-only for encrypted content. Recipient E2E capability and encryption keys must be identity-authorized; a service signature can assert route support only. If an event or tool error says an encryption key/capability is missing, stale, or mismatched, fail closed and report the error. Do not silently resend as plaintext. If the local channel/Pi process was upgraded from a pre-E2E version, run `aw id encryption-key setup` in the workspace before expecting it to receive encrypted messages.
113
115
 
114
116
  ## Control and work awakenings
115
117
 
@@ -84,7 +84,7 @@ aw init # if the joining directory still needs server binding
84
84
 
85
85
  No token round-trip. Direct controller-mint. Available only for hosted teams because BYOT controller keys aren't held by aweb.
86
86
 
87
- **Path 3 — CLI invite-token, for hosted local-worktree only.** Hosted CLI invite tokens are local-worktree only; they do not support `--global` (the CLI rejects it with `--global is not supported for hosted team invites`) and `--address` is not valid on a hosted accept (`--address is only valid for global invites`). Use this when the owner wants to invite a new local-workspace identity by token:
87
+ **Path 3 — CLI invite-token, for hosted self-custodial local or global identities.** Hosted CLI invite tokens are redeemed through the cloud, but the accepting directory keeps its own signing key. Use the default form when the owner wants to invite a new local-workspace identity by token:
88
88
 
89
89
  ```bash
90
90
  # Owner side (in a workspace with the necessary authority):
@@ -97,7 +97,14 @@ aw id team accept-invite <token> --alias <alias>
97
97
  aw init # finish wiring the new workspace
98
98
  ```
99
99
 
100
- `accept-invite` refuses to overwrite an existing `.aw/` identity and generates a fresh local self-custodial identity in the target directory before requesting the certificate. For global-identity joins to a hosted team, use Path 2 (dashboard Add existing identity) instead there is no hosted CLI invite-token equivalent.
100
+ `accept-invite` refuses to overwrite an existing `.aw/` identity and generates a fresh local self-custodial identity in the target directory before requesting the certificate. For a hosted global identity, accept the hosted token with `--address <domain>/<name>`:
101
+
102
+ ```bash
103
+ aw id team accept-invite <token> --address <domain>/<name>
104
+ aw init # finish wiring the new workspace
105
+ ```
106
+
107
+ In the hosted `--address` case, the CLI creates a fresh self-custodial global identity for the address, registers it through the hosted service, and installs the hosted team certificate. The hosted service signs the team certificate; it does not receive the accepting directory's private signing key. If the user already has a global identity and only needs a certificate for an existing hosted team, Path 2 (dashboard Add existing identity + `fetch-cert`) remains valid.
101
108
 
102
109
  This is **not** the cross-machine BYOT path. Do not present it as the normal way to join a BYOT team from another machine.
103
110
 
@@ -161,7 +168,7 @@ This is the local-controller convenience case only. For cross-machine BYOT joins
161
168
 
162
169
  Two distinct local actions install a membership:
163
170
 
164
- - **`aw id team accept-invite <token>`** — redeems a CLI invite token. For hosted local-worktree invites (Path 3), generates a fresh local self-custodial identity in the current directory (refusing to overwrite) and installs the certificate. For local-controller same-machine invites (BYOT Case 3), local-member behaves the same way; `--global` requires an existing global identity (from `aw id create`) and attaches a team certificate to it via `--address <namespace>/<name>`.
171
+ - **`aw id team accept-invite <token>`** — redeems a CLI invite token. For hosted invites (Path 3), generates a fresh self-custodial identity in the current directory (refusing to overwrite) and installs the certificate; default is local, while `--address <domain>/<name>` creates/registers a fresh global identity through the hosted service before certificate install. For local-controller same-machine invites (BYOT Case 3), local-member behaves the same way as hosted local; global accepts require an existing global identity (from `aw id create`) and attach a team certificate to it via `--address <namespace>/<name>`.
165
172
  - **`aw id team fetch-cert --namespace <namespace> --team <team> --cert-id <id>`** — installs a certificate that has already been minted server-side (by hosted "Add existing identity") or signed by a controller (BYOT `add-member`). Used for hosted Path 2 and BYOT Case 1.
166
173
 
167
174
  If you have a token, use `accept-invite`. If you have a `cert-id` printed by the dashboard or controller, use `fetch-cert`.