bitrise-signup - SKILL.md Agent Skill

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.