bitbucket-datacenter

---
name: bitbucket-datacenter
description: "Handle Bitbucket Data Center/Server PR operations. Use for \"PR\", \"pull request\", \"review\" when repo is on self-hosted Bitbucket (NOT bitbucket.org)."
---

# Bitbucket Data Center PR Operations

Use `mcp__plugin_bitbucket-datacenter-plugin__*` MCP tools.
## Platform Detection (REQUIRED)

Run `git remote -v` to verify this is Bitbucket Data Center (self-hosted, not bitbucket.org):
- SSH format: `git@bitbucket.company.com:7999/PROJ/repo.git`
- HTTPS format: `https://bitbucket.company.com/scm/PROJ/repo.git`
- Extract: workspace = `PROJ`, repository = `repo`

## Status Indicators

When listing or displaying PRs, use these status emojis based on PR state:

| Condition | Status |
|-----------|--------|
| `is_draft === true` | 📝 Draft |
| `state === "MERGED"` | 🔀 Merged |
| `state === "DECLINED"` | ❌ Declined |
| `state === "OPEN"` | ✅ Open |

## Output Format

**Do not use a markdown table.** Cursor CLI table cells expand `[label](url)` into `label (url)` and wrap the URL in the cell.

Default listing: **open, non-draft** PRs unless the user asks for drafts or all states.

Each PR is a card of four consecutive lines — **no heading and no blockquote**. A markdown heading adds a bottom margin that separates line 1 from line 2, and Cursor CLI's parser is line-based, so a `>` line renders as dim italic text with any `####` left literal.

1. **PR # with link, plus branch as plain code** — `**PR [131](web_url) · \`source_branch\`**`, bold text. Never link the title or the branch. Cursor CLI always prints the destination URL after a markdown link; that suffix cannot be hidden.
2. **PR Title** — bold, on its own line
3. **Status · Date · Author** — status icon, then full date with year (`9/17/2026`)
4. **Description** — body text, or `_No description provided_`

Status icons only; no other emoji in the card.

End lines 1–3 with **two trailing spaces** (markdown hard break) so all four lines stay in one tight block. Without them Cursor Desktop joins them into one paragraph.

**Order:** flat list, no grouping. Sort by status (Open, then Draft, then any other state), and by date descending within each status.

Example (`␣␣` marks the required trailing spaces):

```markdown
**PR [131](https://git.example.com/projects/PROJ/repos/repo/pull-requests/131) · `feature-branch`**␣␣
**Event-driven index refresh**␣␣
✅ Open · 9/17/2026 · alice␣␣
_No description provided_
```

**Clicks:** inside Herdr, Ctrl+click the number (plain click is Herdr mouse UI). In a plain WezTerm pane, left-click opens the OSC 8 link on the number.

## PR Review

When reviewing a PR:
1. Fetch PR details and diff
2. Analyze for bugs, security issues, performance, and code quality
3. Present findings as: `## PR Review: #<NUM> - <TITLE>`
4. List issues with file references: `file_path:line_number`
5. Provide verdict: APPROVE, REQUEST_CHANGES, or COMMENT
6. Post comments/approve via MCP tools if requested