@ekanos/cli 0.14.0 → 0.16.0

package/templates/skills/build-agent/SKILL.md

@@ -39,9 +39,15 @@ installed — so check it, every time (§ 4, "Make it reachable").
 ## Hard rules
 
 - Never ask for, accept or write a secret (API key, client secret, webhook
-  signing secret). The user types it at their own terminal — `apps set`,
-  `apps connect`, `teams app set` and `teams connect` ask with hidden input
-  and refuse an agent run — or a team enters it in the Ekanos app.
+  signing secret), and never read one from a file or a variable yourself.
+  The user enters it, and it never passes through you: run the command with
+  `--browser` (`apps set`, `apps connect`, `teams app set`, `teams connect`,
+  `teams mcp token`, `teams llm-key set` take it) and the CLI opens a
+  one-time form in their browser on this computer — tell them to fill it in
+  there. If they would rather, they put it in an environment variable or a
+  file only they can read, and you pass `--secret-env <NAME>` or
+  `--secret-file <path>`. Or they type it at their own terminal, or a team
+  enters it in the Ekanos app. A secret is never a value on the command line.
 - Never `publish`, `rollback` or `archive` without the user's explicit yes to
   that version or agent, after they have seen it. `--yes` records that
   consent; it is never a way past a question.
@@ -105,7 +111,8 @@ list` to find the role holding `agents.review` for reviewers — see the
 `ekanos-platform` skill, "Onboarding a team"), and send the member who will
 sign in the link from `ekanos teams connect <team> <product>`. For the
 Source's app itself, `references/app-setup.md` has the console walk-through.
-Secrets are only ever entered at the user's terminal or in the app.
+Secrets are only ever entered by the user — in the `--browser` form, at
+their terminal, or in the app — never through you.
 
 ## 2. The interview
 
@@ -188,25 +195,52 @@ in parentheses are the recommendation when the user has no preference.
    new draft; publishing puts the team back to following.
 4. Ask: publish this version to every team now? Only on yes:
    `npx @ekanos/cli agents publish <key> --source <slug> --to <n> --yes`.
-   When the user is the person the agent runs as on their teams, ask once
-   whether to add `--confirm-access` (it confirms, as them, that the agent
-   may use their connections there, and moves those teams at once; never
-   add it without their yes). A version that reaches further than a team
-   confirmed does not break that team: it is **held** on the version it
-   runs until the person it runs as confirms. The output lists each held
-   team, what the new version adds, who confirms and the `teams agents
-   confirm` command (which moves it) — relay it; never send them to the app
-   for it.
+   The publish is the confirmation: every team that follows the agent
+   moves to the new version, and one that had confirmed what it may use
+   stays confirmed, now in the publisher's name — even when the version
+   reaches further. No team is held. Ask once whether to add
+   `--confirm-access` (it also confirms, as the user, every team on that
+   version that was never confirmed; never add it without their yes). The
+   output lists any team pinned to another version, what the new version
+   would add to it, and the `teams agents unpin` command that moves it —
+   relay it.
 5. If anything waits for approval, name its reviewers (**Reviewers**
    below) before teams turn it on — a draft nobody may decide just waits.
 6. Hand over the team-side checklist (`references/triggers.md` has the
    per-integration parts): find it under Agents → "Provided for your team",
    Turn on, connect what it needs, **install the channel's agent for a
-   channel trigger**, confirm access (`teams agents confirm <team> <key>`,
-   by the person it runs as, or `teams agents enable … --confirm-access`
-   when that is the user), add triggers. Suggest one team pilots
+   channel trigger**, confirm access (`teams agents confirm <team> <key>`
+   or `teams agents enable … --confirm-access`, as the user; or a team
+   manager in the app — never a plain member), add triggers. Suggest one
+   team pilots
    it first, and do § 4 with them.
 
+## 3b. Only one team, or only the user: a team's own or a personal agent
+
+When the agent is for one team only, or for the user alone (§ 2's rollout
+question, `references/rollout.md`), skip the template: the same files make a
+team's own agent, or with `--personal` the user's own.
+
+1. On their go: `npx @ekanos/cli teams agents create <team> --from agents/<key> --source <slug> --json`
+   (add `--personal` for the user's own). The user becomes its creator, so
+   they must be an active member of that team; a `NOT_A_TEAM_MEMBER` refusal
+   names the command that adds them. Skill folders beside it are pushed as
+   that team's skills. Drop any field only a template has (exit 3 lists them).
+2. It starts as a draft:
+   `npx @ekanos/cli teams agents enable <team> <key> --source <slug> --json`.
+   Confirm what it may use only with the user's yes (`--confirm-access` on
+   `create` or `enable`, or `teams agents confirm <team> <key>`); a personal
+   agent's creator alone may.
+3. Start it from a schedule or a webhook:
+   `npx @ekanos/cli teams triggers add <team> <key> schedule --cron "0 8 * * 1-5" --timezone <zone> --prompt "…" --json`
+   or `… webhook --prompt "…"`. The webhook's token is saved to a file only
+   the user can read — never open or print it; tell them a personal agent's
+   token lets whoever holds it make the agent act as them.
+4. Later changes: edit the files and
+   `npx @ekanos/cli teams agents apply <team> agents/<key> --base-version <n> --json`
+   (`<n>` from `teams agents show`). Never `--overwrite` a conflict you have
+   not shown the user.
+
 ## 4. Make it reachable, and prove it end to end
 
 For each team that turns on an agent with a channel trigger, start with
@@ -224,12 +258,12 @@ screen). For the detail behind it:
    and `agent` (`credentialsSaved`, `connected` = installed, `neededBy`),
    and the `agent-events` webhook in `teamApps[].webhooks` must have an
    `endpoint`. Read the state back to the user in those words.
-3. Not installed: the user runs, **in their own terminal** (it asks for the
-   Linear app's secrets, which you never handle):
-   `npx @ekanos/cli teams connect <team> linear --connection agent --source <slug>`.
-   It asks for the app's client ID, secret and webhook signing secret if
-   missing, opens the install (a Linear workspace admin approves it) and
-   waits. No webhook URL yet: `npx @ekanos/cli teams webhook <team> linear
+3. Not installed: run
+   `npx @ekanos/cli teams connect <team> linear --connection agent --browser --source <slug>`
+   (or the user runs it without `--browser` in their own terminal). If the
+   app's client ID, secret or webhook signing secret is missing, it opens a
+   form in the user's browser for them to fill — you never handle those —
+   then opens the install (a Linear workspace admin approves it) and waits. No webhook URL yet: `npx @ekanos/cli teams webhook <team> linear
    agent-events --source <slug>` (shown once, and saved to a file only the
    user can read — the output names it; the user copies it into the Linear
    app. Never open or print that file yourself).

package/templates/skills/build-agent/references/agent-json.md

@@ -56,7 +56,10 @@ conflicting change unless `--overwrite`. Unknown fields are refused.
 ```
 
 The tool names above are illustrations. Take real ones from
-`ekanos catalog --json`.
+`ekanos catalog --json`; `ekanos catalog <product> --json` gives each tool's
+`inputSchema` (when a tool needs an id, another tool of the product returns
+it) and the product's `connection` (`connectedBy`, `runsUse`,
+`sourceConnection`).
 
 ## Fields
 

package/templates/skills/build-agent/references/app-setup.md

@@ -41,23 +41,30 @@ working from those rather than from Ekanos.
   the provider's docs rather than guessing.
 - The last console step is always "copy the client ID and the secret".
   **Never ask them to paste the secret into the chat.** For the Source's app,
-  have them run, **in their own terminal**:
+  run this yourself, and tell them a form is opening in their browser:
 
   ```bash
-  npx @ekanos/cli apps set <product> --source <slug>
+  npx @ekanos/cli apps set <product> --browser --source <slug>
   ```
 
-  It asks for the client ID, then the secret with hidden input; Enter keeps
-  a saved value, so either can be changed on its own. For a team's
-  app, they enter the fields in the team's setup panel in the Ekanos app.
+  The form asks for the client ID and the secret; a field left empty keeps
+  its saved value, so either can be changed on its own. What they type goes
+  from their browser to the CLI and on to Ekanos, never to you. (Or they run
+  `npx @ekanos/cli apps set <product> --source <slug>` in their own terminal,
+  which asks with hidden input.) For a team's app,
+  `npx @ekanos/cli teams app set <team> <product> --browser --source <slug>`
+  does the same, or they enter the fields in the team's setup panel in the
+  Ekanos app.
 - Then check: `apps show <product> --source <slug> --json` should say
   `configured: true`, and the catalog's step should be `done`. Tell them
   teams can now connect, and what the team-side steps are.
 
 ## When it goes wrong
 
-- `apps set` says it needs a terminal: it was run inside Claude or a script.
-  Ask them to run it in a terminal tab themselves.
+- `apps set` says there is no terminal to ask at: add `--browser`. If
+  `--browser` is refused (CI, SSH, no display), ask them to run it in a
+  terminal tab themselves. The form gives up after five minutes; run it
+  again for a fresh one.
 - `apps set` asks which host: they are signed in to more than one Ekanos;
   add `--host <url>` (the Source's site) or log out of the other.
 - Sign-in later fails with a redirect mismatch: the app is missing one of the

package/templates/skills/build-agent/references/rollout.md

@@ -31,25 +31,21 @@ Built with `ekanos agents` by a Source admin.
 - **What stays the team's:** whether it is on, its triggers, its own
   connections, its run history, and whatever `teamCustomization` lets it add.
 - **Confirming access.** The agent uses the connections of the person it
-  runs as, and in runs no one watches only once that person confirms it may:
-  `ekanos teams agents confirm <team> <key>`, signed in as themselves (or
-  `teams agents enable <team> <key> --confirm-access` to turn it on as
-  yourself and confirm at once). Nobody confirms for anyone else.
+  runs as, and in runs no one watches only once someone who sets it up
+  confirms it may: the Source admin with `ekanos teams agents confirm <team>
+  <key>` (or `teams agents enable <team> <key> --confirm-access` to turn it
+  on and confirm at once), or one of the team's agent managers with
+  **Confirm access** in the app. Each confirms as themselves; a plain team
+  member never does. It confirms only the version it printed: a newer
+  publish since is refused, not confirmed unseen.
 - **When a new version needs more access** than a team confirmed (a new
   product or tool, `custom` → `read_only`/`all`, a tool that now runs without
-  approval), that team is **held**: it keeps running the version it is on,
-  confirmed and working, and the new one waits until the person it runs as
-  confirms it — `ekanos teams agents confirm <team> <key>`, which prints the
-  version it confirms and moves the team to it at once (or **Confirm and
-  update** on the agent's page); a version published after that is refused,
-  not confirmed unseen. Nobody
-  else can move it. Skills, instructions, model, triggers and links never
-  hold a team. `agents publish` lists every held team, what the version adds,
-  who confirms and the command; `agents publish --confirm-access` confirms,
-  and moves, every team where the agent runs as the publisher. `teams agents
-  list|show` say "held on vN, vM waiting for confirmation" — the agent is
-  still live. A held team that gets another publish waits for the newest; a
-  team that never confirmed simply moves; a pinned team stays on its pin.
+  approval), the publish is the confirmation: every following team moves to
+  it and stays confirmed, now in the publisher's name. No team is held.
+  `agents publish --confirm-access` also confirms every team on that version
+  that was never confirmed. A team that never confirmed moves unconfirmed; a
+  pinned team stays on its pin, and `agents publish` lists it with what the
+  new version would add and the `teams agents unpin` command.
 
 Good for: the same job done by several teams; a central owner who improves
 it over time; consistent behaviour and approvals.
@@ -57,7 +53,7 @@ it over time; consistent behaviour and approvals.
 **A Source admin can do a team's part from the terminal**:
 `ekanos teams agents enable <team> <key> [--as <member-email>]` turns it on
 for the team (running as that member, the team's owner by default; with
-`--confirm-access`, as you, confirmed in the same step),
+`--confirm-access`, you confirm it in the same step),
 `ekanos teams agents pin|unpin`, `ekanos teams agents policy`, and
 `ekanos teams triggers|links|mcp` set up the rest. `ekanos teams agents list
 <team>` shows where each team stands and what it still needs connected.
@@ -69,11 +65,35 @@ plan is ready.
 
 ## A team's own agent
 
-Built by a team in the app (Agents → New). Only that team has it; the Source
-cannot update or roll it back, and nothing about it is visible to other teams.
+Built for one team, in the app (Agents → New) or from the terminal with the
+same `agent.json` a template uses:
+`ekanos teams agents create <team> --from agents/<key>` (then
+`ekanos teams agents enable <team> <key>` — it starts as a draft), and
+`ekanos teams agents apply <team> agents/<key> --base-version <n>` to change
+it from the file later. Only that team has it; the Source cannot update or
+roll it back, and nothing about it is visible to other teams. Whoever creates
+it is its creator — its tools run as them — so they must be a member of the
+team who manages its agents. A field only a template has (`connections`,
+`mcpServers`, `teamCustomization`, `triggers`, `links`, `teamOverrides`) is
+refused; add triggers with `ekanos teams triggers add`.
 
 Good for: one team's own process; experiments a team owns.
 
+## A personal agent
+
+One person's agent for themselves: `ekanos teams agents create <team> --from
+agents/<key> --personal`, by a member of that team. It acts for its creator,
+with their own connections, on every trigger, so it is theirs alone: nobody
+else changes it, runs it, decides its approvals or cancels its runs — not a
+team manager, not the Source admin (`PERSONAL_AGENT_CREATOR_ONLY`). Others see
+that it exists, not what its runs read or did. It starts from a schedule or a
+webhook (`ekanos teams triggers add <team> <key> schedule --cron "…" --prompt
+"…"`); whoever holds its webhook token can make it act as its creator, so the
+token goes to a file only they can read, never into a chat.
+
+Good for: "brief me on my day", "draft replies to my inbox" — one person's
+own work on their own accounts.
+
 ## Questions that decide it
 
 - How many teams do this work? The same way?

package/templates/skills/build-agent/references/set-up-an-integration.md

@@ -60,19 +60,32 @@ connect nothing for it.
   `teams show` (or `catalog`) and say what changed ("Ekanos sees the client ID
   and secret now"). If the check disagrees with what they said, look at the
   difference with them; don't move on.
-- **Secrets never pass through the chat.** Client secrets and signing
-  secrets go in at the user's own terminal (`ekanos apps set`,
-  `ekanos teams app set`, with hidden input) or in the team's page in the app.
-  If they paste one into the chat anyway, tell them to rotate it in the
-  provider's console and enter the new one at the terminal.
-- **Connect with `teams connect <team> <product>`, run by the user in their
-  own terminal.** It does whatever the integration needs: asks a form's fields
+- **Secrets never pass through the chat, or through you.** Client secrets
+  and signing secrets go in through a form in the user's browser that you
+  start with `--browser` (`ekanos apps set <product> --browser`,
+  `ekanos teams app set <team> <product> --browser`), at the user's own
+  terminal with hidden input, or in the team's page in the app. Never read
+  one from a file or an environment variable yourself; if the user has put
+  one there, pass its name with `--secret-env <NAME>` or its path with
+  `--secret-file <path>` and let the CLI read it. If they paste one into the
+  chat anyway, tell them to rotate it in the provider's console and enter
+  the new one through the form.
+- **Connect with `teams connect <team> <product>`** — add `--browser` when
+  you run it, so any field it needs opens as a form in the user's browser;
+  without it the user runs it in their own terminal. It does whatever the
+  integration needs: asks a form's fields
   (secrets hidden), runs the team-app prompts first when the team's own app is
   missing, or opens a one-time sign-in link and waits until the team is
-  connected. The provider's consent is still a person's click, by a member of
-  the team (owner/admin for a team-wide connection): the user when they are
-  one, else `--as <email>` prints a link to send that member. `--link-only`
-  prints just the team's page. Tell them who should sign in: the account the
+  connected. Non-secret fields of any type can be passed with
+  `--set <field>=<value>` (a list as `a,b`; secrets and JSON values only at a prompt), so
+  it also runs in a script; optional ones can be left out. The provider's
+  consent is still a person's click, by a member of the team (owner/admin for
+  a team-wide connection): the user when they are one, else `--as <email>`
+  prints a link to send that member. A Source admin who is not on the team
+  joins it first with `ekanos teams members add <team> --self` (no email). A
+  personal product (each person connects their own, such as ROAM) connects
+  the account of whoever runs `teams connect`. `--link-only` prints just the
+  team's page. Tell them who should sign in: the account the
   integration acts as. If the product is not enabled for the Source, a
   super-admin enables it (`sources products` shows what the Source has). A dedicated seat such as "Support agent" makes its replies easy
   to recognise.
@@ -88,11 +101,12 @@ pilot), the team-side steps can be done from the CLI:
 1. `npx @ekanos/cli teams show <team> <product> --source <slug>`: the
    callback URL to register and the integration's steps.
 2. They create the app in the provider's console, step by step as above.
-3. **In their own terminal:**
-   `npx @ekanos/cli teams app set <team> <product> --source <slug>`. It asks
-   for each field and hides the secret ones; Enter keeps a saved value. It
-   refuses to run inside Claude; that is deliberate. To change one value
-   later, they need not re-enter the rest:
+3. Run `npx @ekanos/cli teams app set <team> <product> --browser --source <slug>`
+   and tell them a form is opening in their browser: it has every field,
+   secrets as password inputs, and a field left empty keeps its saved value.
+   What they type never reaches you. (Without `--browser`, they run it in
+   their own terminal, which asks for each field and hides the secret ones.)
+   To change one value later, they need not re-enter the rest:
    `teams app set <team> <product> --field <name>` asks for just that field
    (names are in brackets in `teams show`), `--set <name>=<value>` sets a
    non-secret field (a subdomain, a client ID) without a prompt — you may run
@@ -122,10 +136,11 @@ mentions arrive. When the agent has any Linear trigger:
    redirect URIs, webhooks on with **Agent session events** and **Issues**.
 3. Its webhook URL: `teams webhook <team> linear agent-events` (once; paste
    it into the Linear app's webhook URL).
-4. **In their own terminal:**
-   `npx @ekanos/cli teams connect <team> linear --connection agent --source <slug>`
-   — asks for the client ID, secret and webhook signing secret if any is
-   missing, opens the install for a Linear workspace admin to approve, and
+4. `npx @ekanos/cli teams connect <team> linear --connection agent --browser --source <slug>`
+   — opens a form in the user's browser for the client ID, secret and
+   webhook signing secret if any is missing (without `--browser`, the user
+   runs it in their own terminal and it asks there), opens the install for a
+   Linear workspace admin to approve, and
    waits until it is installed. (`teams connect <team> linear` with no
    `--connection` offers this itself once the personal connection is made,
    when the team has agents with Linear triggers.)
@@ -146,11 +161,12 @@ the Source's connection.
 1. **Connect, once, as the Source.** For an integration where each customer
    brings its own app (Zendesk), first create that app in the shared account,
    exactly as in the worked example below (OAuth client, Confidential), but
-   once, for the Source. Then, **in their own terminal**:
-   `npx @ekanos/cli apps connect <product> --source <slug>`. It asks for the
+   once, for the Source. Then run
+   `npx @ekanos/cli apps connect <product> --browser --source <slug>` (or the
+   user runs it without `--browser` in their own terminal). It asks for the
    app's fields it doesn't have yet (Zendesk: subdomain, client ID, client
-   secret, webhook signing secret; secrets hidden, never as flags, and it
-   refuses to run inside Claude), prints the redirect URL to register and the
+   secret, webhook signing secret) in a form in the user's browser — never
+   through you, never as values on the command line — prints the redirect URL to register and the
    consent link, then waits up to ten minutes until it is connected. Whoever
    clicks the link is the account the integration acts as for every team, so
    suggest a dedicated seat ("Support agent"). `apps list` shows every
@@ -201,9 +217,9 @@ from `teams show zendesk`.
    Center › Apps and integrations › Webhooks › Create webhook › Trigger or
    automation: that URL, POST, JSON, no authentication. Open it and Reveal
    secret.
-3. **Credentials into Ekanos.** `ekanos teams app set <team> zendesk` in
-   their terminal: subdomain, client ID, client secret, webhook signing
-   secret. Any of them can be entered or changed later on its own
+3. **Credentials into Ekanos.** `ekanos teams app set <team> zendesk --browser`
+   (a form in their browser; or without `--browser`, in their terminal):
+   subdomain, client ID, client secret, webhook signing secret. Any of them can be entered or changed later on its own
    (`--field <name>`); `teams show` says which are saved.
 4. **Connect.** `npx @ekanos/cli teams connect <team> zendesk --source <slug>`
    opens the sign-in and waits; whoever approves it should be the Zendesk
@@ -244,5 +260,6 @@ from `teams show zendesk`.
   not installed for this team", or no webhook URL) and the command that
   fixes it. Installed and still silent: the Linear app's webhook must send
   **Agent session events** to the latest URL from `teams webhook`.
-- **A command says it needs a terminal:** it was run inside Claude. Ask them
-  to run it in a terminal tab themselves.
+- **A command says there is no terminal to ask at:** run it again with
+  `--browser`. If `--browser` is refused (CI, SSH, no display), ask them to
+  run it in a terminal tab themselves.

package/templates/skills/build-agent/references/triggers.md

@@ -123,9 +123,10 @@ brands, groups and organizations match by name or id. Where the answer goes
    webhook URL), for a Slack trigger the team's Slack. `teams agents list
    <team>` shows each agent's `channels`; none may be `ready: false`.
 4. Do each integration's own setup (team app, webhook) from its guide.
-5. Confirm access: the person it runs as runs `npx @ekanos/cli teams agents
-   confirm <team> <key> --source <slug>` as themselves (or turned it on with
-   `--confirm-access`). `teams agents list <team>` shows anyone still to.
+5. Confirm access: the Source admin runs `npx @ekanos/cli teams agents
+   confirm <team> <key> --source <slug>` (or turned it on with
+   `--confirm-access`), or a team manager confirms in the app. `teams agents
+   list <team>` shows any agent still unconfirmed.
 6. Add the triggers above — unless the template already sets them.
 7. Prove it end to end: a real @mention (or the real event) → a run in
    `runs list --team <team>` → the agent's reply where it was asked. A test

package/templates/skills/build-integration/references/widget-design.md

@@ -185,7 +185,7 @@ mock switch) so the harness can show all four; remove it before publish.
   `border-border`, `bg-primary`, `text-destructive`. NEVER raw palette
   classes (`bg-white`, `text-gray-500`, `bg-amber-400`) or hex/oklch
   literals — they break in dark mode and off-brand tenants.
-- **Accent discipline**: the primary (coral-orange) on ≤10% of the widget —
+- **Accent discipline**: the `primary` token (the Source's accent) on ≤10% of the widget —
   one CTA, one highlighted value, one active state. Semantic status colors
   (success/warning/destructive) are not accents.
 - **Depth via shadow, not borders** where a surface needs lift.

package/templates/skills/ekanos-platform/SKILL.md

@@ -54,6 +54,7 @@ npx @ekanos/cli teams members invite bank-a raj@bank-a.com --role admin   # defa
 npx @ekanos/cli teams members list bank-a                     # members and pending invitations
 npx @ekanos/cli teams members role bank-a raj@bank-a.com member
 npx @ekanos/cli teams members remove bank-a raj@bank-a.com --yes
+npx @ekanos/cli teams members resend bank-a lee@bank-a.com    # resend, or renew an expired invitation
 npx @ekanos/cli teams connect bank-a zendesk                  # connect it for the team (asks, signs in, waits)
 npx @ekanos/cli teams connect bank-a linear --as raj@bank-a.com   # a sign-in link for raj
 npx @ekanos/cli sources products                             # what the Source has enabled (super-admin enables)
@@ -68,10 +69,13 @@ npx @ekanos/cli sources products                             # what the Source h
 - Roles are the team roles (owner / admin / member, or the Source's own
   customized ones). Pick a reviewer for agents by the role holding
   `agents.review` in `teams roles list`. The primary owner's role cannot be
-  changed here; ownership moves in the app.
+  changed here; ownership moves in the app. The Source's custom roles
+  themselves are `sources roles` (`create|update|delete`; owner, admin and
+  member are fixed).
 - `teams connect <team> <product>` does the connect: it asks a form's fields
-  at the user's terminal (hidden for secrets — so the user runs it, never you
-  with values), runs the team-app prompts first when needed (Zendesk), or
+  at the user's terminal (hidden for secrets) or, run by you with
+  `--browser`, in a one-time form in the user's browser — never with values
+  from you — runs the team-app prompts first when needed (Zendesk), or
   opens a one-time sign-in link and waits. The person who signs in is a team
   member (owner/admin for a team-wide connection): the user when they are
   one, else `--as <email>` prints a link to send that member. `--no-wait`,
@@ -81,6 +85,17 @@ npx @ekanos/cli sources products                             # what the Source h
   what it has. Enabling one is a super-admin grant (`sources products enable`)
   that an `ekanos login` session cannot make — the super-admin does it in
   /admin.
+- The rest of a team's life: `teams leave <team> --yes` (the user's own
+  membership), `teams groups list|create|update|delete|members` (groups
+  narrow what their members see to `--products a,b`), `teams health <team>
+  [<product>] [--run]` (each connected integration's health; `--run` checks
+  one now; `<product> --mine` the user's own personal connection),
+  `teams workspace list|default <team> [<workspace>]`, and
+  `sources people` (everyone on the Source and their teams). Each one that
+  takes something away needs `--yes` when you run it, which you pass only
+  after the user says so. Transferring a team's ownership and deleting a team
+  are not in the CLI: the primary owner does them in the app, confirmed by a
+  code emailed to them.
 
 ## Products: integrations and experiences
 
@@ -136,8 +151,8 @@ connect (`setupSteps` step `provider-app`). It is the Source's own app — for a
 white-label Source, under its product name and company — and its admin
 creates it once in the provider's console. The integration ships the steps
 (the catalog's `instructions`, with the Source's exact callback URLs filled
-in); `ekanos apps set <product>`, run by the admin at their own terminal,
-takes the client ID and secret. The `build-agent` skill walks through it
+in); `ekanos apps set <product>` takes the client ID and secret — at the
+admin's own terminal, or in a browser form when you run it with `--browser`. The `build-agent` skill walks through it
 (`references/app-setup.md`). Integrations whose teams each bring their own
 app (Zendesk) have no Source app; each team follows that app's steps.
 
@@ -158,8 +173,13 @@ changed through the CLI or the app, with no deploy.
   (links) and which calls wait for approval, and — per area, with
   `teamOverrides` — whether a team may change them. The template wins unless
   an area is opened to teams.
-- **A team's own** — built by a team in the app (Agents → New). Only that team
-  has it, and the Source cannot update it.
+- **A team's own** — built for one team, in the app (Agents → New) or with
+  `ekanos teams agents create <team> --from <dir>` from the same `agent.json`.
+  Only that team has it, and the Source cannot update it.
+- **A personal agent** — one member's own (`--personal`, or "Just you" in the
+  app). It acts for its creator, with their own connections, on every trigger,
+  so only they change it, run it, decide its approvals or cancel its runs —
+  not a team manager and not the Source admin.
 
 Skills are folders (`SKILL.md` + references) an agent loads when needed.
 A Source admin pushes them with `ekanos skills push <dir>`: at Source level
@@ -183,29 +203,46 @@ always `ekanos teams <area> <verb> <team> …`:
 
 - `ekanos teams agents list <team>` — provided agents, on or off, the version
   each runs (pinned or following), triggers, links, the team's MCP servers,
-  and what each still needs connected.
+  and what each still needs connected; then the team's own and personal
+  agents and whose each is.
+- `ekanos teams agents create <team> --from <dir> [--personal]` /
+  `apply <team> <dir> [--base-version <n>]` — the team's own agent, or your
+  own, from an `agent.json` (+ `AGENT.md`, + `skills/<slug>/`). You become
+  its creator, so you must be an active member of the team. It starts as a
+  draft; `enable` turns it on.
 - `ekanos teams agents enable <team> <key> [--as <member-email>]
   [--confirm-access]` / `disable <team> <key>` — the app's "Turn on" /
   "Turn off". The agent runs as a team member who manages agents (the
-  team's owner by default; with `--confirm-access`, you).
-- `ekanos teams agents confirm <team> <key>` — the person the agent runs as
-  confirms, as themselves, that it may use their connections in runs no one
-  watches; the output says which products' connections that covers. It
-  confirms only the version it printed: a newer publish since is refused, to
-  be reviewed and confirmed again. Nobody confirms for anyone else.
+  team's owner by default): that member is its creator, whose personal
+  connections it uses. Who it runs as is chosen once, when it is turned
+  on; to change it, archive it and turn it on again with `--as`.
+  `--confirm-access` also confirms it, as you.
+- `ekanos teams agents archive <team> <key> [--yes]` / `unarchive <team>
+  <key>` — the app's Archive: off the team's list, nothing starts it, its
+  runs and setup kept; `unarchive` brings it back paused, for `enable`.
+- `ekanos teams agents confirm <team> <key>` — you confirm, as yourself,
+  that the agent may use its connections (the person it runs as's) in runs
+  no one watches; the output says which products' connections that covers.
+  Whoever sets an agent up confirms it — the Source admin, or a team
+  manager in the app — never a plain team member. It confirms only the
+  version it printed: a newer publish since is refused, to be reviewed and
+  confirmed again.
 - `ekanos teams agents pin <team> <key> <version>` / `unpin <team> <key>`.
 - `ekanos teams agents policy <team> <key>` — every tool the agent can call,
   read or write, and whether it runs on its own or waits for approval;
   `… policy <team> <key> set <tool> auto|approve`, `unset <tool>`,
   `--reads auto|approve --writes auto|approve`. A provided agent's policy
   follows its template unless the template turns on team overrides for it.
-  On any agent, a change that lets more run on its own drops the confirmation
-  of the person it runs as, and the agent waits for them to confirm again
-  (`--confirm-access` when that person is you).
+  On any agent, a change that lets more run on its own drops the
+  confirmation, and the agent uses only what needs none until someone who
+  sets it up confirms again (`--confirm-access` does it in the same step).
 - `ekanos teams agents skills <team> <key> [add|remove <skill>]` — the
   skills the agent reads; attach a team skill (pushed with
   `skills push --team`) or a Source one. A provided agent takes them only
   when its template's `teamCustomization.skills` is on; its own stay.
+- `ekanos teams agents tags <team> <key> [add|remove <tag>]` — labels that
+  organize the team's agents and grant nothing; `add` makes a tag the team
+  does not have yet.
 - `ekanos teams triggers list|add|remove <team> <key> …` — manual, schedule
   (`--cron`, `--timezone`), webhook (the token goes to a file only the
   user can read, never the output) and
@@ -214,12 +251,25 @@ always `ekanos teams <area> <verb> <team> …`:
   --filter '{"labels":["feedback"]}'`), plus `slack --channel '#name' [--dms]
   --yes` and `linear [--label <name>]` once the team has installed Slack or
   Ekanos's Linear app with `ekanos teams connect <team> slack|linear-app`.
+- `ekanos teams triggers enable|disable <team> <key> <trigger-id|key>` and
+  `edit <team> <key> <trigger-id|key> [--prompt …] [--cron … --timezone …]
+  [--filter …] [--channel …] [--dms] [--label …]` — turn a trigger off
+  without removing it, or change it in place: a webhook keeps its URL and
+  token (only `rotate` makes a new one).
 - `ekanos teams links list|add|remove <team> <from-key> [<to-key>] --kind
   talk|delegate [--mode await|handoff]`.
 - `ekanos teams mcp list|add|status|token|effect <team> [<server-key> …]` — a
   team's own MCP server (`--url`, `--auth none|token|oauth`); a token is typed
-  at the admin's terminal with hidden input, never in chat or arguments; OAuth
-  prints a link for a team member to open.
+  at the admin's terminal with hidden input, or in the `--browser` form, never
+  in chat or arguments; OAuth prints a link for a team member to open.
+  `ekanos teams mcp attach|detach <team> <server-key> <agent-key>` gives one
+  agent a team server, or takes it away (where its template allows), and
+  `refresh <team> <server-key>` (or `--agent <key>`) lists its tools again.
+- `ekanos teams llm-key show|set|remove <team>` — the team's own Anthropic
+  key, which its agents and assistant then use instead of the Source's.
+  `show` gives only whether one is saved and its last four characters; `set`
+  takes it like any secret (`--browser`, or `--secret-env <NAME>` /
+  `--secret-file <path>` the user prepared); `remove` needs `--yes`.
 
 Triggers, links and the policy of a provided agent follow its template by
 default; when the template has not turned on team overrides for that area,
@@ -261,19 +311,23 @@ is refused (`USER_NOT_IN_SOURCE`): `ekanos teams list` shows the teams.
 | Agents provided for every team | A Source admin, with `ekanos agents` (`agents archive <key>` retires one once no team has it on) |
 | Testing an unpublished agent version on one team | A Source admin: `ekanos teams agents enable\|pin <team> <key> --draft`, then `ekanos agents test <key> --team <slug>` |
 | Running a team's agent, reading its runs (transcript, tool calls) | A team's agent manager in the app, or a Source admin with `ekanos runs` |
-| Deciding what an agent run waits on (approve, reject, edit & send a reply) | A team's agent manager in the app, or a Source admin with `ekanos approvals` (for a team's own agent, only a Source admin who manages that team's agents) |
+| Deciding what an agent run waits on (approve, reject, edit & send a reply) | A team's agent manager in the app, or with `ekanos approvals`: a Source admin (for a team's own agent, only one who manages that team's agents), or any seat holder with that authority themselves — a member who manages (or, for reply drafts, reviews) the team's agents, a named reviewer, a personal agent's creator |
+| A team's workflows: saving one, turning it on, running it, deciding its approval gates | A team member who configures integrations, in the app's editor; or a Source admin with `ekanos workflows apply\|enable\|run\|approvals --team <slug>` (Workflows must be on for the Source; a member's personal workflow is theirs alone). Custom Code that writes or reaches a host is approved by whoever turns the workflow on: `ekanos workflows enable <workflow> --team <slug> --confirm-access` |
 | Skills (SKILL.md folders) for every team, or one team's own | A Source admin, with `ekanos skills push` (`--team <slug>` for one team); `ekanos skills archive` retires one nothing uses |
 | Knowledge articles for every team (General), or one team's own | A Source admin, with `ekanos knowledge push` (`--team <slug>` for one team); a team's members in the app |
 | Who decides agent drafts that wait for a person | A Source admin, with `ekanos reviewers` |
-| An integration's app for the whole Source (client ID and secret) | A Source admin, with `ekanos apps set` at their own terminal |
+| An integration's app for the whole Source (client ID and secret) | A Source admin, with `ekanos apps set` (at their own terminal, or its `--browser` form) |
 | One connection for the whole Source, used by provided agents in every team | A Source admin, with `ekanos apps connect` (status: `ekanos apps show`), or **Shared integrations › Connections** in the Source admin area |
 | Which team gets which events on that connection (Zendesk organization → team) | A Source admin, with `ekanos routes` (`webhook`, `options`, `set`, `list`, `remove`, `unrouted`, `replay`), or **Shared integrations › Routing** in the Source admin area |
 | A team's own app for an integration (client ID, secrets, webhook URL) | The team in the app, or a Source admin with `ekanos teams` |
 | A provided agent's triggers, links and approvals | A Source admin, in the template (`ekanos agents triggers / links / policy / overrides`); teams change them only where `teamOverrides` allows |
 | Creating a team, inviting its members, changing their roles | A Source admin, with `ekanos teams create` / `ekanos teams members` (or the team's owner in the app) |
+| A team's groups and default workspace | A Source admin, with `ekanos teams groups` / `ekanos teams workspace default`, or the team's owner in the app |
+| Transferring a team's ownership, deleting a team | The team's primary owner in the app (a code emailed to them confirms it), or a super-admin under /admin |
+| The Source's custom roles and their permissions | A Source admin, with `ekanos sources roles`; owner, admin and member are fixed |
 | Connecting an integration for a team (signing in) | A team member in the app, or a Source admin with `ekanos teams connect <team> <product>` (`--as <member-email>` when the connection is a person's own) |
 | Turning on a provided agent for a team, pinning its version, its triggers, links, MCP servers and approval policy | Each team in the app, or a Source admin with `ekanos teams agents\|triggers\|links\|mcp` |
 | Which products a team sees in the app (product scopes) | A Source admin: `ekanos sources scopes` (and `add`/`remove <scope> <product>`), `ekanos teams scope show\|set <team>`; creating a scope is in /admin |
 | Is a team's agent live, and if not, what is the next step | A Source admin, with `ekanos teams agents show <team> <key>`; the whole team on one screen with `ekanos teams show <team>` |
-| Disconnecting a team's integration, removing a team's MCP server | A Source admin, with `ekanos teams disconnect <team> <product> --yes` / `ekanos teams mcp remove <team> <server-key> --yes`, or the team in the app |
-| Confirming an agent may use a person's connections | Only the person it runs as, signed in as themselves: `ekanos teams agents confirm <team> <key>` (or `enable --confirm-access`, `agents publish --confirm-access`), or **Confirm access** in the app. On a team held on an earlier version (a newer one reaches further than they confirmed) it moves the team to the version waiting |
+| Disconnecting a team's integration, removing a team's MCP server | A Source admin, with `ekanos teams disconnect <team> <product> --yes` / `ekanos teams mcp remove <team> <server-key> --yes`, or the team in the app. A personal connection: only its owner, `ekanos teams disconnect <team> <product> --mine --yes` |
+| Confirming an agent may use its connections | Whoever sets it up, as themselves: the Source admin with `ekanos teams agents confirm <team> <key>` (or `enable --confirm-access`, `agents publish --confirm-access`), or a team manager with **Confirm access** in the app — never a plain member. A publish is the confirmation for following teams: no team is held on an earlier version |