Get started with Huddle: install the Claude Code plugin

1. Install the plugin

Every developer installs Huddle once, on their own machine. A settings file committed to the repo does not do it for them. You need:

Claude Code (opens in a new tab).
Node 22 or newer, and git.
On GitHub, the gh (opens in a new tab) command line, logged in with gh auth login. On GitLab, the glab (opens in a new tab) command line, logged in with glab auth login (add --hostname gitlab.example.com for a self-managed server).

Run this once in any terminal, then open a new Claude Code session:

claude plugin marketplace add SrProfessional/Huddle
claude plugin install huddle@huddle

In the Claude Code command line you can type the same as /plugin marketplace add SrProfessional/Huddle and /plugin install huddle@huddle. The VS Code extension uses /plugins instead of /plugin: type /plugins, add the marketplace SrProfessional/Huddle in the Marketplaces tab, install huddle from the Plugins tab with Install for this project (not «Install for you»), and type /reload-plugins (or restart Claude Code). Each person does this once per clone. Huddle has no runtime dependencies, so there is nothing to npm install.

To update later. Install and update are per project, so repeat this in each project that uses Huddle. From the project, type one command:

/huddle-update

It updates the plugin (claude plugin marketplace update huddle and claude plugin update huddle@huddle --scope project), refreshes the templates and the CLAUDE.md block in a branch of its own, asks only the questions a new release added, and opens the PR. It ends by telling you to type /reload-plugins; if the new skills do not show up, restart Claude Code. A project can be on an older version than another. /huddle-play and /huddle-update tell you in the chat when a newer release exists, at most once a day.

2. Set up your repo

This is the AI Manager's step, once per repo. Open Claude Code in the repo and create a branch for the setup:

git switch -c huddle-setup

Run /huddle-setup. It asks for the platform (GitHub or GitLab), the host (empty for github.com or gitlab.com), the project, the login of the AI Manager and the logins of the developers.
It writes huddle.json, the Issue and pull request templates, the job that keeps the labels up to date, and the Huddle block of CLAUDE.md. Nothing outside that block is touched.
Run huddle doctor. You want a check mark on the file, the login, the AI Manager and the labels. If a label is missing, run huddle labels once.
Commit, push and open a pull request with the setup files. Merge it. The AI Manager is the only one who merges.

On GitLab, two more steps are only the AI Manager's: a pipeline schedule with the cron */10 * * * * on the default branch, and a project access token with the api scope stored as the masked, protected CI variable HUDDLE_TOKEN. Labels can take up to ten minutes to change. The GitLab notes (opens in a new tab) explain both in detail.

3. Write the first Issue

Run /huddle-issue. It writes the Issue from the template, so every task arrives complete:

Part	What it says
Goal	What we want to achieve and why, in a few lines.
Prompt for Claude Code	The text the developer pastes, with the steps, the branch and how to open the pull request.
Allowed files	The only files the session may touch.
Forbidden files	What is not touched. If it must be, the session asks first.
Contract or spec	The document that rules over the code.
Tests	What must pass before the pull request opens.

4. A developer's first day

Set up your machine. Install Claude Code, Node, git and gh or glab, log in yourself, and install Huddle with the two commands above. Never paste a token into a chat, a file or an Issue.
Check it works. Clone the team's repo, open Claude Code in it and run huddle doctor. If labels fails, tell the AI Manager: only they run huddle labels.
Take an Issue. The AI Manager assigns one, or the labels job does. Run /huddle-play <n> with its number, or paste the Issue's prompt. The session checks what the Issue depends on, creates its own branch and adds the in progress label. If a dependency is not merged yet, it stops, and that is right.
Answer its questions. This is the job. If you do not know, say so and let the session ask the AI Manager.
Review what it did before you accept the pull request. You are responsible for it.

A session ends with a message that starts with «Issue #N finished» or «Issue #N stopped», with the pull request link, the test counts, what was not done and your next step. After the pull request opens, the session waits in the background and picks up the AI Manager's requested changes on its own.

Next: how it works, with the roles, the labels and the reviews.