# Specialist

> Organize workflows, apps, skills, and shared files into specialists. Sharing a specialist shares everything in it.

Source: https://docs.generalinput.com/cli/specialist



A specialist owns one body of work. Every workflow, app, and skill lives in exactly one specialist, and anyone with access to the specialist gets that access to what it holds. A specialist also keeps a **memory** (what it is for, how its work is done, what was decided) and **shared files**: reference material and deliverables that every conversation with the specialist can load into `specialist/`.

* [`geni specialist list`](/cli/specialist/list) lists the specialists you can access. Bare `geni specialist` does the same.
* [`geni specialist get`](/cli/specialist/get) shows one specialist and what it holds.
* [`geni specialist create`](/cli/specialist/create) and [`update`](/cli/specialist/update) manage the specialist itself, including its memory.
* [`geni specialist pin`](/cli/specialist/pin) moves a resource you own into a specialist.
* [`geni specialist delete`](/cli/specialist/delete) deletes a specialist you own. There is no undo.
* [`geni specialist files`](/cli/specialist/files) lists, pulls, pushes, and removes shared files.
* [Import, export and templates](/cli/specialist/transfer) moves whole specialists and manages reusable publications.
* [`geni sharing`](/cli/sharing) inspects, grants and revokes specialist access.

Every command takes the specialist id (`proj_…`). The alias `geni specialists` works too.

## Roles [#roles]

Your role on a specialist is `owner`, `editor`, `runner`, or `viewer`, resolved from the nearest grant. Reading needs any role, and a `runner` can also run the workflows it holds; changing the specialist, pinning into it, and pushing files need edit; deleting needs ownership. A resource-level grant beats the specialist's, so "editor on the specialist, viewer on one workflow" is a real state.