Enterprise quickstart
This page is for the team that brings stamity into a company on a private fork. It puts the steps in order, by day and by role, and sends you to the guide that owns each one.
It repeats no commands. Each step is one sentence, and its link is the section of the guide that has the commands. The links go to the page, so find the section by its name there.
Who does what
| Role | What they own |
|---|---|
| Admin | The prerequisites, the Actions and branch controls, and the rollout of the plugin to every developer's client. |
| Platform team | The fork, its identity and its releases, and the catalog repository developers install from. |
| Developers | Installing the plugin, setting each repository up, and staying on the version the platform team pins. |
Day 0: make the fork
The admin and the platform team do this once.
- Check the plan, the access and the network routes before anything else, as Check the prerequisites before you import lists.
- Copy the upstream history into a new private repository with Actions turned off, by following Import the history into a private repository.
- Give the private package its own name, repository and publisher with one command, from Set the private package's identity.
- Point the update lane at the upstream and name your integration branch in Configure
.stamity/upstream.json. - Turn Actions back on last, once your changes are committed and your branch checks match your integration branch, as Turn the workflows on last explains.
Day 1: release and roll out
The platform team releases first, then the admin rolls out, then every developer installs.
- Arm the release workflow and push your first version tag, as Release your fork shows.
- Publish your customized content as a package your other repositories install, through Ship your fork through APM.
- Declare the marketplace, allow only that one, and mark the plugin on in every developer's Claude Code with the managed-settings file from Roll the plugin out to your organization.
- Open Claude Code once on each machine, finish its first-run screens, and then install the plugin, as Start Claude Code once on each machine explains.
- Install the plugin in every other client, or find that client's organization route, under Install.
- Give each repository its charter and manifest with the one setup command in Set the repository up.
Day 2: take updates
The platform team runs the update lane, and developers follow the version it pins.
- See what the next upstream release touches and merge it on an update branch, as Take the next release shows.
- Fix a merge conflict in the lane's own worktree rather than in your checkout, by following Resolve a conflict.
- Land the update with a merge commit so the next update still finds its base, as Land the update branch explains.
- Undo an attempt, or a release you already landed, with Back out an attempt or a landed release.
- Move developers to the new version, or back to the old one, client by client in Pin, update, roll back.
- Keep a repository that also depends on the package on the same engine as its plugin, as Keep the runtime in step describes.
- Serve the release from your own catalog repository, where Renovate opens a pull request you review for each new version, through Private catalogs and Renovate.
Where to go next
- Enterprise forks — the whole fork guide, including the fork layer that keeps your changes out of upstream's way.
- Plugins — every client's install, pin and rollback, and which files the plugin carries.
- Customization — changing what the agents, rules, commands and skills say, before you reach for the fork layer.
- Packs and trust — shipping extra content behind a signature and an org policy.