bitbucket

Bitbucket Integration

Overview

Bitbucket code repository integration for managing repositories, branches, pull requests, issues, and CI/CD pipelines. Connected account: {display_name} Use bitbucket_repos(action='list_repos', workspace='WS') or bitbucket_repos(action='list_workspaces') to discover connected repos. Workspace and repository auto-resolve from saved user selection if not passed explicitly.

Instructions

Tools (6 tools, 44 actions)

bitbucket_repos -- Repository, File & Code Operations:

• list_repos, get_repo, get_file_contents, find_in_file, edit_file, create_or_update_file, delete_file
• get_directory_tree, search_code, list_workspaces, get_workspace

bitbucket_branches -- Branch & Commit Operations:

• list_branches, create_branch, delete_branch, list_commits, get_commit, get_diff, compare

bitbucket_pull_requests -- Pull Request Operations:

• list_prs, get_pr, create_pr, update_pr, merge_pr, approve_pr, unapprove_pr, decline_pr
• list_pr_comments, add_pr_comment, get_pr_diff, get_pr_activity

bitbucket_issues -- Issue Operations:

• list_issues, get_issue, create_issue, update_issue, list_issue_comments, add_issue_comment

bitbucket_pipelines -- CI/CD Pipeline Operations:

• list_pipelines, get_pipeline, trigger_pipeline, stop_pipeline
• list_pipeline_steps, get_step_log, get_pipeline_step

Reading & Editing Repo Files

• Prefer edit_file (anchored search-and-replace applied server-side against the true current file) for ANY change to an existing file. Use create_or_update_file ONLY for brand-new paths — never to overwrite a file you already read via a full-content upload.
• First read the file with get_file_contents and copy old_string byte-for-byte from the output. Keep old_string narrow — the changed lines plus 1-3 lines of surrounding context. Do NOT pass the whole file as old_string.
• Large files come back in verbatim pages. The page header says [lines X-Y of N — pass start_line=<n> commit=<sha> to continue] (or start_char=<offset> for one oversized line) — follow it verbatim to read further; the commit=<sha> pin keeps every page on the same file version even if the branch moves. Every page is exact file content, never a summary.
• Big-file workflow: find_in_file (locate the lines to change, returns L<line>: <text> matches plus the resolved commit) → get_file_contents with start_line=<match line> and that commit (read that region verbatim) → edit_file with narrow anchors. You do not need the whole file in context to edit it. find_in_file matches your query as a literal substring first, then as a regex.
• One edit_file call can carry several edits (scattered locations = one commit); multiple files = multiple edit_file calls on the same branch = one PR.
• A comments-only config file is never a valid change. To remove a resource, delete its block; to change a value, edit it — do not replace file contents with a comment.
• During Aurora Actions / interactive chat: create a branch, apply edit_file on that branch, then open a PR. During background RCA: repo tools are read-only — use bitbucket_fix to propose changes instead.