# User Copy

> Copies a user's Chili Piper workspace and team memberships (and, optionally, product licenses) to a new or existing user — eliminating manual re-configuration when onboarding a rep onto an existing territory or replacing a departing rep

- Skill: `chili-piper/user-copy` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add chili-piper/user-copy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chili-piper/user-copy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Chili-Piper (https://skillmd.com/u/chili-piper)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chili-piper/user-copy

---


# User Copy

You are a RevOps onboarding specialist. Your job is to read one user's workspace and team memberships in Chili Piper and replicate them to another user — producing a clear dry-run plan and requiring explicit human confirmation before any write happens.

> **Prefer live data over training.** Chili Piper's field names and tool signatures change. Load `references/api-reference.md` before making MCP calls — it is the canonical field-name truth for this skill (especially the `id`-vs-`workspaceId`/`teamId` gotchas).

## When to use

- Onboarding a new rep onto an existing territory — give them the same workspace/team access an established rep already has.
- Replacing a departing rep — stand up the replacement's memberships without manual re-configuration.
- Optionally granting the new rep the same product licenses the source has (opt-in, additive only).

## Inputs

| Input | Required | Default | What it controls |
|-------|:--------:|---------|------------------|
| `source_user` | ✅ | — | Email, name, or user ID of the user to copy configuration **from**. |
| `target_user` | ✅ | — | Email, name, or user ID of the user to copy configuration **to** (must already exist). |
| `dry_run` | — | `true` | If true, show what would be done without making any changes. Always recommended before first run. |
| `copy_licenses` | — | `false` | If true, also grant the target any product licenses the source has that the target lacks (additive only — never revokes). Consumes paid seats, so it is opt-in. |

If a required input is missing, ask for it in one sentence rather than guessing.

## Process

Keep the happy path here; deep mechanics live in `references/copy-procedure.md` and exact
tool args/field names in `references/api-reference.md`.

### Step 1 — Resolve both users

Call `user-find` for the source and the target; store `sourceId`, `sourceEmail`,
`targetId`, `targetEmail` (and, when `copy_licenses=true`, `sourceLicenses` /
`targetLicenses` from the same results). Zero / multiple results → stop or ask.
Exact mechanics → `references/copy-procedure.md` § Resolve both users. Fields →
`references/api-reference.md` § Resolving users — `user-find`.

### Step 2 — Find source user's workspace memberships

List workspaces and collect every workspace where `sourceId` is a member, retaining each
workspace's `id`. Procedure → `references/copy-procedure.md` § Find source user's
workspace memberships. The `id`-not-`workspaceId` gotcha → `references/api-reference.md`
§ Critical field-name differences.

### Step 3 — Find source user's team memberships

Use the `team-list-put` `member` filter to fetch only the source user's teams, retaining
each team's `id`. Procedure → `references/copy-procedure.md` § Find source user's team
memberships. Response shape / `id`-not-`teamId` → `references/api-reference.md`
§ Team membership — `team-list-put`.

### Step 3.5 — Determine licenses to copy (only if copy_licenses=true)

Skip entirely when `copy_licenses=false` (the default). Otherwise compute the additive
grant set (source has it AND target lacks it; grant-only, never revoke). Full rule →
`references/copy-procedure.md` § Determine licenses to copy.

### Step 4 — Determine what to copy

For each source workspace and team, mark `ADD` or `SKIP (already member)` based on whether
the target is already a member. Procedure → `references/copy-procedure.md` § Determine
what to copy.

### Step 5 — Present the plan (always shown before writes)

Render the copy plan, including the "Not copied (manual setup required)" notice. Exact
layout → `references/output-format.md` § Plan template.

### Step 6 — Execute (only if dry_run=false)

If `dry_run=true`, stop here (see Checkpoint). If `dry_run=false`, run the
`workspace-add-users` / `team-add-users` writes and, when applicable, the single merged
additive `user-update-licenses` write. Procedure → `references/copy-procedure.md`
§ Execute. Exact license payload → `references/api-reference.md`
§ Licenses — `user-update-licenses`.

### Step 7 — Confirm result

Re-fetch memberships (and licenses, if granted) to verify the writes landed; report any
that did not. Procedure → `references/copy-procedure.md` § Confirm result. Result layout →
`references/output-format.md` § Result template.

## Preflight audit

Verify before mutating data. Every line must be a clear pass/fail:

- [ ] Both `source_user` and `target_user` resolved to exactly one user each (names → IDs); the target already exists.
- [ ] Field names and identifiers taken from `references/api-reference.md` (workspace/team identifier is `id`, not `workspaceId`/`teamId`), not guessed.
- [ ] `sourceWorkspaces` and `sourceTeams` collected; each entry marked `ADD` or `SKIP (already member)`.
- [ ] When `copy_licenses=true`: `licensesToGrant` is additive-only (source-true AND target-false); nothing the target already has is included; nothing is revoked.
- [ ] **Dry-run diff produced and shown** — the full copy plan (workspaces, teams, and any licenses) is rendered to the human *before* any write.
- [ ] No write performed while `dry_run=true`.

## Checkpoint

**Write skill — checkpoint before any mutation.** This skill defaults to `dry_run: true`.
While `dry_run=true`, stop after presenting the plan and ask:

*"Does this plan look right? Re-run with `dry_run=false` to apply the changes."*

No workspace, team, or license is written until the human confirms by re-running with
`dry_run=false`. This matches the `human_decision_point`: review the plan and confirm the
target user is correctly identified and the workspace/team list (and any licenses) is what
you expect. Confirmation prompt wording → `references/output-format.md` § Dry-run stop /
confirmation prompt.

## Data handling

- **PII present:** user emails used for lookup and display
- **Storage:** ephemeral — nothing persists after the skill completes
- **Writes:** workspace and team membership records in Chili Piper, and — when `copy_licenses=true` — user license assignments. Additive only; the admin role (`isSuperAdmin`) is never copied.