Skip to main content

bitrise-signup

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-io/agentic-onboarding
آخر نشاط في المصدر
٧ مايو ٢٠٢٦ في ٠٩:٥٢
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٠
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
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: ```json { "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: ```json { "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.
عرض على GitHub