[TigerYWang]

What changes

Shared Skills page, for an Admin. In a workspace shared with them, an Admin now sees Knowledge, Skills, as Orgo keeps it. It works with their own Orgo key, the same way Keys works, so nothing waits for the owner's Mac. From there they can:

• read every skill, with its SKILL.md, files and versions;
• publish a draft;
• import a skill folder as a new draft;
• update a skill from a folder. This publishes the folder as the next version, after a confirm step;
• roll back or delete a skill;
• give a skill that names its own bots to one more or one fewer;
• approve or take back a script.

Labels, Who has what, Suggest labels and a bot's proposals stay the owner's. A Member doesn't see Skills there, and the server refuses them before Orgo is asked. The other Knowledge kinds keep the owner's line, with an Open Skills button under it for an Admin.

The owner's Mac.

• Every 2 minutes it checks Orgo for skill changes: every time for a workspace with people in it, every 10 minutes for one without. An Admin's publish, roll back, delete or approval arrives soon after the Mac comes on.
• It counts a script approval when Orgo says the approver is the owner or an Admin. A Member's never counts, and a demoted Admin stops counting. With an older Orgo that doesn't send roles, only the owner's counts, as before.
• When an Admin's publish comes in and the owner has unpublished work in that skill's folder, the folder is kept and the Admin's version is stored beside it.
• When the owner and an Admin both published the same version number with different content, the owner's goes to Orgo as the next free number. Before, the two copies stayed different under one number. A roll back made on the Mac now also reaches Orgo this way. Every version kept on the Mac stays.

Bots answered on their own computer (runner). The runner now reads the workspace's published skills from Orgo with the computer's own key. It does this at most once a minute: at the start of a chat turn and before copying skills to the computer. It keeps them on the computer's disk.

• Each bot gets the skills Bops' own rule gives it: named for it, or under one of its labels.
• read_skill reads them.
• The copy to the computer carries them. A script there can run only once the owner or an Admin approved it.
• A skill moved back to draft or deleted in Orgo goes away on the computer too.
• If Orgo doesn't answer, the kept copy stays. With an older Orgo, or before the first read, everything works as before.

Chat.

• When a bot saves a new skill as a draft, on the Mac or on its computer, the answer now carries a card: "Saved as a draft", with "Review and publish". The button opens the skill in Skills. The card never publishes anything itself.
• The owner and an Admin see the card; a Member doesn't. Bops Cloud passes on the card's kind, slug and name.
• The bot now says the owner or an Admin can publish a new draft. A change to an existing skill is still the owner's to publish, because its folder is on the owner's Mac.

Why

Admins can do everything except delete or transfer the workspace and pay. Until now an Admin had no way to publish a skill from Bops, and nothing a member needed could happen with the owner's Mac off. Bots answered on their own computers also got no skill text at all with the Mac off, not even skills the owner had published.

This is phase 1 (Admins). Phase 2, Members with the "Memory and skills" switch, has a clean hook: sharedSkillsWho in lib/shared.ts is the one rule both the window and the server read.

How I checked it

Counts below are on the branch merged with main at 0.0.52.

• npx next typegen && npx tsc --noEmit -p .: clean. npx tsc -p cloud/tsconfig.json --noEmit: clean.
• eslint on every touched .ts/.tsx file: clean.
• New suites:
  • node --conditions=react-server scripts/test-shared-skills.mjs: 11 passed. Covers the route against a fake orgo-web: list, detail, file, publish, roll back, delete, bots, approvals, both folder paths, owner-only actions, a Member refused, plain words, no dashes or Orbit, nothing logged.
  • node scripts/test-skills-ui-shared.mjs: 8 passed. A linkedom render of the shared page, Knowledge and the card.
• Changed suites:
  • node --conditions=react-server scripts/test-skills.mjs: 29 passed. 5 of its checks already failed on main because of stale built-in skill counts; they now count from the built-in list. New checks cover Admin approvals by role, a pull that keeps the folder, the version clash and the poll.
  • node --conditions=react-server scripts/test-skills-v2.mjs: 26 passed. New checks cover the runner read, filtering, read_skill, the copy with approvals, Orgo away, a draft taken back, and an older Orgo.
  • node --conditions=react-server scripts/test-chat-tools.mjs: 91 passed (wording, the card on both paths, and an Admin's turn keeping create_skill).
  • node scripts/test-shared.mjs: 71 passed.
  • node --test cloud/test/core-members.test.ts against a throwaway local Postgres 18: 88 passed (all 381 cloud/test/core-* pass), including the MESSAGE spec keeping only the card's fields.
• Nearby suites, all passing: test-skills-ui-labels 12, test-runner-chat 13, test-shared-people 8, test-keys 51, test-computer-scope 19, test-runs-on-keys 4.
• All 140 scripts/test-*.mjs run on the branch before the merge:
  • 14 exit non-zero. 13 of them fail the same way on an untouched copy of main (same pass and fail counts).
  • test-compat-0032 greps the current lib/server/workspaces.ts for a showsAny line that main has already moved to lib/member-access, so it fails in any git checkout of main too.
• check-public.sh on HEAD: OK.

Not done or limits

• Deploy order:

  1. The orgo-web PR (runner read rows, approved_by_role, current_version.label) first.
  2. Then Bops Cloud, for the card field.
  3. Then this app release.

  Each piece falls back cleanly if it ships before the others. The page itself needs only orgo-web's existing skills routes.

• Phase 2 (Members with "Memory and skills") is not here.

• Not done (follow-ups):

  • Admin label structure: an Admin can't move a skill between labels or switch which bots have a label, and a skill that follows its label says so instead of showing bot switches.
  • Admins can't accept a bot's proposal from orgo-web.
  • The approver ("by owner" or "by an Admin") is kept on each approval but not shown.

• The runner reads only its own computer's workspace. A free Bops computer that also serves other workspaces' main bots keeps today's behaviour for those bots.

• Anyone with root on a bot's computer can read every published skill of its workspace. This was the owner's call while orgo-web keeps no label.

• Later change still wins: if the owner's Mac changes a skill after an Admin published it, the Mac's change wins on the next sync.

• An owner's Mac on 0.0.50 or older still overwrites unpublished folder work on a pull. It ignores Admin approvals, so a script stays blocked (fails closed) until the owner approves it too.

• Edits to a draft made on the Mac after it first reached Orgo still don't go to Orgo until it's published. This was already so; an Admin publishing that draft in Orgo publishes the first text.

• In the shared page, a file counts as a script by its executable bit, its folder or its kind of name. A file that is a script only because of its #! line shows as one once it's opened.