internal-github-operations

Estrelas1

Forks0

Atualizado1 de agosto de 2026 às 21:32

Use when /internal-github routes a GitHub operational request covering Actions health, runners, audit evidence, reporting, drift, preflight, rollout validation, or post-rollout proof.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

pagopa

pagopa/cloud-strategy.github

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Administradores de redes e sistemas de computadorInformática e Matemática·SOC 15-1244

Explorador de arquivos

3 arquivos

SKILL.md

readonly

name	internal-github-operations
description	Use when /internal-github routes a GitHub operational request covering Actions health, runners, audit evidence, reporting, drift, preflight, rollout validation, or post-rollout proof.
user-invocable	false

Internal GitHub Operations

Validate, observe, and operationalize an existing GitHub platform change. Treat workflow behavior, runner health, audit evidence, and reporting as separate signals that must be tied to the requested proof.

When to use

Use when the requested deliverable is operational evidence, rollout proof, runner or workflow health, audit evidence, reporting, or drift validation.

Evidence workflow

State the operational objective, affected surface, and rollout unit.
Define preflight checks proportional to blast radius, including permission, environment, runner, workflow, audit, and reporting signals as relevant.
State what is confirmed, what is inferred, and what still needs a real test.
Validate the first safe rollout unit and record both success signals and unexpected permission, runner, or release regressions.
Define the rollback trigger and owner before widening rollout.
Collect post-rollout evidence for the workflow, runner, audit, and drift signals that prove the requested behavior.

Operational rules

Keep workflow success distinct from runner health and permission proof.
Keep audit and reporting evidence tied to the decision that needs confirmation.
Use current GitHub documentation when Actions behavior, runner support, audit capability, reporting export, or platform validation details can change the result.
When querying GitHub security alert endpoints with gh api, force --method GET or encode filters in the query string. Form fields such as -f state=open without an explicit GET can produce misleading 404 responses.

Load references/validation-and-evidence.md when a deeper checklist is needed.

Completion criteria

Confirmed and inferred evidence are separated.
Rollout unit and rollback trigger are explicit for risky changes.
Runner, workflow, audit, and permission signals match the affected surface.
Post-rollout proof and any drift follow-up are stated.
Continuity assumptions are included only when build, release, or repository criticality is in scope.

Mais deste repositório

mesmo repositório

anthropic-docx

pagopa/cloud-strategy.github

Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.

2026-08-011

internal-agent-creator

pagopa/cloud-strategy.github

Use when creating, reviewing, or materially revising a repository-owned Copilot agent under `.github/agents/`.

2026-08-011

internal-aws-governance

pagopa/cloud-strategy.github

Use when /internal-aws selects the AWS governance lane for IAM operating models, trust policies, federation, permission boundaries, SCPs, tag policies, exception controls, or access guardrails.

2026-08-011

internal-aws-lambda

pagopa/cloud-strategy.github

Use when /internal-aws selects the AWS Lambda lane for handlers, event sources, runtimes, packaging, retries, concurrency, cold starts, or Lambda-specific configuration.

2026-08-011

internal-aws-mcp-research

pagopa/cloud-strategy.github

Use when /internal-aws selects the AWS research lane to retrieve current official AWS documentation, regional availability, service behavior, IAM state, or policy-simulation evidence.

2026-08-011

internal-aws-operations

pagopa/cloud-strategy.github

Use when /internal-aws selects the AWS operations lane for monitoring, logging, rollout validation, backup and restore proof, DR evidence, reporting, or audit evidence.

2026-08-011

name	internal-github-operations
description	Use when /internal-github routes a GitHub operational request covering Actions health, runners, audit evidence, reporting, drift, preflight, rollout validation, or post-rollout proof.
user-invocable	false

Internal GitHub Operations

When to use

Use when the requested deliverable is operational evidence, rollout proof, runner or workflow health, audit evidence, reporting, or drift validation.

Evidence workflow

State the operational objective, affected surface, and rollout unit.
Define preflight checks proportional to blast radius, including permission, environment, runner, workflow, audit, and reporting signals as relevant.
State what is confirmed, what is inferred, and what still needs a real test.
Validate the first safe rollout unit and record both success signals and unexpected permission, runner, or release regressions.
Define the rollback trigger and owner before widening rollout.
Collect post-rollout evidence for the workflow, runner, audit, and drift signals that prove the requested behavior.

Operational rules

Keep workflow success distinct from runner health and permission proof.
Keep audit and reporting evidence tied to the decision that needs confirmation.
Use current GitHub documentation when Actions behavior, runner support, audit capability, reporting export, or platform validation details can change the result.
When querying GitHub security alert endpoints with gh api, force --method GET or encode filters in the query string. Form fields such as -f state=open without an explicit GET can produce misleading 404 responses.

Load references/validation-and-evidence.md when a deeper checklist is needed.

Completion criteria

Confirmed and inferred evidence are separated.
Rollout unit and rollback trigger are explicit for risky changes.
Runner, workflow, audit, and permission signals match the affected surface.
Post-rollout proof and any drift follow-up are stated.
Continuity assumptions are included only when build, release, or repository criticality is in scope.