Run a Team

For individual users. This playbook covers the operational lifecycle of a
Temper team: creating one, bringing people in, managing their roles, sharing
your work, and offboarding a departing member.

By the end you will have created a team, added or invited its members at the
right roles, shared a context or granted a resource so the team can read your
work, and know how to reassign ownership when someone leaves.

Prerequisites

Temper installed — see Install Temper.

Authenticated — you have signed in and have a profile. Run temper auth status
to confirm.

Familiar with contexts and refs — team membership gates access to
contexts, and the sharing commands use
the ref grammar described there.

For the durable explanation of what a team is, the role ladder, nested teams,
and what membership grants (and does not), see
Teams and Roles. This playbook is the
how-to; that page is the why.

Create a team

You become its owner. Slugs are globally unique. Pass --parent <ref> to nest
the team under another — child teams inherit the parent's read reach while the
parent stays active.

List the teams you belong to, or inspect one:

show prints the roster — each member's profile UUID, handle, and role. This
is also the one place you can read a teammate's profile UUID, which you need
for the member commands below.

Bring people in

There are two ways someone joins, depending on whether they already have a
Temper profile.

Already have a profile: add them directly

If you know a person's profile UUID (from temper team show on a shared
team), add them straight away. add-member takes IDs, not slugs — the team
UUID is in temper team show acme-eng (or in the team create output), and
the profile UUID comes from team show's roster:

Not in the system yet: invite by email

Invite someone by the email they will sign in with:

This creates a pending invitation and prints it back — including a token.
Two things are worth understanding:

No email is sent. Temper doesn't run a mailer. The invited_email is not a
delivery address — it's how the invitation finds its way to the right profile once
that profile exists, and it decides who may redeem: only the account whose verified
email it is. The token on its own admits nobody else.

Signing in is self-serve. With OAuth/SAML, the newcomer just signs in and
a profile is provisioned automatically. They don't need the token handed to
them.

Once the newcomer has signed in, the invitation finds them. temper warmup — the primer
every session starts with — counts what is waiting on them:

"pending": { "invitations": 1, "join_requests": null, "review_requests": null }

Counts only; the detail is one command away. Two nulls at different levels mean different
things: pending: null means the block could not be read, while
pending.join_requests: null means the caller is not an instance admin and nothing was
read — as distinct from 0, which means an admin read an empty queue.

This closes the loop only for people who have already signed in. A brand-new human
still has to be told once, out of band — the invitation can only resolve to a profile that
exists. That is the same reason the invited_email is matched rather than mailed: nothing
here is outbound delivery.

They can also ask directly, at any time:

This lists every pending invitation addressed to their verified email —
team, role, and the redemption token — across all teams. They then accept:

…or decline: temper team decline <token>.

As the inviter, you can review a team's outstanding invitations any time:

Over MCP, the same loop is three tools, for anyone working through an agent without the
CLI. invitation_read answers count (the warmup-style number, with no tokens), mine (your
invitations and their tokens) and team (a team's pending invitations). invitation_manage
takes accept / decline with a token, and create / revoke for a team's owners and
maintainers; team_manage takes leave. They go through the same API routes and the same
checks as the commands above, and an agent should use them only when the person asks.

One edge to know about. temper invitations resolves an invitation to
you only when your email maps unambiguously to a single profile. In the rare
case where the same email is spread across more than one profile (which can
only happen with unverified sign-ins), the invitation is not auto-surfaced
— it stays safely invisible rather than risk showing up for the wrong
account. Sharing the printed token does not get around this: an invitation
can be accepted or declined only from the one account that verifiably owns
its email address, so the duplicate address has to be resolved first.

Manage membership

Update the team's metadata (owner or maintainer):

Membership alone doesn't share your resources — you grant access explicitly.
For what membership does and does not confer, see
Teams and Roles.

Sharing a whole context lets the team see everything homed in it:

The context argument takes a handle-qualified ref (@<handle>/<slug>) or a
context UUID. @me is not accepted here — use your own handle or the
context UUID. To find your handle, run temper context list and read the
owner_ref column.

The team argument takes a bare slug (acme-eng) or a +-prefixed slug
(+acme-eng).

Grant a single resource

Grant a single resource to a team at a specific capability:

Sharing grants the team read access. The only path to shared authorship is
transferring context ownership — see Contexts and Refs
for the model.

Offboarding

When someone leaves, reassign the work they owned in the team's shared contexts
to whoever picks it up:

This is an in-place ownership change over every resource --from owns that is
homed in a context shared to this team; --to must be a current member. It's a
single transaction — good for bulk offboarding. Provenance is untouched: the
original author stays recorded.

Reassignment is half of a departure. It moves the work, and
temper team remove-member ends what this team's share conferred — but neither
ends the person's admission to the instance, and anything they still own keeps
them as its owner, and its reader, until it is handed off. Ending admission is a
system-admin act on a different page: see
Offboard a Departure for the whole sequence, and for
why an IdP-side group removal is not the control it looks like.

Retire a team

Soft-delete (owner only). The team stops conferring any access immediately, its
children lose the inherited umbrella, but the slug stays reserved and the row is
preserved server-side. The root temper-system team cannot be deleted.

Prerequisites#

Create a team#

Bring people in#

Already have a profile: add them directly#

Not in the system yet: invite by email#

Manage membership#

Share work with a team#

Share a context#

Grant a single resource#

Offboarding#

Retire a team#

Further reading#