| name | bitrise-signup |
| description | Sign a brand-new prospect up to Bitrise from inside Claude using the Bitrise MCP server's anonymous registration tools. Use this whenever the user says things like "sign me up to Bitrise", "create my Bitrise account", "I want to try Bitrise", "start a Bitrise trial", or expresses interest in trying Bitrise but doesn't have an account yet. Also use as the first step when the user asks for end-to-end Bitrise onboarding. Do NOT use this skill if the user already has a Bitrise PAT configured — go straight to bitrise-ci-onboarding.
|
Bitrise Signup
Walk a prospect from "no Bitrise account" to "MCP authenticated and ready to
build". The Bitrise MCP server's agentic-onboarding branch exposes two
tools that run anonymously (no PAT required), and this skill drives them.
Why these instructions exist
Signup is special: it's the only flow where the MCP works without a PAT, and
it ends with the agent rewriting the user's MCP client config to install the
PAT it just received. That's a sharp edge — the rest of this skill is about
not slipping on it.
Preconditions
Before you start, verify the user has a working install of the Bitrise MCP
from the agentic-onboarding branch. The hosted endpoint at
https://mcp.bitrise.io runs main and does not yet have these tools.
Two install options work:
- Local stdio (recommended for the PoC):
claude mcp add bitrise -- go run github.com/bitrise-io/bitrise-mcp/v2@agentic-onboarding
Note: BITRISE_TOKEN does NOT need to be set yet. The new code lets stdio
start without a token; signup tools work anonymously, and the token is
installed afterwards.
- Local HTTP transport pointed at a self-hosted build of the branch.
Send no
Authorization header; the registration group runs without one.
If the user is connected to the hosted mcp.bitrise.io, stop and tell them
the signup tools aren't deployed there yet and ask them to switch to a local
install of the branch. Don't try to call register against a server that
doesn't have it — you'll get a "tool not found" error and confuse the user.
If the user mentions they already have a Bitrise account and just need to
hook up the MCP, skip signup entirely and ask them for their existing PAT
(generated at https://app.bitrise.io/me/account/security). This skill is
for net-new accounts.
The flow
1. Get the user's email
Ask the user which email address they want to register with. Don't assume
the email in the session metadata is the right one — they may want to use a
work email vs. a personal one. Confirm before sending.
2. Start signup
Call register with { "email": "<the email>" }. The response is:
{ "pending_signup_id": "<id>", "expires_at": "<iso8601>" }
A 6-digit OTP code is emailed to the user. Tell them to check their inbox
(including spam). Capture pending_signup_id — you'll need it next.
If the response is an error: surface the status and body to the user and
stop. Common cases: invalid email format (400), email already registered
(409 — the user may already have an account; offer to skip to PAT setup
instead). The error response is structured JSON like
{"status": 409, ...body fields...} — read the status field to branch.
3. Collect the OTP and verify
Ask the user to paste the OTP from the email. Then call:
verify_registration with { "pending_signup_id": "<from step 2>", "otp": "<6-digit code>" }.
The response is:
{
"user_slug": "<slug>",
"api_token": "<pat>",
"token_expires_at": "<iso8601>",
"workspace_slug": "<slug or omitted>"
}
The api_token is a real, live Bitrise Personal Access Token. Treat it as a
secret. Do NOT echo it back in a chat message, do NOT log it, do NOT save it
to a file the user can see. Hold it just long enough to install it (next
step), then drop it from anything you write down.
If the OTP is wrong or expired, the response is an error with the appropriate
status. Offer to re-send by calling register again with the same email.
4. Install the PAT into the MCP client
This is the only step that needs you to leave the MCP and edit
configuration. Two cases:
Stdio mode (most likely for the PoC):
The user's claude mcp add command needs the token in BITRISE_TOKEN. Tell
them you're going to remove and re-add the MCP server with the token wired
in. Then run, in the user's shell:
claude mcp remove bitrise
claude mcp add bitrise -e BITRISE_TOKEN=<api_token> -- go run github.com/bitrise-io/bitrise-mcp/v2@agentic-onboarding
HTTP mode:
Re-add with an Authorization: Bearer <api_token> header:
claude mcp remove bitrise
claude mcp add --transport http bitrise <url> -H "Authorization: Bearer <api_token>"
After the config update, the user must restart Claude (or otherwise
re-establish the MCP connection) for the new token to take effect. Tell them
this explicitly. Until they do, every tool except register /
verify_registration will fail with the auth error
missing Bitrise authentication: ....
5. Verify auth, surface the workspace
Once the user confirms they've reconnected, call me and list_workspaces
to confirm the PAT works. Show the user:
- Their account email and user slug (from
me)
- The workspace slug(s) returned by
list_workspaces — for a fresh signup
there will be exactly one, auto-created during registration
This confirms signup worked end-to-end and gives the user (and the next
skill) the workspace slug they'll need.
Hand-off to the next step
After this skill finishes, the prospect has:
- A Bitrise account (free 30-day Teams trial with 500 build credits — the
default for new signups)
- A working PAT installed in their MCP client
- A workspace slug
If the user invoked this skill as part of an end-to-end onboarding flow,
hand off to bitrise-ci-onboarding and pass the workspace slug along.
Things to watch out for
- Don't paste the PAT into chat. It's tempting to "show" the user what
was generated. Don't. The user can read it back from their MCP config if
they need to.
- OTPs expire. The
expires_at field on the register response tells
you when. If the user takes a long time to check email, the verify call
may fail — re-run register to get a fresh OTP.
- Don't pre-fill an email you scraped from the session metadata. Always
ask. The session email may be a work address the user doesn't want
associated with a personal Bitrise trial, or vice versa.
- The
workspace_slug on the verify response can be omitted. If it's
missing, fall back to list_workspaces after the PAT is installed.
- Don't assume HTTP vs. stdio. Ask which transport the user installed.
claude mcp list will show it; offer to run that for them if they're
unsure.
