Your AI assistant can now have built-in knowledge of Bitrise CI. Install the using-bitrise-ci skill once, and the LLM of your choice will understand Bitrise conventions, configuration structure, step versioning, pipeline architecture, and best practices (without you having to explain them).
The problem
AI assistants are general-purpose. They know a little about everything, which means they guess at the specifics. With Bitrise, the specifics matter: step version pinning conventions, the difference between pipelines and stages, using step bundles instead of before_run, how triggers are structured in the new format versus the old trigger_map, and more. Get these wrong, and your config may look plausible but fail at runtime (or perform poorly).
The MCP server enables LLMs to call Bitrise APIs. But ability without knowledge still produces mistakes. The agent skill adds the knowledge layer so your LLM knows not just how to interact with Bitrise, but how to do it correctly.
How it works
Follow the installation instructions here - GitHub - bitrise-io/agent-skills: Collection of agent skills published by Bitrise
Once installed in your AI environment, the skill loads automatically whenever a conversation involves Bitrise CI, or you can invoke it explicitly with /using-bitrise-ci in Claude.
What your AI assistant now knows (some examples)
Configuration structure – The correct format_version, required meta.bitrise.io.stack fields, how to structure app, step_bundles, workflows, pipelines, and triggers sections.
Step best practices – Prefer official steps. Use script@1 when no dedicated step exists. Lock to major versions (git-clone@8, not git-clone). Use run_if expressions for conditional execution.
Pipeline architecture – Use explicit depends_on relationships for new pipelines. Reserve legacy stages only when editing existing configs that already use them.
Step bundles over duplication – Extract repeated step sequences into step bundles instead of using the deprecated before_run/after_run pattern.
Validation before deployment – The assistant will always validate a configuration before handing it to you. It uses the MCP validation tool, the CLI (bitrise validate -c bitrise.yml), or the API—and will not proceed if validation fails.
Trigger formats – Use the new per-workflow trigger format in new files. Preserve the existing trigger_map in configs that already use it.
Security – Secrets belong in the Bitrise web UI for cloud builds. The assistant will never suggest committing .bitrise.secrets.yml.
When to use it
Writing new configurations – Describe what your project needs. The assistant designs the pipeline, picks the right steps, structures the YAML correctly, and validates before delivery.
Refactoring existing configs – Share your current bitrise.yml. The assistant identifies structural issues, deprecated patterns, and opportunities to reduce duplication with step bundles.
Troubleshooting build failures – Paste your build log. The assistant reads through the failing steps, distinguishes configuration problems from source problems, and suggests targeted fixes without touching unrelated parts of the config.
Setting up a new app – The assistant walks through the full checklist: verifying the default branch exists, registering the app, handling SSH keys for private repos, completing app setup, and validating the initial config.
Understanding someone else’s config – Ask the assistant to explain a workflow or pipeline. It translates Bitrise-specific concepts into plain language.
Example usage
You: "Our iOS build workflow is running too slow.
Here's our bitrise.yml—what would you change?"
