bitrise-onboard-end-to-end

Bitrise End-to-End Onboarding (Orchestrator)

Drive the full Bitrise prospect journey in one session by orchestrating three sub-skills in order:

1. bitrise-signup — anonymous registration via the MCP, ending with a Bitrise PAT installed in the user's MCP config.
2. bitrise-ci-onboarding — register the user's app in Bitrise CI, connect the repo, set up signing credentials, trigger and watch the first build.
3. bitrise-release-management — register the app in Release Management, upload the build artifact, surface the public install page URL.

Each sub-skill works on its own. This skill is the connective tissue: it gathers shared context once, runs the stages in sequence, and hands state between them so the prospect doesn't have to repeat themselves.

Why this exists

The prospect wants one outcome: "I went from no account to a shareable install link." Composing three skills sequentially keeps each stage focused and testable, while this orchestrator hides the seam between them. Without it, the user would have to manually invoke each skill and repeat workspace slugs and app slugs across them.

Preconditions

• The user has the Bitrise MCP installed from the agentic-onboarding branch. The hosted endpoint at https://mcp.bitrise.io doesn't yet have the signup or signing-upload tools. If the user is on the hosted version, route them to local stdio install first: claude mcp add bitrise -- go run github.com/bitrise-io/bitrise-mcp/v2@agentic-onboarding. No BITRISE_TOKEN needed at startup; the signup flow installs one.
• The user is willing to do all three stages in one session. If they only want one stage, run that sub-skill directly.

Up-front context gathering

Before kicking off stage one, ask the user a few questions in one batch so the rest of the flow runs without interruptions. Don't ask them again later unless the answers don't apply.

1. Email for the Bitrise account (will receive an OTP).
2. Platform: iOS or Android (or Flutter / React Native — those route to platform-specific configs in stage 2).
3. Repo URL, public or private.
4. Git provider (GitHub, GitLab, Bitbucket, or self-hosted).
5. Default branch name (usually main).
6. Bundle ID / package name (you'll need this for stage 3; ask once, not three times).
7. App display name (also for stage 3).
8. Path to a signing artifact, if they have one ready: .p12 + .mobileprovision for iOS, or .jks/.keystore + alias + passwords for Android. If they don't have these and just want to see a green build, skip signing in stage 2 — the default Android config uses the debug keystore, and iOS can build & test without distribution signing.

Maintain these in a context dictionary you carry across the stages:

{
  email, platform, repo_url, is_public, provider, default_branch,
  bundle_id, store_app_name, signing_files: {...},
  // populated as we go:
  workspace_slug, api_token, app_slug, build_slug,
  connected_app_id, installable_artifact_id, public_install_url
}

Don't put api_token in any chat output. Hold it during the config update in stage 1, then drop it.

Stage 1: Signup

Run the bitrise-signup skill. Pass the email. When done, capture:

• workspace_slug (from verify_registration or list_workspaces)
• The PAT is installed in the MCP config — it's not in your context any more, by design

Confirm with me and list_workspaces before moving on. If signup fails (invalid email, expired OTP, MCP not reconnected), don't proceed to stage 2 — fix or stop.

Stage 2: CI onboarding and first build

Run the bitrise-ci-onboarding skill. Pass:

• workspace_slug from stage 1
• platform, repo_url, is_public, provider, default_branch, signing_files

Capture:

• app_slug
• build_slug of the first successful build

If the build fails, stop and surface the failure log with diagnosis. Don't roll into Release Management on a failed build — there's no artifact to publish.

Stage 3: Release Management public install page

Run the bitrise-release-management skill. Pass:

• workspace_slug
• app_slug
• platform
• bundle_id as store_app_id
• store_app_name
• build_slug (so the skill can pull the artifact from CI) OR a local artifact path if the user has one handy

Capture:

• connected_app_id
• installable_artifact_id
• The public install page URL

Final hand-off

When all three stages succeed, summarize for the user:

• Their account email + workspace slug
• Their app's Bitrise URL (https://app.bitrise.io/app/<app_slug>)
• The build URL of their first green build
• The public install page URL

Suggest a couple of natural next steps: invite teammates to the workspace (invite_member_to_workspace), set up Slack/email notifications, or send the install URL to a tester. Keep the suggestion short — the prospect just sat through three stages, give them air.

Failure recovery

Each stage has its own failure modes. The orchestrator's job is to fail loudly and helpfully:

• Signup failure: Don't continue. Tell the user what went wrong (invalid email, OTP expired, MCP not reconnected) and how to retry.
• CI failure: If register_app errored, fix the input and retry. If the first build failed, surface the failing step and don't move to stage 3. The build can be retried after a fix without redoing stage 1.
• Release Management failure: If processing fails (signing issue), stop and tell the user. Don't loop. The connected app and uploaded artifact persist, so a re-run from stage 3 with a fresh artifact can succeed without redoing 1 or 2.

Things to watch out for

• Don't ask the same question twice. The whole point of this skill is reusing context across stages. If you find yourself asking about the workspace slug in stage 3 after capturing it in stage 1, something's off.
• The PAT is installed in the MCP config, not in your context. After stage 1, you don't have the token any more — and that's correct. All subsequent tool calls authenticate via the MCP transport.
• Stage 1 requires a client reconnect. This is the one place where the user has to do something outside the chat (restart Claude or re-establish the MCP connection). Set the expectation up-front so it's not a surprise.
• A "demo" first build often doesn't need signing. If the user just wants to see the journey work, skip signing in stage 2 and run a test/build workflow. Save signing for when they're ready to ship a real artifact through Release Management.
• Total time: usually 15–30 minutes, dominated by the first build (5– 15 min) and any user latency on email/OTP. Set this expectation up-front.
• iOS install pages have a UDID gotcha. A dev-signed IPA only installs on devices in the provisioning profile. Mention this when handing the install URL over.