
Golang Continuous Integration
Run Claude-powered Go pull request review jobs in GitHub Actions with scoped permissions, concurrency, and quality-focused gates.
Overview
golang-continuous-integration is an agent skill most often used in Ship (also Build testing) that provides a GitHub Actions workflow for Claude-driven Go PR code review with documented permission risks.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-continuous-integrationWhat is this skill?
- GitHub Actions workflow for PR opened/sync/review events with concurrency cancel-in-progress
- Job 1 Review—Quality covers style, naming, and documentation with suggestion-first posture
- Explicit permissions block: contents/issues read, pull-requests write, actions read, id-token write
- Security note flags repo-wide pull-requests write and actions read exposure
- Skips Dependabot/Renovate bot PRs by default with optional filter removal
- Review—Quality job timeout: 15 minutes
- Workflow triggers: pull_request, pull_request_review_comment, pull_request_review
Adoption & trust: 3.6k installs on skills.sh; 2k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want consistent AI review on every Go PR without hand-rolling Actions triggers, concurrency, and permission scopes each time.
Who is it for?
Solo Go maintainers who already use GitHub Actions and want automated suggestion-first review on human-opened PRs.
Skip if: Repos that cannot grant pull-requests write to Actions, teams that need review on every bot bump PR without changing the filter, or projects not using Go.
When should I use this skill?
Setting up or extending GitHub Actions for Go repositories that need automated Claude PR review with quality-focused jobs.
What do I get? / Deliverables
You adopt a ready-to-adapt workflow YAML with quality review job scaffolding and explicit guidance on narrowing repo-wide write permissions.
- GitHub Actions workflow YAML for PR-triggered AI review
- Documented permissions and bot-PR skip guardrails
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Automated PR review is a Ship concern—quality and security feedback before merge—while the workflow lives in CI/CD. The skill centers on AI code review on pull requests (quality job), not local unit tests alone.
Where it fits
Turn on AI quality review on every synchronize event before you merge a Go API change.
Bootstrap a standard PR review workflow while defining team CI conventions for a new service repo.
Tighten bot-skip and permission comments after noticing noisy reviews on dependency PRs.
How it compares
CI workflow template for AI PR review, not a local golangci-lint skill or interactive chat-only review.
Common Questions / FAQ
Who is golang-continuous-integration for?
Indie Go developers and small teams running GitHub Actions who want Claude review jobs wired to PR and review-comment events.
When should I use golang-continuous-integration?
In Ship when setting up PR review automation; in Build when standardizing CI before merge; adjust triggers if you need stricter trust boundaries on forks.
Is golang-continuous-integration safe to install?
The skill itself documents broad workflow permissions—confirm trust boundaries and review the Security Audits panel on this page before enabling in production repos.
SKILL.md
READMESKILL.md - Golang Continuous Integration
name: AI Code Review (Claude) on: pull_request: types: [opened, synchronize, reopened, ready_for_review] pull_request_review_comment: types: [created] pull_request_review: types: [submitted] # Security note: these permissions apply to the entire repository, not just the current PR. # `pull-requests: write` allows the workflow to post, edit, and resolve comments on ANY pull request. # `actions: read` allows reading logs from ANY workflow run, which may contain sensitive output. # Scope risk by restricting the trigger to PRs from trusted contributors or protected branches, # and by never logging secrets in CI steps. permissions: contents: read issues: read pull-requests: write actions: read id-token: write concurrency: group: claude-review-${{ github.event.pull_request.number || github.event.issue.number }}-${{ github.event_name }} cancel-in-progress: true jobs: # ── Job 1: Code quality (suggestion-first) ────────────────────────────────── # Covers: style, naming, documentation quality: name: Review — Quality runs-on: ubuntu-latest timeout-minutes: 15 # Skip bot PRs (Dependabot, Renovate, etc.) # Remove this filter if you want bots to get reviewed. if: ${{ github.event_name == 'pull_request' && !endsWith(github.event.pull_request.user.login, '[bot]') }} steps: - uses: actions/checkout@v6 with: fetch-depth: 1 - name: Set up Go uses: actions/setup-go@v6 with: go-version: stable - name: Install Go skills run: npx skills add https://github.com/samber/cc-skills-golang -a claude-code --skill '*' -y --copy - uses: anthropics/claude-code-action@v1 with: anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }} show_full_output: true use_sticky_comment: true track_progress: true sticky_comment_header: "<!-- claude-review-quality -->" additional_permissions: | actions: read claude_args: >- --allowedTools "mcp__github_inline_comment__create_inline_comment,mcp__context7__resolve-library-id,mcp__context7__query-docs,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*)" prompt: | REPO: ${{ github.repository }} PR NUMBER: ${{ github.event.pull_request.number }} AUTHOR: ${{ github.event.pull_request.user.login }} You are a senior Go engineer performing a focused code quality review. Review this pull request. - Use `gh pr diff` to read the diff. - Use `gh pr view` to read description and metadata. - Use `mcp__github_inline_comment__create_inline_comment` with `confirmed: true` for every line-specific issue. Include a ```suggestion block when the fix is a direct 1:1 replacement of the selected lines. - Use `gh pr comment` only for a top-level summary. - Post nothing else. No chat output. ## Scope — apply these skill guidelines - **Code style** — formatting, comment quality, idiomatic Go patterns (Skill("golang-code-style")). - **Naming** — packages, types, variables, functions, constants (Skill("golang-naming")). - **Documentation** — exported symbols, package-level docs, README impact (Skill("golang-documentation")). ## Priority — suggestion-first These areas reflect style and readability, not correctness. Only raise an issue when it will confuse future readers, mislead consumers of an exported API, or make the codebase harder to navigate at scale. Do not flag formatting that `gofmt` handles automatically. Do not flag personal preferences when the code is otherwise clear. ## How to report Every comment must: 1. Name the specific problem (not just its symptom) 2. Explain under what conditions it matters or fails