Help us improve
Share bugs, ideas, or general feedback.
From session-orchestrator
Single source of truth for VCS operations on GitLab and GitHub repos — creating/updating/closing issues and MRs, resolving project IDs, and running glab/gh CLI commands. Consuming skills reference this rather than duplicating logic.
npx claudepluginhub kanevry/session-orchestrator --plugin session-orchestratorHow this skill is triggered — by the user, by Claude, or both
Slash command
/session-orchestrator:gitlab-opshaikuThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Detect which VCS platform the current repo uses and select the right CLI:
Reference GitLab CLI (glab) commands for authentication, issues, merge requests, pipelines, releases, repo management, labels, variables from terminal.
Manages GitHub issues, PRs, milestones, and Projects v2 using gh CLI commands, REST API calls, and GraphQL queries. Useful for automation, bulk operations, and project tracking.
Executes GitHub operations (PRs, issues, milestones, labels, comments, merges) using Python scripts with structured output and error handling. Use for pull requests, issues, review comments, CI checks, milestones instead of raw gh.
Share bugs, ideas, or general feedback.
Detect which VCS platform the current repo uses and select the right CLI:
# Check git remote
REMOTE_URL=$(git remote get-url origin 2>/dev/null)
if echo "$REMOTE_URL" | grep -q "github.com"; then
VCS=github # use `gh`
else
VCS=gitlab # use `glab`
fi
Session Config overrides:
vcs: github|gitlab — force a specific platformgitlab-host: <host> — override auto-detected GitLab host (glab reads host from git remote by default)Directive: Consuming skills MUST NOT duplicate VCS auto-detection logic or CLI command syntax inline. This skill is the single source of truth for all VCS operations.
When a skill needs VCS operations, include this reference block in its instructions:
VCS Reference: Detect the VCS platform per the "VCS Auto-Detection" section of the gitlab-ops skill. Use CLI commands per the "Common CLI Commands" section. For cross-project queries, see "Dynamic Project Resolution."
Canonical commands: All glab and gh command syntax — flags, output formats,
pagination options — is defined in the "Common CLI Commands" section below. Consuming
skills must reference that section rather than redefining commands. If a skill needs a
command variant not listed there, add it to this file first, then reference it.
What consuming skills should include:
glab/gh invocations or detection snippetsNever hardcode project IDs. Resolve them at runtime.
# GitLab — get numeric project ID
glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])"
# GitHub — get owner/name identifier
gh repo view --json nameWithOwner -q '.nameWithOwner'
When a skill needs to reference other projects (e.g., from cross-repos in Session Config):
# GitLab — resolve project ID by name
glab api "projects?search=<project-name>" | python3 -c "import json,sys; [print(p['id'], p['path_with_namespace']) for p in json.load(sys.stdin)]"
# GitHub — resolve repo details
gh api "repos/<owner>/<name>" --jq '.full_name'
Note: Some API calls require numeric project IDs (GitLab) or owner/repo slugs (GitHub). Always resolve dynamically from the project name.
priority:critical — blocking production or userspriority:high — important, schedule this sprintpriority:medium — plan for next sprintpriority:low — backlog, nice-to-havestatus:ready — defined, ready to pick upstatus:in-progress — actively being worked onstatus:review — MR/PR created, awaiting reviewstatus:blocked — waiting on external dependencyarea:frontend | area:backend | area:databasearea:ai | area:security | area:testingarea:ci | area:infrastructure | area:compliancebug | feature | enhancement | refactorchore | documentation | epic | discovery | carryovercarryover — auto-created for 2×SPIRAL or FAILED agent tasks; see scripts/lib/spiral-carryover.mjs.# Issues
glab issue list --per-page 50 # All open issues
glab issue list --label "status:ready" --per-page 10 # Ready to work on
glab issue list --label "priority:high" --per-page 10 # High priority
glab issue list --closed --per-page 10 # Recently closed
glab issue view <IID> # View issue details
glab issue view <IID> --comments # With comments
glab issue create --title "title" --label "priority:high,status:ready"
glab issue update <IID> --label "status:in-progress"
glab issue close <IID>
glab issue note <IID> -m "Comment text" # Add comment
# MRs
glab mr list # Open MRs
glab mr create --fill --draft # Create draft MR
glab mr merge <MR_IID> # Merge MR
# Pipelines
glab pipeline list --per-page 5 # Recent pipelines
glab pipeline status <ID> # Pipeline details
# API (reads host from git remote automatically)
glab api "projects/$(glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/issues?state=opened&per_page=50"
glab api "projects/$(glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/milestones?state=active"
# Issues
gh issue list --limit 50 # All open issues
gh issue list --label "status:ready" --limit 10 # Ready to work on
gh issue list --label "priority:high" --limit 10 # High priority
gh issue list --state closed --limit 10 # Recently closed
gh issue view <NUMBER> # View issue details
gh issue view <NUMBER> --comments # With comments
gh issue create --title "title" --label "priority:high,status:ready"
gh issue edit <NUMBER> --add-label "status:in-progress"
gh issue close <NUMBER>
gh issue comment <NUMBER> --body "Comment text" # Add comment
# PRs
gh pr list --state open # Open PRs
gh pr create --fill --draft # Create draft PR
gh pr merge <NUMBER> # Merge PR
# Workflows (CI equivalent)
gh run list --limit 5 # Recent workflow runs
gh run view <RUN_ID> # Run details
# API
gh api "repos/{owner}/{repo}/issues?state=open&per_page=50"
gh api "repos/{owner}/{repo}/milestones?state=open"
## Description
What happens vs. what should happen.
## Steps to Reproduce
1.
2.
## Root Cause (if known)
## Acceptance Criteria
- [ ]
## Goal
What should be achieved and why.
## Tasks
- [ ]
## Acceptance Criteria
- [ ]
## Session Type
[housekeeping|feature|deep]
## [Carryover] Original Task Description
### What was completed
- [completed items]
### What remains
- [ ] [remaining task 1]
- [ ] [remaining task 2]
### Context for next session
[relevant context, file paths, decisions made]
### Original Issue
Relates to #ORIGINAL_IID
## [Discovery] <finding title>
**Probe:** <probe_name>
**Severity:** <priority:critical|high|medium|low>
**Category:** <code|infra|ui|arch|session>
### Finding
<description of the problem>
### Evidence
- **File:** `<file_path>`
- **Line:** <line_number>
- **Code:**
<matched_text with surrounding context>
### Impact
<why this matters — severity rationale>
### Recommended Fix
<concrete fix suggestion>
### Acceptance Criteria
- [ ] <specific, verifiable condition>
- [ ] Quality gates pass after fix
Labels: type:discovery, priority:<level>, area:<inferred>, status:ready
Pattern 3 of the gsd Pattern Adoption (Issue #519) registers a PreToolUse hook
hooks/pre-bash-templates-first.mjs that blocks gh|glab pr|mr|issue create|new
Bash calls when the current session contains no prior Read on a matching template file.
When this matters: before you or a subagent opens an MR, PR, or issue via CLI, a matching template must have been read in the current session:
.github/PULL_REQUEST_TEMPLATE.md / .github/ISSUE_TEMPLATE*.gitlab/merge_request_templates/Default.md / .gitlab/issue_templates/*Accepted template paths are configured in .orchestrator/policy/templates-policy.json
(versioned, operator-editable). Default behaviour:
enforcement: "block" — hook exits 2 when no prior template Read is foundbypass_patterns — list of command substrings that skip the hook (e.g. CI/bot calls)Bypass options for the current session (when the hook blocks unexpectedly):
create call after a Read on the template
path; the hook re-evaluates and sees the Read..orchestrator/runtime/templates-acknowledged.json
containing { sessionId, acknowledgedAt }; the hook allows all subsequent create
calls in this session.What the hook mechanically enforces (what this skill previously documented as convention only):
If the hook blocks incorrectly, follow this sequence:
create call.hooks/pre-bash-templates-first.mjs
with reproduce steps (command, session ID, template path that should have matched).# 1. Read the relevant template first (satisfies the hook)
# GitLab MR
Read .gitlab/merge_request_templates/Default.md
# GitHub PR
Read .github/PULL_REQUEST_TEMPLATE.md
# 2. Then create — hook now passes
glab mr create --title "..." --description "..."
gh pr create --title "..." --body "..."
hooks/pre-bash-templates-first.mjshooks/_lib/transcript-history.mjs (checks session transcript for prior Reads).orchestrator/policy/templates-policy.json.orchestrator/runtime/templates-acknowledged.jsonhooks/pre-bash-destructive-guard.mjsdocs/prd/2026-05-22-gsd-pattern-adoption-quickwins.md § Pattern 3 + § 3 Gherkin Pattern 3