Onboarding builders

Ask Claude, once you’re signed in as Ops through the sprig connector or Claude Code: “Add bea@corp as a builder.” This calls onboard_builder, which adds them to the platform’s builder group (the group the gateway checks on every sign-in) and confirms what the builder should do next. They need no CLI or resource group. A Claude tenant administrator uploads the current Builder and diagnostic skills from Admin > Setup > Skills; the builder does not install them individually. See Builder setup. Their first message that needs Sprig sends them through a normal Microsoft sign-in.

offboard_builder reverses it: builder access is removed immediately, their apps are never deleted, and you get an explicit offer to reassign ownership of anything they still own (either in the same call, or as a follow-up once you know who should take over).

Scripting it from the CLI

The same actions are available from the sprig CLI, so you can script onboarding (a joiner feed, a batch import, or the very first install before the connector is configured) instead of asking Claude one builder at a time. The CLI signs you in as an operator with a normal Microsoft sign-in and remembers you for later runs:

sprig builders onboard bea@corp
sprig builders offboard sam@corp --reassign-to bea@corp

The first command that needs authentication starts device-code sign-in when no cached session exists. Onboarding requires the Ops role and performs the same group update as onboard_builder, with no per-builder resource group.

Offboarding

Prefer offboard_builder (or sprig builders offboard <upn>): either way it is immediate, keeps the builder’s apps and audit history intact, and offers ownership reassignment in the same call (--reassign-to <upn> on the CLI).