Agent Skills for SRE/DevOps: Claude Code, Codex & Cloud

The way SREs and DevOps engineers interact with AI tools changed when Agent Skills moved from a Claude feature into a portable, open format. Anthropic introduced Agent Skills in October 2025 and published the format as an open standard in December 2025. OpenAI then adopted the same SKILL.md model across Codex, ChatGPT, and its API platform during 2026.

Instead of re-prompting an agent every time it needs your naming conventions, IaC module patterns, deployment gates, or cloud security baseline, you package that operational knowledge once as a versioned skill. The agent sees lightweight metadata first, loads the full instructions only when relevant, and reads supporting scripts or references only when needed.

This post covers the current cross-vendor ecosystem, the most useful SRE and DevOps patterns, and a complete worked example: an Azure Terraform skill with Microsoft Defender for Cloud guidance.

Current-day update — August 15, 2026: This article now reflects Claude Code project skills in .claude/skills/, Codex repository skills in .agents/skills/, OpenAI’s versioned Skills API, Claude’s current container-based API syntax, Codex plugins and GitHub Action, and the official Agent Skills specification. It also reflects OpenAI’s migration from the deprecated openai/skills catalog to openai/plugins. Obsolete --headless, --skill, local /plugin install <path>, and old Claude API examples have been removed.

References used in this article:

• Anthropic — Equipping agents for the real world with Agent Skills
• Agent Skills specification — the portable SKILL.md format
• Claude Platform — Agent Skills overview
• Claude Code — Extend Claude with skills
• OpenAI — Build skills for ChatGPT and Codex
• OpenAI Skills API reference
• OpenAI — Using skills to accelerate OSS maintenance
• github.com/anthropics/skills — Anthropic’s implementation and examples
• github.com/openai/plugins — current OpenAI plugin and skill examples
• Microsoft Learn — Microsoft Cloud Security Benchmark in Defender for Cloud
• Microsoft Learn — Scan IaC in Defender for Cloud
• github.com/YISUSVII/azure-terraform-defender — Published Azure Terraform Defender for Cloud compliance skill (the skill described in Section 6)

1. What Are Agent Skills?

An Agent Skill is a folder containing a required SKILL.md file and optional scripts, references, assets, and metadata. Compatible agents discover a skill from its frontmatter, decide whether it matches the task, then load its instructions and supporting files progressively.

The minimal SKILL.md structure looks like this:

---
name: my-skill-name
description: A clear description of what this skill does and when to use it
---

# My Skill Name

[Instructions that a compatible agent will follow when this skill is active]

## Examples

- Example usage 1
- Example usage 2

## Guidelines

- Guideline 1
- Guideline 2

The portable specification has two required fields:

The specification also defines optional license, compatibility, metadata, and experimental allowed-tools fields. The name must match its parent directory, use lowercase letters, numbers, and hyphens, and stay within 64 characters. The description can be up to 1,024 characters and should state both what the skill does and when it should activate.

The markdown body can include steps, decision trees, command sequences, examples, and pointers to bundled resources. Keep the entrypoint focused: the specification recommends a SKILL.md under 500 lines and moving detailed material into references/ so the agent loads it only when required.

Where Skills Run Today

The file format is portable, but installation paths and runtime features are product-specific:

A shared skill can keep the same core SKILL.md, scripts, references, and assets across products. Product-specific discovery paths, optional metadata, allowed tools, sandbox rules, and distribution still need separate adapters.

2. The Skills Ecosystem as of August 15, 2026

What Changed Since This Article Was Published

OpenAI also now exposes project-level CRUD and immutable version endpoints for skills. Anthropic’s API supports custom workspace skills, explicit versions, and container-based execution. Skills are no longer only local prompt folders; they are becoming managed operational artifacts.

The Open Specification: agentskills.io

The Agent Skills format is published at agentskills.io/specification. Any agent implementing the specification can consume its core directory structure and frontmatter. Portability does not guarantee identical behavior: triggering, tool permissions, sandboxing, installation, and product-only metadata still vary by host.

Anthropic’s Official Skills Library

Anthropic maintains examples at github.com/anthropics/skills. Claude Code also bundles a Claude API skill and supports project, personal, plugin, and enterprise skill scopes.

• skills/ — Production and example skills across Creative & Design, Development & Technical, Enterprise & Communication, and Document Skills categories
• spec/ — The agent-skills specification (points to agentskills.io)
• template/ — A starter template for building new skills

Notable technical examples include:

OpenAI’s Codex Plugins and Built-in Skills

OpenAI’s former openai/skills catalog is deprecated. Current distributable examples live in openai/plugins, where plugins can combine skills with apps, MCP configuration, agents, commands, hooks, and assets. System skills still ship with Codex, and $skill-installer remains available for curated local setup. Codex can invoke a skill explicitly with $skill-name or select it implicitly from its description.

Installing Project Skills

# Claude Code project scope
mkdir -p .claude/skills
cp -R skills/azure-terraform-defender .claude/skills/

# Codex project scope
mkdir -p .agents/skills
cp -R skills/azure-terraform-defender .agents/skills/

Both Claude Code and Codex support symlinked skill directories, so a repository can keep one canonical bundle and link it into both discovery paths instead of maintaining duplicate content. Commit those links or folders with the infrastructure code.

For marketplace distribution, use product packaging:

# Claude Code: install official skill-creator plugin
/plugin install skill-creator@claude-plugins-official

# Codex: install a curated skill
$skill-installer linear

3. Technology Trends Driving SRE/DevOps Skills Adoption in 2026

Trend 1 — Platform Engineering and Internal Developer Platforms (IDPs)

Platform teams are building skills that encode their org’s golden-path patterns. A skill might know your team’s Helm chart structure, your approved image registries, your naming conventions, and your rollout policies. Every engineer who loads the skill gets the same context, eliminating the “platform documentation nobody reads” problem.

Usage pattern: Skills are checked into the platform monorepo under the agent’s project discovery path. Wider distribution uses Claude Code plugins, Codex plugins, or managed enterprise configuration.

Trend 2 — Policy-as-Prompt: Security and Compliance Skills

Security teams are encoding compliance requirements (CIS Benchmarks, SOC 2 controls, NIST CSF, and cloud security baselines) into skills. The agent reviews and generates code through that lens, surfacing likely issues before a deterministic scan runs.

Usage pattern: CI invokes the skill for contextual review, then uses policy engines, provider validation, IaC scanners, and human approval as authoritative gates. A skill improves generation and triage; it is not a security control by itself.

Trend 3 — GitOps-Native Skills

Skills are versioned in Git alongside the infrastructure they describe. When a new module is added to a Terraform monorepo, the corresponding skill instructions and eval cases change in the same PR. Skills become executable documentation that compatible agents can act on.

Trend 4 — Multi-Cloud Skills Libraries

Enterprises are building skill libraries per cloud provider (one for Azure, one for AWS, one for GCP), each encoding that provider’s security defaults, resource naming rules, cost tagging standards, and approved services list. Engineers switch context by swapping skills, not rewriting prompts.

Trend 5 — Agentic SRE Workflows

SRE teams now run agent workflows non-interactively, on schedules, or from alert and repository events. A skill supplies runbook knowledge; the agent gathers evidence and proposes remediation within explicit tool, network, and approval boundaries.

# Claude Code discovers project skills from .claude/skills/
claude -p --output-format json --max-turns 10 \
  "Use the SRE runbook and Kubernetes operations skills. Investigate the
   high-error-rate alert for payments-api in namespace prod. Read-only triage:
   inspect pod logs, events, and recent deployments; return evidence and a
   remediation proposal. Do not change cluster state."

# Codex discovers repository skills from .agents/skills/
codex exec --sandbox read-only \
  "Use the SRE runbook skill to perform read-only triage of the payments-api alert."

For CI, OpenAI’s official openai/codex-action@v1 runs codex exec with configurable sandboxing. Keep untrusted alert text, issue bodies, and PR content outside privileged instructions; sanitize inputs and grant the narrowest permissions possible.

4. Functional Skills Every SRE/DevOps Engineer Should Know

Skill Category 1 — Kubernetes Operations

A Kubernetes ops skill teaches the agent your cluster topology, approved add-ons, naming conventions, and runbook patterns. When loaded, it can:

• Generate manifests that match your cluster’s resource quotas and LimitRange policies
• Write kubectl debugging sequences specific to your setup
• Produce PodDisruptionBudgets, NetworkPolicies, and HPA configs using your defaults
• Interpret kubectl describe and event output with awareness of your node pool sizes

Why a skill beats a one-off prompt: The skill carries the cluster context permanently. You don’t re-explain that your prod cluster has 32-CPU nodes and uses Karpenter instead of Cluster Autoscaler on every query.

Skill Category 2 — Incident Response and Runbooks

SRE skills encode the runbook library. A skill for the payments-api service knows:

• Its SLO (99.9% availability, p99 < 200 ms)
• Its alert definitions and their typical root causes
• The escalation path and on-call rotation lookup command
• The triage checklist for each alert class

When an alert fires, the engineer invokes the skill for a structured investigation plan with environment-specific commands, evidence requirements, stop conditions, and escalation rules.

Skill Category 3 — Infrastructure as Code (IaC) Review

An IaC review skill carries your module standards, approved resource configurations, and forbidden patterns. Examples of what it enforces:

• Every Azure Storage Account must have https_only = true, min_tls_version = "TLS1_2", allow_nested_items_to_be_public = false
• Every managed disk must use encryption_settings with a customer-managed key
• Every resource group must have a cost-center and environment tag

The agent applies these rules when generating or reviewing Terraform. Follow with terraform validate, provider tests, an IaC scanner, and policy-as-code; language-model review cannot prove compliance.

Skill Category 4 — CI/CD Pipeline Authoring

A CI/CD skill knows your approved Docker registries, your OIDC trust relationships, your environment promotion flow (dev → staging → prod), and your required pipeline stages (SAST, container scan, DAST, smoke test). It generates pipelines that match your org’s standards out of the box.

Skill Category 5 — Observability and Alerting

An observability skill encodes your Prometheus metrics naming conventions, Grafana layout standards, alerting severity taxonomy, and approved PromQL patterns. Compatible agents can then generate dashboards and alerts that fit the existing stack.

5. How Engineers Are Creating Skills Today

The Skill Creation Workflow

The real-world pattern adopted by most platform teams:

1. Start from the template — clone the template/SKILL.md from anthropics/skills
2. Extract existing documentation — provide runbooks, wiki pages, and module READMEs; distill stable procedure into SKILL.md and detailed facts into references/
3. Iterate with evals — run realistic trigger and non-trigger prompts in fresh sessions, then compare output quality, duration, and token cost with and without the skill
4. Version in Git — store skills in a skills/ directory at the root of the relevant repo
5. Package for distribution — use Claude Code or Codex plugins when the skill needs managed installation, connectors, hooks, agents, or supporting workflows

Using the skill-creator Meta-Skill

Both ecosystems provide skill-creation tooling. In Claude Code, the official skill-creator plugin can generate test cases, run isolated evaluations, grade assertions, benchmark with-skill versus without-skill behavior, and compare versions:

# Install the official Claude Code skill-creator plugin
/plugin install skill-creator@claude-plugins-official

# Use it to generate a new skill from your documentation
"Use the skill-creator skill to create a new skill for our Kubernetes platform.
 Here are our platform docs: [paste or attach docs]
 The skill should cover: cluster topology, approved add-ons, naming conventions,
 and common runbook patterns."

Codex includes $skill-creator as a system skill. Use either creator as a starting point, then review every instruction and bundled script before installation.

Anatomy of a Well-Structured SRE Skill

A good SRE or DevOps skill includes:

---
name: skill-name
description:
  [
    Precise description — this is used by Claude to decide when to activate the skill,
  ]
---

# Skill Title

## Context

[What environment, service, or system this skill applies to]

## Decision Tree

[A flowchart or numbered checklist Claude should follow for common tasks]

## Standards and Defaults

[Tables of approved values, naming conventions, required tags, etc.]

## Prohibited Patterns

[Explicit list of things Claude must never generate]

## Examples

[Two to three representative input/output examples]

## Reference Commands

[Frequently needed CLI commands with explanations]

The description frontmatter field is the most important part of any skill. It strongly influences automatic activation. Write it as a complete sentence that specifies scope and use cases: “Use this skill when generating or reviewing Terraform for Azure infrastructure against Microsoft Defender for Cloud recommendations and the organization’s approved security baseline.”

6. Building a Custom Skill — Terraform Azure Best Practices with Cloud Defender Compliance

This section walks through building a reviewable starting-point skill for a Terraform monorepo targeting Azure, with explicit rules intended to reduce common Microsoft Defender for Cloud (MDC) recommendations.

Why Defender for Cloud Matters

Microsoft Defender for Cloud (formerly Azure Security Center) assesses Azure resources against the Microsoft Cloud Security Benchmark (MCSB) and enabled regulatory standards. As of August 15, 2026, MCSB v2 is available in preview with expanded risk-based controls, Azure Policy mappings, and coverage for newer workloads including AI. Covered misconfigurations can generate security recommendations and affect secure score. Policies, recommendation names, effects, and provider fields change over time, so verify each rule against the standards enabled in your tenant. Common patterns include:

The Complete SKILL.md for Azure Terraform

Below is a starting-point SKILL.md you can drop into your Terraform repo as skills/azure-terraform-defender/SKILL.md, then validate and adapt to your tenant. The published version is available at github.com/YISUSVII/azure-terraform-defender:

---
name: azure-terraform-defender
description: >
  Use this skill when writing, reviewing, or refactoring Terraform code that
  provisions Azure resources. Apply Microsoft Cloud Security Benchmark (MCSB),
  tenant-enabled regulatory standards, and organization-approved Azure defaults.
  Activate whenever the user mentions Azure, the azurerm provider, ARM, or
  Defender for Cloud in a Terraform context. Treat findings as review guidance;
  verify them with current Azure Policy, AzureRM provider documentation,
  deterministic scans, and Terraform validation.
---

# Azure Terraform — Defender for Cloud Compliance Skill

## Scope

This skill applies to Terraform code using the `azurerm` provider. It encodes
preferred controls for compute, storage, networking, identity, and PaaS
services. It does not prove compliance or guarantee a recommendation-free
Defender for Cloud assessment.

## Mandatory Defaults

Apply ALL of the following defaults when generating or reviewing any resource
unless the user explicitly overrides them with a documented justification.

### Storage Accounts (`azurerm_storage_account`)

```hcl
resource "azurerm_storage_account" "example" {
  # ... required fields ...

  # MDC: "Secure transfer to storage accounts should be enabled"
  https_traffic_only_enabled = true

  # MDC: "Minimum TLS version should be TLS 1.2"
  min_tls_version = "TLS1_2"

  # MDC: "Storage account public access should be disallowed"
  allow_nested_items_to_be_public = false

  # MDC: "Storage accounts should use customer-managed key for encryption"
  # (configure via azurerm_storage_account_customer_managed_key if CMK required)

  # MDC: "Storage accounts should restrict network access"
  network_rules {
    default_action             = "Deny"
    bypass                     = ["AzureServices"]
    # ip_rules and virtual_network_subnet_ids added per use case
  }

  blob_properties {
    # MDC: "Soft delete for blobs should be enabled"
    delete_retention_policy {
      days = 30
    }
    # MDC: "Soft delete for containers should be enabled"
    container_delete_retention_policy {
      days = 30
    }
    versioning_enabled = true
  }
}
```

### Key Vaults (`azurerm_key_vault`)

```hcl
resource "azurerm_key_vault" "example" {
  # ... required fields ...

  # MDC: "Key vaults should have soft delete enabled"
  soft_delete_retention_days = 90

  # MDC: "Key vaults should have purge protection enabled"
  purge_protection_enabled = true

  # MDC: "Key vault firewall should be enabled"
  network_acls {
    default_action = "Deny"
    bypass         = ["AzureServices"]
  }

  # MDC: "Diagnostic logs in Key Vault should be enabled"
  # (add azurerm_monitor_diagnostic_setting separately)

  # Never set enable_rbac_authorization = false in prod
  enable_rbac_authorization = true
}
```

### SQL Servers (`azurerm_mssql_server`)

```hcl
resource "azurerm_mssql_server" "example" {
  # ... required fields ...

  # MDC: "An Azure Active Directory administrator should be provisioned"
  azuread_administrator {
    login_username = var.sql_admin_login
    object_id      = var.sql_admin_object_id
  }

  # MDC: "SQL servers should have auditing enabled"
  # Configure via azurerm_mssql_server_extended_auditing_policy

  # Never allow public network access unless explicitly required
  public_network_access_enabled = false

  minimum_tls_version = "1.2"
}

# MDC: "Auditing on SQL server should be enabled"
resource "azurerm_mssql_server_extended_auditing_policy" "example" {
  server_id                               = azurerm_mssql_server.example.id
  storage_endpoint                        = var.audit_storage_endpoint
  storage_account_access_key              = var.audit_storage_key
  storage_account_access_key_is_secondary = false
  retention_in_days                       = 90
}
```

### AKS Clusters (`azurerm_kubernetes_cluster`)

```hcl
resource "azurerm_kubernetes_cluster" "example" {
  # ... required fields ...

  # MDC: "Role-Based Access Control should be used on Kubernetes Services"
  role_based_access_control_enabled = true

  # MDC: "Azure Kubernetes Service clusters should have Defender profile enabled"
  microsoft_defender {
    log_analytics_workspace_id = var.log_analytics_workspace_id
  }

  # MDC: "Azure Active Directory integration should be enabled for AKS"
  azure_active_directory_role_based_access_control {
    managed            = true
    azure_rbac_enabled = true
  }

  # MDC: "AKS clusters should not allow container privilege escalation"
  # Enforce via Azure Policy add-on
  azure_policy_enabled = true

  # MDC: "AKS should use managed identities"
  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "azure"
    # MDC: "Authorized IP ranges should be defined on Kubernetes Services"
    # Set api_server_authorized_ip_ranges in production
  }

  # MDC: "Kubernetes Services should be upgraded to a non-vulnerable version"
  # Always pin to a supported minor version and keep current
  kubernetes_version = var.kubernetes_version
}
```

### Network Security Groups (`azurerm_network_security_group`)

```hcl
# MDC: "Management ports should be closed on your virtual machines"
# MDC: "SSH access from the internet should be blocked"
# MDC: "RDP access from the internet should be blocked"
# NEVER generate rules with:
#   source_address_prefix = "*" or "Internet" for port 22 or 3389
#
# Always scope inbound management traffic to known CIDR ranges or
# use Azure Bastion instead.

# Prohibited pattern — NEVER generate this:
# resource "azurerm_network_security_rule" "bad" {
#   ...
#   access                     = "Allow"
#   direction                  = "Inbound"
#   protocol                   = "Tcp"
#   destination_port_range     = "22"
#   source_address_prefix      = "*"  # <-- PROHIBITED
# }
```

### Diagnostic Settings (All PaaS Resources)

```hcl
# Azure Policy can raise recommendations when required diagnostic logs are missing.
# Add supported categories for resources covered by the tenant's logging policy.

resource "azurerm_monitor_diagnostic_setting" "example" {
  name                       = "${var.resource_name}-diag"
  target_resource_id         = azurerm_key_vault.example.id
  log_analytics_workspace_id = var.log_analytics_workspace_id

  enabled_log {
    category = "AuditEvent"
  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}
```

### Required Resource Tags

Every taggable resource MUST include the required tags. Resource-group tags do not automatically propagate to child resources. Pass `created_date` as a stable input from release automation; calling `timestamp()` directly would create a new value and a perpetual Terraform diff.

```hcl
tags = {
  environment    = var.environment # dev | staging | prod
  "cost-center"  = var.cost_center
  owner           = var.owner_email
  "managed-by"   = "terraform"
  "created-date" = var.created_date
}
```

## Prohibited Patterns

**Reject and flag any of the following when reviewing Terraform code:**

1. `https_traffic_only_enabled = false` on any storage account
2. `allow_nested_items_to_be_public = true` on any storage account
3. `purge_protection_enabled = false` on any key vault
4. `soft_delete_retention_days < 7` on any key vault
5. `public_network_access_enabled = true` on SQL servers without explicit CIDR allow-listing
6. NSG rules with `source_address_prefix = "*"` or `"Internet"` on ports 22, 3389, 5985, 5986
7. `role_based_access_control_enabled = false` on any AKS cluster
8. Service principals with client secret credentials instead of managed identities where Azure supports MSI
9. Any `azurerm_role_assignment` with `role_definition_name = "Owner"` — prefer least-privilege built-in roles
10. Taggable resources deployed without the required tag set

## Review Checklist

When reviewing a Terraform plan or module, work through this checklist:

- [ ] All storage accounts: HTTPS-only, min TLS 1.2, no public blob, network deny-all default, soft delete enabled
- [ ] All key vaults: soft delete, purge protection, firewall deny-all default, RBAC auth
- [ ] All SQL/PostgreSQL servers: AAD admin, auditing policy, TLS 1.2 minimum, no public access
- [ ] All AKS clusters: RBAC, Azure AD integration, Defender profile, Azure Policy add-on, managed identity
- [ ] NSG rules: no wildcard source for management ports
- [ ] Diagnostic settings: present with supported categories for resources covered by logging policy
- [ ] Tags: all required tags present on every taggable resource; no `timestamp()`-driven perpetual diff
- [ ] No Owner/Contributor role assignments without documented justification

## Remediations for Common MDC Alerts

| MDC Recommendation                                         | Terraform Resource to Add or Update                                     |
| ---------------------------------------------------------- | ----------------------------------------------------------------------- |
| "Secure transfer to storage accounts should be enabled"    | Set `https_traffic_only_enabled = true`                                 |
| "Storage account public access should be disallowed"       | Set `allow_nested_items_to_be_public = false`                           |
| "Key vaults should have purge protection enabled"          | Set `purge_protection_enabled = true`                                   |
| "SQL servers should have auditing enabled"                 | Add `azurerm_mssql_server_extended_auditing_policy`                     |
| "Diagnostic logs should be enabled"                        | Add `azurerm_monitor_diagnostic_setting`                                |
| "Management ports should be closed"                        | Remove or restrict NSG rules for ports 22/3389                          |
| "AKS should use Azure AD integration"                      | Add `azure_active_directory_role_based_access_control` block            |
| "Vulnerabilities in container images should be remediated" | Enable applicable Defender plans and fix findings in the image pipeline |

Using the Skill in Claude Code and Codex

Once the skill file is in place:

cd ~/repos/my-terraform-azure-repo
mkdir -p .claude/skills .agents/skills
ln -s ../../skills/azure-terraform-defender .claude/skills/azure-terraform-defender
ln -s ../../skills/azure-terraform-defender .agents/skills/azure-terraform-defender

Then ask either agent to generate or review Terraform. Explicit invocation is useful when the task is high stakes:

# Claude Code
/azure-terraform-defender Review ./modules/aks/main.tf. Return findings with file,
line, evidence, recommendation, and proposed fix. Do not modify files.

# Codex
$azure-terraform-defender Review ./modules/aks/main.tf. Return findings with file,
line, evidence, recommendation, and proposed fix. Do not modify files.

Treat findings as review input. Confirm them against the current Azure Policy definition, Defender for Cloud recommendation, AzureRM provider schema, and the Terraform plan before making a compliance claim.

Using the Skill via the Claude API

For CI/CD integration, upload the complete skill directory once, store its skill_id, and pin a specific version in production. The current Claude API requires Skills to run through the code-execution container:

import anthropic
from anthropic.lib import files_from_dir

client = anthropic.Anthropic()

# Create once; publish a new immutable version when the bundle changes.
skill = client.beta.skills.create(
    files=files_from_dir("skills/azure-terraform-defender"),
)

def check_terraform_pr(changed_files: str) -> str:
    response = client.beta.messages.create(
        model="claude-opus-5",
        max_tokens=4096,
        betas=["code-execution-2025-08-25", "skills-2025-10-02"],
        container={
            "skills": [
                {
                    "type": "custom",
                    "skill_id": skill.id,
                    "version": "latest",  # Pin an immutable version in production.
                }
            ]
        },
        messages=[
            {
                "role": "user",
                "content": (
                    "Review the following Terraform changes for Microsoft Defender "
                    "for Cloud compliance issues. For each finding, include: "
                    "file name, resource, the specific MDC recommendation it would "
                    "trigger, and the exact fix.\n\n"
                    f"```hcl\n{changed_files}\n```"
                ),
            }
        ],
        tools=[{"type": "code_execution_20250825", "name": "code_execution"}],
    )
    return "\n".join(block.text for block in response.content if block.type == "text")

# In your GitHub Actions workflow:
# - Run terraform fmt -check and terraform validate.
# - Run deterministic IaC and policy-as-code checks.
# - Pass the diff or redacted plan to check_terraform_pr() for contextual review.
# - Publish findings for human review; do not parse free-form prose as the only gate.

GitHub Actions Integration

Two supported patterns now exist:

1. Call the Claude Messages API with the pinned custom skill as shown above.
2. Commit the skill under .agents/skills/ and run openai/codex-action@v1; the action checks out the repository, discovers the skill, and runs codex exec with the configured sandbox.

For either path, restrict workflow triggers to trusted users, sanitize PR and issue text to reduce prompt-injection risk, keep cloud credentials out of model-visible context, use read-only permissions for review jobs, pin dependencies, and require deterministic checks before apply.

7. Key Takeaways

Agent Skills represent a shift in how infrastructure engineers work with coding agents. Rather than writing elaborate prompts from scratch for every session, teams can build versioned operational packages that encode domain knowledge — from Kubernetes topology to cloud security baselines — and reuse them across Claude Code, Codex, and hosted APIs.

For SRE and DevOps engineers the most impactful applications in 2026 are:

• Safer IaC generation — Skills push preferred defaults into the first draft, while scanners and policy engines remain the compliance gate.
• Bounded runbook execution — Skills carry incident context, evidence requirements, stop conditions, and escalation paths into agent-assisted triage.
• Cross-agent portability — One core skill bundle can serve multiple compatible agents, with thin adapters for discovery paths and product-specific metadata.
• Testable platform knowledge — Trigger evals, output assertions, and version pinning let teams review skills with discipline similar to infrastructure code.

The Azure Terraform Defender skill shown here is a starting point, available at github.com/YISUSVII/azure-terraform-defender. Fork it, align every rule with current Azure and provider documentation, add your naming and policy requirements, build eval cases, pin released versions in CI, and expose it through both .claude/skills/ and .agents/skills/ when your team uses both agents.

Published March 2026. Updated August 15, 2026. See also: Top Tech Publications to Follow in 2026.