Feature: Add Configurable GitLab Support to `ce-babysit-pr`

[Yaduttam95]

Problem

/ce-babysit-pr is currently GitHub-only and exits when the repository remote is GitLab.

This makes the skill unavailable for teams using GitLab merge requests, even though the core workflow appears applicable to GitLab as well.

The current documentation also mentions that GitLab support is mappable in principle using glab, merge requests, discussions, pipelines, and detailed_merge_status.

Proposed Approach

Add GitLab support incrementally while keeping platform-specific logic isolated behind the existing platform seam.

Rather than implementing the complete GitLab workflow in a single change, the work could be split into smaller MRs.

Phase 1: Review Feedback

The first implementation would focus on the review feedback workflow:

1. Detect GitLab repositories and use glab
2. Add GitLab implementations for the pr-snapshot fetch / fetch_threads layer
3. Support GitLab MR discussions and resolution state in ce-resolve-pr-feedback
4. Allow /ce-babysit-pr to watch for and handle actionable review feedback on GitLab MRs

This would provide the core workflow:

Watch MR
  ↓
New actionable review feedback
  ↓
Delegate to ce-resolve-pr-feedback
  ↓
Apply fix / reply / resolve discussion
  ↓
Continue watching

Phase 2: CI/CD and Pipeline Handling

A follow-up MR could add GitLab pipeline support, including:

1. Mapping GitLab pipeline and job status to the CI state consumed by ce-babysit-pr
2. Handling pipeline failures
3. Retrying transient failures where appropriate
4. Delegating genuine failures to ce-debug

Phase 3: Branch and Merge State

Further support could include:

1. Detecting when the target branch has moved
2. Mapping GitLab mergeability and MR state, such as detailed_merge_status
3. Integrating branch maintenance into the babysitting workflow

Configurable Workflow

Ideally, the different parts of the babysitting workflow should be independently configurable.

For example, users could choose to babysit:

• Review comments only
• CI/CD only
• Branch/merge state only
• Any combination of the above
• The complete workflow

This would allow users to enable only the behavior they need. For example, someone who only wants automatic handling of incoming review comments would not need to enable CI/CD monitoring, while another user could use the skill primarily to monitor and handle pipeline failures.

The higher-level babysitting loop could remain platform-agnostic where possible, with GitHub and GitLab implementations providing the required platform-specific state and actions.

Potential Platform Equivalents

GitHub	GitLab
Pull Request	Merge Request
gh	glab
Review threads	MR discussions / resolvable threads
GitHub Actions	Pipelines
PR merge state	detailed_merge_status / MR state

Questions

Before starting implementation, I would like to understand whether GitLab support is something the project would want to accept and whether this incremental approach aligns with the intended architecture.

In particular:

• Does splitting the implementation into separate MRs for review feedback, CI/CD, and branch/merge state make sense?
• Should these babysitting capabilities be independently configurable, allowing users to enable only comments, only CI/CD, or any combination?
• Is the proposed platform abstraction direction aligned with the project?
• Is there an existing abstraction or architectural direction planned for supporting multiple git hosting providers?

I am interested in working on this if the maintainers are open to the approach. I may not be able to start immediately, but if nobody else picks it up, I would be happy to start working on the initial review feedback support in the coming weeks.

[tmchow]

GitLab support is something we would want, with a hard constraint: a GitHub-only run must not load GitLab (or a generic forge framework) into context all the time.

ce-babysit-pr just went through a 90KB -> 8KB split so the always-loaded kernel stays under the prompt budget. Dual-writing gh/glab into SKILL.md or tick.md, or making the three streams independently configurable, undoes that. GitHub users would pay for GitLab on every babysit.

There is also no existing platform seam to plug into. GitHub Enterprise is still GitHub (gh --hostname). pr-snapshot and ce-resolve-pr-feedback are GitHub GraphQL/gh. The seam to add is:

• Keep the kernel’s conditions (three streams, comments-before-CI, settle, envelope).
• Detect forge once. GitHub continues on the current path. GitLab loads references/gitlab.md and uses a GitLab fetch in pr-snapshot that still emits the same attention-set schema. Other forges keep the current stop.
• Do not put glab recipes, discussion mapping, or pipeline retry in the always-loaded body.

Answers to your Qs:

• Phased MRs. Splitting the work is fine but shipping a comments-only GitLab babysit isn't. The skill exists to run comments, CI, and currency together and explicitly refuses to half-run on an unsupported forge. Minimum GitLab babysit is comments + CI, and ce-resolve-pr-feedback GitLab discussions have to land in the same ship as the comments stream (this skill delegates, it MUST not reimplement). Branch currency can lag if GitLab need_rebase is parked as needs-human rather than auto-rebased.
• Independently configurable streams. No. That is a diff't product, and it explodes the kernel of the skills. Comments-only is ce-resolve-pr-feedback. CI-only is ce-debug. If those skills need GitLab, that is the right place, not flags on babysit.
• Platform abstraction. Yes in the helper and a GitLab-only reference. Not as an always-loaded “forge-agnostic” rewrite of the skill, and not as a generic multi provider framework.
• Existing multi-forge plan. nope. GitLab is a second concrete adapter, not Bitbucket-ready infrastructure.

2 GitLab mappings that must not be 1:1:

• need_rebase is not GitHub BEHIND + update-branch. This skill’s envelope forbids rebase and force-push.
• Stack posture (gh stack, stack-ready / stack-land) stays GitHub-only until a GitLab manager can prove membership the same way we require manager_status == "confirmed".

If you still want to take this, a first PR I would suggested attempting is: GitLab detect -> load references/gitlab.md, pr-snapshot GitLab fetch behind the existing snapshot schema, ce-resolve-pr-feedback discussions, babysit still stops unless comments and CI both work. No stream-config flags, no kernel dual-write.