git:20261029.af52e7c to git:20261029.4d40373

# AWS, EKS & ECS Guidance

- For EKS, ECS or APEX skill requests (including one that names a single

skill), load the skill named exactly `apex` first if it is installed: it

routes to the matching skill and holds the shared APEX rules. The

`/apex:*` commands of a v1 install, such as `apex:eks`, are not it. If it

is not installed, use the matching skill directly; the router's extra

rules are then not loaded, but the rules in this file still apply.

- Before any task, check for a relevant AWS or APEX skill.

APEX skills are installed at `~/.claude/skills/` (Claude Code),

`~/.kiro/skills/` (Kiro) or `~/.agents/skills/` (Codex, by a manual copy),

or under `.claude/skills/` or `.kiro/skills/` in the project for an

`npx apex-skills@1.3.0 --project` install. Prefer skill

guidance over general knowledge.

- Prefer the AWS MCP Server for AWS interactions: it provides scoped

IAM access and CloudTrail-compatible audit logging. If unavailable,

use the AWS CLI directly.

- Prefer the EKS MCP Server for live cluster interactions: it provides

Kubernetes API access (the self-hosted server is read-only unless run

with `--allow-write`; the AWS-hosted server allows the write tools its

IAM policy grants unless the MCP Proxy for AWS runs it with

`--read-only`), upgrade insights, and cluster discovery. If the user

wants live cluster reads and its tools are missing, ask the user

whether they are willing and interested to install the EKS MCP Server:

if yes, load the `eks-mcp-server` skill to set it up; if no, use

kubectl and the AWS CLI directly, except for `eks-operation-review`,

which needs the EKS MCP server and stops at its pre-flight (its runbook, Pre-flight Action 3).

- When uncertain about specific AWS details (API parameters, permissions,

limits, error codes), verify against documentation rather than guessing.

State uncertainty explicitly if you cannot confirm.

- When uncertain about specific EKS details (add-on versions, API parameters,

Karpenter behavior, VPC CNI settings), verify against upstream source repos

rather than guessing. Cross-reference the upstream repo to confirm the

behavior still holds in the current release:

- Karpenter: `github.com/aws/karpenter-provider-aws`

- VPC CNI: `github.com/aws/amazon-vpc-cni-k8s`

- AWS Load Balancer Controller: `github.com/kubernetes-sigs/aws-load-balancer-controller`

- CoreDNS: `github.com/coredns/coredns`

- EKS AMI: `github.com/awslabs/amazon-eks-ami`

- EKS Terraform module: `github.com/terraform-aws-modules/terraform-aws-eks`

- When creating infrastructure, prefer infrastructure-as-code (Terraform with

`terraform-aws-modules/terraform-aws-eks`, AWS CDK, or CloudFormation) over

direct CLI commands.

- When working with infrastructure, follow AWS Well-Architected Framework

principles.

- Never output secrets, credentials, or kubeconfig contents in responses.

- Avoid non-ASCII characters (including em dashes) in AWS resource names

and descriptions. Use hyphens instead.