golang-continuous-integration

Files (1)

• SKILL.md

SKILL.md (first lines)

# Go Continuous Integration

Create the smallest pipeline that enforces the repository's actual support and release policy. Do not copy a generic workflow without reconciling it with the project.

## Inspect before designing

Read:

- go.mod, go.work, tool pinning, generated-code instructions, and supported platforms;
- existing workflows, repository instructions, Makefile or task runner, and local verification commands;
- release and container configuration;
- branch protection assumptions and whether pull requests can come from forks.

Infer neither the supported Go matrix nor the release process from the current local toolchain. If compatibility is undocumented, surface the choice rather than inventing a matrix.

## Build a minimal check graph

A typical pull-request pipeline may include:

1. Build or compile the packages and commands relevant to the project.
2. Run unit tests with the repository's ordinary flags.
3. Run formatting, vet, lint, generated-code, or module-tidiness checks only when the repository defines the corresponding policy.
4. Run integration tests in a separate job when they need services, credentials, longer timeouts, or platform-specific setup.
5. Run vulnerability analysis when govulncheck is already pinned or available, or when the user asks to add it.

Use the race detector where CGO, platform support, runtime, and the project's risk profile make it useful; it need not run on every matrix entry. Coverage is evidence, not a universal quality threshold. Do not introduce a blocking percentage without an agreed baseline and policy.

Keep feedback fast: put deterministic, cheap checks early; split genuinely independent jobs; avoid matrices that repeat identical signal.

## Remove Duplicate Work Before Expanding

For each job or matrix dimension, identify the distinct supported behavior it verifies. Reuse the repository's commands and fixtures. A new script, wrapper command, planner, or test harness needs a concrete purpose that the existing entry point cannot serve.

- Do not automatically multiply every patch version by every architecture and lifecycle scenario. Group equivalent behavior only with evidence; retain exact-version or target checks where the support contract or binary differences require them.
- Distinguish target compilation from runtime compatibility. Use representative expensive scenarios when they provide the needed signal, without claiming unexecuted targets were tested.
- Check whether pull-request and push triggers duplicate work for the same development update. Consider which revisions release gates need before removing a trigger; concurrency settings alone may not deduplicate different refs.
- Prefer existing commands and simple workflow conditions to a custom change planner. Avoid rebuilding or retesting the same artifact in several jobs without an independent reason.
- Simplify redundant tests or setup at their owner. Keep necessary synchronization, isolation, and cleanup; do not hide failures with retries or longer timeouts.

Honor required checks and release guarantees. If a proposed simplification changes that policy, make the decision explicit instead of silently dropping coverage. Describe removed duplication and remaining evidence; job counts and coverage percentages are not success criteria.

## Version and dependency policy

- Derive the primary Go version from go.mod or the repository's declared support policy.
- For current GitHub Action versions and configuration, verify the action's official repository or Marketplace page at implementation time.
- Follow the repository's existing pinning policy. For third-party actions in higher-risk jobs, prefer immutable commit pins and annotate the corresponding release tag.
- Use automated update tooling to keep action pins and Go dependencies current when the user requests it.
- Do not install arbitrary tools globally in the workflow. Prefer the repository's pinned Go tools or a version explicitly recorded in the workflow.

Treat go mod tidy as a consistency check by running it and failing on a diff; do not silently commit workflow-generated changes.

## Permission and event invariants

Start each workflow with no permissions or contents: read, then add the minimum permission per job.

Before writing a workflow, reason about both the event and the code being executed:

- Fork pull requests must not receive repository secrets.
- Avoid pull_request_target when checking out or executing untrusted pull-request code.
- Do not expose cache write credentials, cloud credentials, package tokens, or OIDC to untrusted code.
- Pin service images and actions according to repository policy.
- Set timeouts and concurrency cancellation for jobs that can hang or become obsolete.
- Keep artifacts free of secrets and define an appropriate retention period.

A workflow that publishes packages, pushes images, creates releases or tags, enables auto-merge, modifies pull requests, or requests id-token: write is a separate privileged operation. Implement it only when explicitly requested. Restrict its trigger, environment, permissions, and inputs, and describe the remaining repository-side controls such as protected environments and required checks.

## Releases and dependency automation

Keep validation separate from publication. A tag pattern alone is not proof that a release is authorized.

For release automation:

- establish who may create the release trigger;
- build from a reviewed commit;
- produce checksums and provenance when supported by the chosen release system;
- grant write permissions only to the publishing job;
- avoid printing secrets or passing them to untrusted subprocesses;
- test configuration in a non-publishing mode when the tool supports it.

For Dependabot or Renovate, group updates only when failures remain diagnosable. Do not add automatic merging by default. If it is requested, require the normal protected-branch checks and constrain which update classes may merge.

## Verification

Validate workflow syntax with an existing repository tool when available. Review the final diff for:

- event coverage and fork behavior;
- effective permissions per job;
- secret and OIDC exposure;
- current, pinned actions;
- cache keys and poisoning risk;
- Go version consistency;
- duplicated work and missing required checks;
- whether privileged jobs can run from untrusted input.

Do not push, enable workflows, change repository settings, create releases, or configure secrets unless the user explicitly authorizes those external changes.

From reagin/agent-skills, MIT.

More from reagin/agent-skills