/gh-merge
Completes the AgentsMesh GitHub pull-request workflow: commits scoped changes, rebases on the authoritative GitHub branch, opens or reuses a PR, monitors required checks, fixes failures, and merges only after verification. Use when the user asks to merge, submit, or land
$ npx -y skills add AgentsMesh/AgentsMesh --skill gh-merge --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/gh-merge
Context preview
The summary Claude sees to decide when to auto-load this skill.
Completes the AgentsMesh GitHub pull-request workflow: commits scoped changes, rebases on the authoritative GitHub branch, opens or reuses a PR, monitors required checks, fixes failures, and merges only after verification. Use when the user asks to merge, submit, or land
SKILL.md
gh-merge.SKILL.mdname: gh-merge
description: >-
Completes the AgentsMesh GitHub pull-request workflow: commits scoped
changes, rebases on the authoritative GitHub branch, opens or reuses a PR,
monitors required checks, fixes failures, and merges only after verification.
Use when the user asks to merge, submit, or land repository changes.
GitHub Merge
GitHub is the development source of truth for this repository. Land changes through a GitHub pull request; do not create a GitLab merge request for product code.
Workflow
1. Inspect repository state:
git status --short --branch
git branch --show-current
git remote -v
gh auth status --hostname github.com
2. Identify the GitHub remote by URL instead of assuming a remote name. Resolve the target branch, normally `main`, and refuse to merge directly while checked out on that branch. 3. Review all dirty files. Stage only files belonging to the requested change; preserve unrelated user changes and never use `git add .`. Run the relevant local tests and `git diff --check`, then create a focused commit containing only the requested change. 4. Require a clean index and working tree before rebasing. If unrelated user changes remain, do not stash or move them automatically; use an already isolated checkout or stop and report what prevents a safe rebase. Once the checkout is clean, fetch and rebase on the current GitHub target:
git fetch <github-remote> <target-branch>
git rebase <github-remote>/<target-branch>
Resolve conflicts with user-owned work preserved, then rerun affected tests when the rebase changes the integration base. 5. Push the current branch. After a rebase, use `--force-with-lease`, never `--force`. 6. Reuse an existing pull request for the branch or create one with `gh pr create` and the repository PR template. The title and body must explain behavior, verification, and any remaining risk. 7. Inspect review state and wait for checks:
gh pr checks <pr-number> --watch --interval 15 --fail-fast
At least one check must be observed. If no checks are reported, retry after the workflow trigger delay; no checks is not a passing state. Diagnose failures from run logs, fix them, push, and monitor again. 8. Merge only when all observed checks have completed successfully, reviews and branch policy allow it, and the PR is conflict-free:
gh pr merge <pr-number> --squash --delete-branch
9. Verify the remote PR state is `MERGED`. In a worktree, failure to delete the local branch does not mean the remote merge failed; report cleanup separately.
Result
Report the PR URL, source and target branches, commit, local tests, remote check results, merge method, and any local branch or worktree that remains.
Read more
name: gh-merge description: >- Completes the AgentsMesh GitHub pull-request workflow: commits scoped changes, rebases on the authoritative GitHub branch, opens or reuses a PR, monitors required checks, fixes failures, and merges only after verification. Use when the user asks to merge, submit, or land repository changes.
GitHub Merge
GitHub is the development source of truth for this repository. Land changes through a GitHub pull request; do not create a GitLab merge request for product code.
Workflow
1. Inspect repository state:
git status --short --branch git branch --show-current git remote -v gh auth status --hostname github.com
2. Identify the GitHub remote by URL instead of assuming a remote name. Resolve the target branch, normally `main`, and refuse to merge directly while checked out on that branch. 3. Review all dirty files. Stage only files belonging to the requested change; preserve unrelated user changes and never use `git add .`. Run the relevant local tests and `git diff --check`, then create a focused commit containing only the requested change. 4. Require a clean index and working tree before rebasing. If unrelated user changes remain, do not stash or move them automatically; use an already isolated checkout or stop and report what prevents a safe rebase. Once the checkout is clean, fetch and rebase on the current GitHub target:
git fetch <github-remote> <target-branch> git rebase <github-remote>/<target-branch>
Resolve conflicts with user-owned work preserved, then rerun affected tests when the rebase changes the integration base. 5. Push the current branch. After a rebase, use `--force-with-lease`, never `--force`. 6. Reuse an existing pull request for the branch or create one with `gh pr create` and the repository PR template. The title and body must explain behavior, verification, and any remaining risk. 7. Inspect review state and wait for checks:
gh pr checks <pr-number> --watch --interval 15 --fail-fast
At least one check must be observed. If no checks are reported, retry after the workflow trigger delay; no checks is not a passing state. Diagnose failures from run logs, fix them, push, and monitor again. 8. Merge only when all observed checks have completed successfully, reviews and branch policy allow it, and the PR is conflict-free:
gh pr merge <pr-number> --squash --delete-branch
9. Verify the remote PR state is `MERGED`. In a worktree, failure to delete the local branch does not mean the remote merge failed; report cleanup separately.
Result
Report the PR URL, source and target branches, commit, local tests, remote check results, merge method, and any local branch or worktree that remains.
The AI Agent Workforce Platform. Run a hundred AI coding agents across your own machines — schedule, isolate, and steer them all from one console.
Repo: AgentsMesh/AgentsMesh
Other skills on agentsmesh.
- /arch-check
架构与实现审查 —— 基于「概念建模 → 职责划分 → 机制/策略分离 → 因果与不变量 → 属性建模 → 模块化 → SOLID → GRASP → YAGNI」的全维度审查,带置信度门控与假阳性抑制(对抗"过度工程建议"这类 AI slop)。触发于:要求 review/审查架构、检查目录结构/依赖关系/职责划分、重构前评估、技术债盘点、判断是否过度设计,或问「这个设计合理吗 / 该怎么拆 / 有没有循环依赖 / 这个改动架构上 OK 吗」。一律按最高强度审查。用法:`arch-check [范围]
Open skill - /e2e
Selects and runs the appropriate AgentsMesh end-to-end suite for Web, Desktop, MCP, or iOS, including worktree-specific environment setup and browser-level verification. Use when a change needs E2E coverage, a user asks to execute or diagnose an E2E test, or a cross-service
Open skill - /github-gitlab-mirror
Audits or synchronizes the authoritative GitHub main branch to the internal GitLab mirror without importing GitLab-only history back into GitHub. Use when checking GitHub/GitLab consistency, updating the internal mirror, or resolving a divergence between the two remotes.
Open skill - /worktree
Creates or reuses an isolated AgentsMesh Git worktree from a verified base branch, preserves existing changes, and optionally starts the worktree-scoped development environment. Use when the user asks for a new worktree or isolated work for a feature, fix, investigation, or
Open skill

