Code quality

This skill covers the moment code leaves your machine: a push, a pull request, a merge, a review.

Pick the CLI

The task's vcsProvider field or the remote URL tells you the provider.

Operation	GitHub (`gh`)	GitLab (`glab`)
Clone	`gh repo clone`	`glab repo clone`
Create PR or MR	`gh pr create`	`glab mr create`
View	`gh pr view`	`glab mr view`
CI status	`gh pr checks`	`glab mr view --json pipelines`
Review	`gh pr review`	`glab mr approve`, `glab mr note`
Comment on an issue	`gh issue comment`	`glab issue note`

Before you push

Run every command in the Repository Guidelines section "PR Checks" of your system prompt, one after the other. When no guidelines exist, run the checklist in the repo's CLAUDE.md. When neither exists, ask the lead before you push.
A failing check: fix the cause and run the check again. Push only when every check passes.
Git hooks stay on. --no-verify and any other bypass flag are out.
main and master are never force-pushed.
One logical change per PR. Conventional commit titles when the repo uses them.

After you open a PR

Wait about 30 seconds, then read CI: gh pr checks <number> or glab mr view --json pipelines.
Red CI: read the failing job, fix, push, read CI again. Repeat until green.
Put the PR URL and the CI status in your task output.

Merge policy

The Repository Guidelines carry allowMerge and mergeChecks.

allowMerge false (the default): review and approve. Do not merge.
allowMerge true: run every mergeChecks entry first, then merge.

Review a PR

CI status first, including the fork checks below before treating CI as evidence. Failing CI is a REQUEST_CHANGES. Name the failing checks in the review.
Detect a GitHub fork PR with gh pr view <number> --json isCrossRepository --jq .isCrossRepository.
For a GitHub fork PR, inspect held runs with SHA=$(gh pr view <number> --json headRefOid --jq .headRefOid); gh api --paginate "repos/<owner>/<repo>/actions/runs?head_sha=$SHA" --jq '.workflow_runs[] | "\(.conclusion // .status)|\(.name)"'; gh pr checks and statusCheckRollup can omit them.
Treat any action_required run or no substantive run executed on that SHA as a CI blocker. Keep run handling read-only: REQUEST_CHANGES naming the held or unexecuted run, and report the blocker so an explicitly authorized maintainer or the application-controlled GitHub integration can approve the run after validating the workflow and its trust boundary. Do not APPROVE on omitted runs.
Tests second. A code change without new or updated tests is a REQUEST_CHANGES. Name the tests you expect. Exceptions: documentation-only, configuration-only, and dependency-bump PRs.
Apply the "Review Guidance" entries from the Repository Guidelines.
Read the diff for security (injection, secrets in code), logic (null handling, off-by-one, edge cases), performance (N+1, leaks), and code shape (naming, duplication, error handling). Run the test suite and the type check locally when you can.
Post the review with the verdict first. One finding per comment, with file and line, and what to change.

GitHub review-reply provenance

Before an automated reply to an inline review thread:

gh api user --jq .login must equal ${GITHUB_BOT_NAME:-agent-swarm-bot}.
Post through the GITHUB_TOKEN-backed gh api path.
Append  to the reply body.

A user-OAuth GitHub connector (for example codex_apps) must not author swarm review replies. When the login does not match, do not post. Report the mismatch in your task output.

Related skills

tackle-gh-comments: working through every review thread on a PR.
engineering-standards: the code-shape bar a reviewer holds the diff to.
code-reviewing: the two-axis review (standards and spec) for a phase or a branch.

Code Quality

Template Content