Slipstream

Stack smarter, merge safer.

Comment

Slipstream 🏎️

Stack smarter, merge safer.

Inspiration

Every developer has felt the pain of stacked pull requests gone wrong.

You're building a feature that naturally breaks into dependent parts: Part A β†’ Part B β†’ Part C. You could wait for Part A to be reviewed before starting Part B, but that wastes precious productivity. So you stack your PRsβ€”working ahead while reviews happen in parallel.

Then disaster strikes: someone merges Part B before Part A, and suddenly main is broken.

This exact scenario happened to our team one too many times. We searched for solutions and found that tools like Graphite and ghstack exist for GitHub, but Bitbucket Cloud teams were left behind.

We asked: What if Bitbucket could natively understand PR dependencies and enforce merge order?

That's how Slipstream was born.

What it does

Slipstream brings intelligent stacked pull request management to Bitbucket Cloud:

πŸ”— Stack Creation via Comments

@slipstream stack start        β†’ Creates a new stack
@slipstream stack child-of 5   β†’ Links PR as child of PR #5

πŸ›‘ Merge Order Enforcement

  • Automatically detects when a PR's parent hasn't been merged
  • Shows 🚫 BLOCKED warning directly in the PR panel
  • On Premium plans, can hard-block the merge button

πŸ‘€ Visual Stack Panel

A Custom UI panel in every PR sidebar showing:

  • Complete stack order (numbered list)
  • Current PR highlighted
  • Parent PR status
  • Merge readiness indicator

πŸ€– Rovo AI Assistant

The "Slipstream Pit Engineer" answers questions like:

  • "Why is my PR blocked?"
  • "Which PR should I merge first?"
  • "What's the status of my stack?"

How we built it

100% Atlassian Forge β€” no external servers, bots, or polling.

Component Technology
Runtime Node.js 22.x on Forge
Frontend React 18 + Vite 7 (Custom UI)
Storage Forge Storage API
AI Atlassian Rovo Agent
Merge Control bitbucket:mergeCheck module

Architecture

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚           Bitbucket Pull Request            β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  Custom UI Panel    β”‚  Forge Resolver       β”‚
β”‚  (React + Vite)     β”‚  (Node.js 22)         β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  Comment Triggers   β”‚  Merge Check Handler  β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚        Forge Storage (Stack Graph)          β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Key Implementation Details

Stack Graph Storage: Each PR link stored as:

{ parentId: "pr-3", stackRoot: "pr-1", createdAt: timestamp }

Merge Readiness Check: \( \text{canMerge}(PR) = \forall p \in \text{parents}(PR): \text{isMerged}(p) \)

Challenges we ran into

1. Merge Check Enforcement on Free Plans

Bitbucket Free tier only supports merge checks as warnings, not hard blocks. We pivoted to prominent visual warnings with dramatic stylingβ€”the social pressure works surprisingly well.

2. Circular Dependency Detection

We had to implement cycle detection before linking PRs:

function wouldCreateCycle(childId, newParentId, stackData) {
  let current = newParentId;
  while (current) {
    if (current === childId) return true; // Cycle!
    current = stackData[current]?.parentId;
  }
  return false;
}

3. Rovo Action Context

Rovo actions don't automatically know which PR the user is asking about. We require explicit PR ID input and handle graceful prompting when missing.

4. Cross-Repository Stacks

Users wanted stacks spanning multiple repos. We scoped to single-repo for the hackathonβ€”cross-repo requires workspace-level storage and complex permissions.

Accomplishments that we're proud of

βœ… Zero external infrastructure β€” Everything runs on Forge, no servers to maintain

βœ… Native UX β€” The Custom UI panel feels like a built-in Bitbucket feature

βœ… Comment-based workflow β€” No learning curve, just @slipstream in a comment

βœ… AI integration β€” Rovo agent provides instant, contextual explanations

βœ… Graph-based architecture β€” Clean DAG model handles complex stacks elegantly

βœ… Real-world testing β€” We used Slipstream to build Slipstream (dogfooding!)

What we learned

Forge is Powerful

The platform handles auth, hosting, and storageβ€”we focused purely on logic. Custom UI with React felt natural.

Graph Theory Applies Everywhere

A PR stack is a DAG. Merge readiness = ancestor traversal. Stack order = topological sort. Thinking in graphs simplified our code.

AI as Documentation

The Rovo agent became living documentation. Instead of reading READMEs, developers just ask "why is this blocked?" and get contextual answers.

UX Matters More Than Enforcement

On Free plans without hard blocks, visual warnings alone reduced out-of-order merges to zero. Good UX > forced restrictions.

What's next for Slipstream

πŸ”œ Cross-repository stacks β€” For monorepo-adjacent workflows

πŸ”œ Slack/Teams notifications β€” Alert when parent merges and child is unblocked

πŸ”œ Auto-rebase suggestions β€” Detect when child branches need rebasing

πŸ”œ Analytics dashboard β€” Track stack health across the organization

οΏ½ Bitbucket Pipelines integration β€” Auto-trigger child PR builds after parent merge

Slipstream
Stack smarter. Merge safer. Ship faster.

Built with ❀️ for the Atlassian Hackathon

Share this project:

Updates