GitLab Slash Commands for Claude Code

I’ve been using Claude Code as my daily driver for development work on a self-hosted GitLab instance. One of its best features is slash commands — custom prompts that you can invoke with /command from the CLI. I’ve built a set of GitLab-focused commands that have become muscle memory.

Here’s what I’m running and why they’ve been useful.

How slash commands work

Claude Code supports two types of custom commands:

• Global skills (~/.claude/skills/<name>/SKILL.md) — available across all projects. These teach Claude how to use a tool.
• Project commands (.claude/commands/<name>.md) — scoped to a repo. These define what to do when invoked.

When you type /commit in Claude Code, it reads the matching .claude/commands/commit.md file and executes it as a prompt. You can pass arguments too — /commit fix typo in readme uses that as the commit message.

The GitLab CLI skill

First, the foundation. I have a global skill at ~/.claude/skills/gitlab-cli/SKILL.md that teaches Claude how to use glab (the GitLab CLI). It covers authentication, cross-project operations, CI/CD variables, issues, merge requests, pipelines, and releases.

The key parts:

---
name: gitlab-cli
description: Manage GitLab issues, merge requests, pipelines,
  CI/CD variables, releases, and project settings using glab CLI.
---

## GitLab CLI (glab) Operations

Use `glab` CLI for all GitLab interactions.

### Issues
glab issue create --title "Title" --description "Body" --label "bug"
glab issue list --search "keyword"
glab issue note 1 --message "Resolved in commit abc123"
glab issue close 1

### Known Gotchas
- `glab issue close -c "message"` does NOT exist
  — use `glab issue note` then `glab issue close` separately
- `glab variable set` overwrites existing variables silently
- Protected variables only inject on protected branches

The gotchas section is critical. Without it, Claude will confidently try glab issue close -c "message" which doesn’t exist. Documenting failure modes in skills saves you from watching the same mistake repeat.

/commit — stage, commit, and push

The most-used command. Type /commit and it:

1. Runs git status and git diff to understand the changes
2. Reads git log --oneline -5 to match the existing commit style
3. Stages specific files (not git add -A — avoids accidentally committing secrets)
4. Writes a commit message derived from the diff
5. Pushes to the remote

Commit all current changes and push to the remote repository.

Use a Bash subagent (via the Task tool with subagent_type="Bash") to:

1. Run `git status` to see all changed/untracked files
2. Run `git diff` to review the changes
3. Run `git log --oneline -5` to see recent commit message style
4. Stage the relevant files (prefer specific filenames over `git add -A`)
5. Write a concise commit message that follows the existing style
6. Commit with the message ending with:
   `Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>`
7. Push to the remote

If arguments are provided, use them as the commit message: $ARGUMENTS
If no arguments, derive the message from the diff.

Do NOT commit .env files or anything containing secrets.

The $ARGUMENTS variable is the magic — /commit fix typo passes “fix typo” as the commit message. Without arguments, Claude reads the diff and writes one.

The Co-Authored-By trailer is important for attribution. When you look at git log, you can see which commits had AI assistance.

Why a Bash subagent?

The command delegates to a Bash subagent rather than running git commands directly. This is a Claude Code pattern — subagents run in their own context and return a summary. It keeps the main conversation clean and avoids cluttering your context window with raw diff output.

/issue — file a bug report

Create a GitLab bug report issue for this project.

Use the gitlab-manager agent to create a bug report issue.

If arguments are provided, use them as the bug description: $ARGUMENTS
If no arguments, ask the user what bug they want to report.

The issue should follow this structure:
- Title: concise, descriptive
- Label: `bug`
- Body format:

## Summary
Brief description of the bug.

## Steps to Reproduce
1. Step 1

## Expected Behaviour
What should happen.

## Actual Behaviour
What actually happens.

## Impact
How this affects users or system behaviour.

Usage: /issue security alerts triggering on Docker internal IPs

Claude reads the codebase context, writes a properly structured issue with the right label, and returns the URL. The structured template means issues are consistent whether I write them or Claude does.

/feature — request a feature

Same pattern as /issue but with enhancement label and a different template:

Create a GitLab feature request issue for this project.

The issue should follow this structure:
- Title: concise, imperative
- Label: `enhancement`
- Body format:

## Summary
1-3 sentences describing the feature.

## Motivation
Why this is needed / what problem it solves.

## Proposed Solution
How it should work at a high level.

## Acceptance Criteria
- [ ] Checklist of what "done" looks like

Usage: /feature add strategy matrix to email digest

/document — generate project docs

This one delegates to a doc-generator subagent that writes AsciiDoc:

Generate or update AsciiDoc documentation for the TurfOps.run project.

Use the doc-generator subagent to create/update structured
technical documentation in ./docs/.

If arguments are provided, focus on: $ARGUMENTS
If no arguments, update documentation for any recent changes.

Requirements:
- Australian/British English spelling
- Proper AsciiDoc hierarchy with cross-references
- Code examples with language highlighting

I use this after implementing a feature to generate discussion documents or architecture notes. The subagent reads the code, understands the changes, and writes structured docs.

The workflow in practice

A typical development session looks like this:

> /feature add strategy matrix to email digest
  → Creates GitLab issue #16 with structured description

> [implement the feature across 4 files]

> /commit
  → Stages files, writes "Add strategy matrix email digest",
    pushes to main

> close gitlab issue 16
  → Comments with implementation summary, closes issue

The overhead of project management drops to almost nothing. Issues get created with consistent structure, commits reference what changed, and issues get closed with context about what was actually implemented.

Tips for writing your own

1. Be explicit about what NOT to do. The /commit command says “Do NOT commit .env files.” Without this, Claude will happily stage your secrets.

2. Use $ARGUMENTS for flexibility. Commands that accept optional arguments are much more useful than rigid ones.

3. Document tool gotchas in skills, not commands. The global gitlab-cli skill has the glab issue close -c gotcha. Every command that uses GitLab benefits from that knowledge.

4. Delegate to subagents for heavy work. The /commit command uses a Bash subagent. The /document command uses a doc-generator subagent. This keeps each command focused.

5. Match your team’s conventions. My commit command reads git log to match the existing style. My issue templates use Australian English. Small details, but they make the output feel like it belongs.

The files

All of this lives in two places:

~/.claude/skills/
  gitlab-cli/SKILL.md          # Global: how to use glab

<project>/.claude/commands/
  commit.md                     # /commit — stage, commit, push
  issue.md                      # /issue — create bug report
  feature.md                    # /feature — create feature request
  document.md                   # /document — generate AsciiDoc docs

The skills are portable across projects. The commands are project-specific and checked into git, so anyone on the team gets the same workflow.