Communitygithub.com

Nuvraxis/nuvraxis-plugins

Convenções de GitHub Actions para apps Next.js da Nuvraxis — exatamente três workflows: pr.yaml (toda PR para qualquer branch: Biome, stylelint, typecheck/test/build com turbo --affected, build Docker + health check, helm lint + kubeconform; não publica nada), main.yaml (push para main: uma imagem multi-arquitetura para GHCR com tags sha-SHORTSHA e main, proveniência + SBOM, cache gha), release.yaml (tag vX.Y.Z: verifica na main, retaga a imagem existente sem reconstruir, empacota e envia o chart Helm para OCI, GitHub Release com chart, digest e SBOM). Permissões mínimas por job, apenas GITHUB_TOKEN, actions fixadas em majors. Use ao editar .github/workflows/*, adicionar uma etapa de CI ou depurar uma execução ou release com falha.

O que é nuvraxis-plugins?

Este skill define um conjunto rigoroso de três workflows de GitHub Actions para aplicações Next.js na organização Nuvraxis, garantindo um pipeline de CI/CD consistente, seguro e eficiente. Ele elimina a ambiguidade ao ditar exatamente o que cada workflow faz: 'pr.yaml' executa verificações de qualidade, build, Docker e Helm em pull requests sem publicar nada; 'main.yaml' constrói e publica uma imagem Docker multi-arquitetura com proveniência e SBOM; e 'release.yaml' retaga a imagem existente, publica o chart Helm no OCI e cria uma GitHub Release com artefatos. O skill impõe regras críticas como permissões mínimas por job, uso exclusivo de GITHUB_TOKEN, pinagem de actions por major, toolchain fixa (pnpm antes de setup-node), concorrência inteligente e nomes em minúsculas. Suporta plataformas como GitHub Actions, Docker BuildKit e Helm, e é útil para desenvolvedores que precisam depurar falhas de CI, adicionar novas etapas ou entender o pipeline de deploy, eliminando conjeturas sobre a configuração correta.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Nuvraxis/nuvraxis-plugins/tree/HEAD/plugins/nuvraxis-frontend/skills/github-actions
Ver original→Navegar por todas as habilidades

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentação

GitHub Actions

Três workflows por aplicativo, cada um com um job do seu tipo. O template .github/workflows/{pr,main,release}.yaml é a fonte da verdade; eles são reproduzidos com notas em references/workflows.md.

pull request ──► pr.yaml       verificações apenas, nada publicado
merge para main ─► main.yaml     imagem construída uma vez → ghcr.io/nuvraxis/<app>:sha-<short>, :main
tag vX.Y.Z ────► release.yaml  mesma imagem retagada :vX.Y.Z, :latest · chart X.Y.Z → OCI · GitHub Release

Regras para todos os workflows

  1. permissions: contents: read no topo; amplie por job apenas conforme necessário. packages: write para jobs que enviam para GHCR, contents: write apenas para o job que cria o Release. Sem id-token: write ou attestations: write: proveniência e SBOM vêm do BuildKit, não de actions/attest* (que precisa do GitHub Enterprise para repositórios privados).

  2. Apenas GITHUB_TOKEN. O login no GHCR usa ${{ github.actor }} / ${{ secrets.GITHUB_TOKEN }}; gh usa GH_TOKEN: ${{ github.token }}. Sem tokens de acesso pessoal no CI. (Puxar pacotes privados do cluster é uma credencial diferente; veja helm-nextjs.)

  3. Fixar actions por major (@v7) e manter a tabela de SHA atualizada. O template usa tags major para legibilidade. Se a organização exigir pinagem por SHA, substitua cada @vN pelo SHA de references/action-pins.md e mantenha o comentário # vN.M.P. Atuais majors: checkout v7, setup-node v7, pnpm/action-setup v6, setup-qemu v4, setup-buildx v4, login v4, metadata v6, build-push v7, azure/setup-helm v5.

  4. Toolchain: pnpm/action-setup antes de actions/setup-node. O action-setup lê a versão do pnpm de packageManager; o setup-node lê .node-version e armazena em cache o store do pnpm (cache: pnpm precisa do pnpm no PATH primeiro). Em seguida, pnpm install --frozen-lockfile. Nunca npm ci.

  5. concurrency por workflow e ref; cancela em andamento apenas em PRs. Um novo push para uma PR cancela a execução antiga. Em main e tags, as execuções sempre terminam: release.yaml precisa da imagem daquele commit exato.

  6. Nunca ecoar segredos ou interpolar entrada não confiável em run:. Passe valores através de env: e cite-os ("${APP}"). ${{ github.event.pull_request.title }} e similares nunca entram em um script. persist-credentials: false no checkout quando o job não faz push para git.

  7. Todo job tem timeout-minutes. Um build Docker pendurado, caso contrário, queima seis horas.

  8. Nomes são em minúsculas. GHCR rejeita repositórios em maiúsculas. IMAGE: ghcr.io/nuvraxis/<app> é escrito em minúsculas em env; o scaffold converte o nome do app para minúsculas.

pr.yaml

  1. on: pull_request com types: [opened, synchronize, reopened, ready_for_review] e sem filtro branches, para que PRs empilhadas contra branches de funcionalidade também sejam verificadas. Todo job tem if: ${{ !github.event.pull_request.draft }}; marcar como pronto dispara a execução.

  2. Quatro jobs paralelos: quality (biome ci --reporter=github, stylelint, turbo run typecheck test --affected, pnpm audit --audit-level high), build (turbo run build --affected), docker (construir uma plataforma com load: true, executar apenas leitura com capacidades removidas, curl /api/health), helm (helm lint --strict e kubeconform em ambos os arquivos de valores). --affected precisa de fetch-depth: 0.

  3. Nada é enviado de uma PR. push: false, cache somente leitura (apenas cache-from), sem login no registro.

main.yaml

  1. on: push: branches: [main] constrói a imagem uma vez, para ambas as arquiteturas, e a envia. Tags de docker/metadata-action: type=sha,format=short,prefix=sha- e type=raw,value=main, flavor: latest=false. latest pertence aos releases.

  2. provenance: mode=max, sbom: true, cache-from/to: type=gha,scope=<app>,mode=max. Proveniência e SBOM são anexados ao índice da imagem; o release.yaml os carrega ao retagar. NEXT_DEPLOYMENT_ID=${{ github.sha }} é o argumento de build para proteção contra skew.

  3. main.yaml não publica o chart e não reexecuta as verificações da PR. A proteção de branch exige pr.yaml; main apenas produz o artefato.

release.yaml

  1. on: push: tags: ['v*.*.*'], então, em ordem:

    1. Falhar a menos que a tag seja exatamente vMAJOR.MINOR.PATCH e seu commit seja um ancestral de origin/main.
    2. Não reconstruir. Se ghcr.io/nuvraxis/<app>:sha-<short> não existir, falhar com "deixe main.yaml terminar, então reexecute". Sem build de fallback.
    3. docker buildx imagetools create --tag :vX.Y.Z --tag :latest <sha-image>: uma cópia no nível do manifesto que mantém ambas as arquiteturas, proveniência e SBOM, no mesmo digest.
    4. helm package --version X.Y.Z --app-version vX.Y.Z, helm push para oci://ghcr.io/nuvraxis/charts.
    5. gh release create vX.Y.Z --verify-tag --generate-notes com o chart .tgz, image-digest.txt e sbom.spdx.json anexados.

  2. O ritual de release: merge para main → aguardar o main.yaml ficar verde → git tag vX.Y.Z && git push origin vX.Y.Z. Marcar a tag antes do main.yaml terminar faz com que o passo 2 falhe de propósito; reexecute o job de release assim que a imagem existir. Um release ruim é corrigido com uma nova tag de patch, nunca movendo uma tag.

Acelerando (apenas quando necessário)

  • arm64 sob QEMU é a parte lenta do main.yaml. Substitua por uma matrix em ubuntu-24.04-arm + ubuntu-latest enviando por digest, depois um job de merge com imagetools create. Mantenha as tags e o índice único.
  • Cache remoto do Turborepo para pr.yaml: veja pnpm-turborepo.

Verificar

docker run --rm -v "$PWD:/repo" -w /repo rhysd/actionlint:latest     # lint em todos os workflows
gh workflow list && gh run list --limit 5
gh run view <run-id> --log-failed

Após um release: docker buildx imagetools inspect ghcr.io/nuvraxis/<app>:vX.Y.Z mostra ambas as plataformas, e helm show chart oci://ghcr.io/nuvraxis/charts/<app> --version X.Y.Z mostra appVersion: vX.Y.Z.

Fontes

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Nuvraxis/nuvraxis-plugins

>- Biome 2.5 setup and rules for Nuvraxis monorepos — root biome.json with pinned $schema, VCS ignore, formatter settings, the recommended preset with a11y and the react/next domains, nursery policy, organize imports, overrides, nested per-package configs ("extends": "//"), biome check --write locally, biome ci in CI, VS Code settings, and migrating from ESLint/Prettier. Use when the repo has biome.json or biome.jsonc, @biomejs/biome in package.json, .eslintrc*/eslint.config.*/.prettierrc* to migrate, or when fixing lint and formatting errors.

Nuvraxis/nuvraxis-plugins

>- Dockerfile rules for Next.js standalone apps in a pnpm + Turborepo monorepo — multi-stage build (turbo prune → pnpm fetch/offline install → turbo build → minimal runner), pinned Node 26 Alpine by digest, checksum-verified pnpm binary, non-root uid 1001, read-only root filesystem with a writable .next/cache, HEALTHCHECK on /api/health, build args only for NEXT_PUBLIC_* values, BuildKit secrets and cache mounts, multi-arch, OCI labels and .dockerignore. Use when the repo has a Dockerfile, .dockerignore, compose file, or next.config with output "standalone", or when asked to containerise, shrink, harden or debug an image.

Nuvraxis/nuvraxis-plugins

>- Helm chart rules for Nuvraxis Next.js apps — one chart per app in charts/ (named after the app), published to oci://ghcr.io/nuvraxis/charts and synced by Argo CD; Chart.yaml version/appVersion set only by release.yaml; Deployment with startup/liveness/readiness probes on /api/health, non-root read-only security context, emptyDir for .next/cache, ConfigMap + existing Secret via envFrom, Service, Ingress with cert-manager, HPA, PDB, ServiceAccount, topology spread; no Helm hooks; helm lint --strict + kubeconform. Use when the repo has charts/, Chart.yaml, values*.yaml, templates/*.yaml with Helm syntax, or an Argo CD Application, or when asked to deploy, scale, expose or configure the app on Kubernetes.

Nuvraxis/nuvraxis-plugins

>- Production rules for Next.js 16 App Router apps at Nuvraxis — Server/Client Component boundaries, Cache Components ("use cache", cacheLife, cacheTag, updateTag), Server Actions, route handlers, env handling, instrumentation, output standalone and the /api/health route. Use when the project has "next" in package.json, an app/ or src/app/ directory, next.config.ts, proxy.ts, instrumentation.ts, or files named page.tsx, layout.tsx, route.ts, loading.tsx, error.tsx.

Habilidades Relacionadas

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community