Creating Merge Requests From Telegram — One Message, Full CI Pipeline

The Problem

Creating a merge request should take 30 seconds. It doesn't.

You open GitLab. You pick the source branch. You pick the target. You write a title. Then a description — what changed, why, what to test. You add labels. You assign reviewers. You wait for CI to kick off. You check back later.

That's 5-10 minutes if you're fast. And it's 5-10 minutes of pure context switching — you were deep in code, now you're filling out a form. Multiply by 8-12 MRs per week across our team. That's over an hour a week. Gone.

I have 31 agents running at PyratzLabs. They exist precisely so I don't spend time on things that follow patterns. MR creation is a pattern.

The Solution

Thom — our lead developer agent — handles merge requests through a single Telegram message. The command is natural language. The output is a production-grade MR with everything filled in.

The flow: I send a message. Thom creates the MR. CI runs. If it passes, Nico (our code review agent) gets pinged. If it fails, Thom shows me the error and suggests a fix. I never open GitLab.

The Process

The interaction looks like this in Telegram:

Me: @thom merge feature/auth into main

Thom: ✅ MR created: !142 — "Add JWT authentication middleware"
  📝 Description: 3 commits summarized
  🏷 Labels: backend, auth, security
  🔄 CI pipeline running...

Under the hood, Thom runs a sequence through the GitLab CLI:

# Extract commit messages for the description
git log main..feature/auth --pretty=format:"- %s" > /tmp/mr_desc.md

# Detect changed files to auto-label
changed_files=$(git diff --name-only main..feature/auth)
labels=""
echo "$changed_files" | grep -q "frontend/" && labels="$labels,frontend"
echo "$changed_files" | grep -q "api/" && labels="$labels,backend"
echo "$changed_files" | grep -q "auth\|security" && labels="$labels,security"

# Create the merge request
glab mr create \
  --source-branch feature/auth \
  --target-branch main \
  --title "Add JWT authentication middleware" \
  --description "$(cat /tmp/mr_desc.md)" \
  --label "${labels#,}" \
  --assignee bea7892046

The title generation is smart. It doesn't just use the branch name — it reads the commit messages and generates a human-readable title. feature/auth becomes "Add JWT authentication middleware" because that's what the commits describe.

CI triggers automatically on MR creation. Thom monitors the pipeline:

# Watch pipeline status
pipeline_id=$(glab ci list --per-page 1 -o json | jq '.[0].id')
glab ci view "$pipeline_id" --web=false

The pipeline runs four stages — lint, test, build, deploy preview. Each status update flows back to Telegram:

Thom: 🔄 Pipeline #891 — lint ✅ | test ✅ | build ⏳ | deploy ⏳
Thom: ✅ Pipeline #891 passed. Preview: https://preview-142.pyratzlabs.dev
Thom: 👀 Pinging @nico for code review.

If CI fails:

Thom: ❌ Pipeline #891 failed at "test" stage
  Job: test-unit — exit code 1
  Error: AssertionError in test_auth_middleware.py:47
  💡 Suggestion: Token expiry check expects UTC but receives local time.
     See commit a3f2c1 where timezone handling changed.

The Results

Try It Yourself

This works with any GitLab instance and the glab CLI. The core pattern: parse branch names, extract commit messages, detect file categories for labels, and wire CI status back to your chat platform. Mr.Chief makes the orchestration simple — one skill config, one agent, one message.

15 seconds. That's the real cost of a merge request now.