git:20260624.d9f3fc2 to git:20261028.d2eaec0

22 added, 13 removed. Audit A to A.

# AWS & EKS Guidance
- - Prefer the AWS MCP Server for AWS interactions — it provides scoped
+ - 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.
- - Before starting a task, check whether a relevant AWS skill is available.
- Prefer skill guidance over general knowledge.
- - Prefer the EKS MCP Server for live cluster interactions — it provides
- Kubernetes API access (read by default, write if configured), upgrade
- insights, and cluster discovery. If unavailable, use kubectl and AWS
- CLI directly.
- - Before starting an EKS task, check whether a relevant APEX skill is
- available. Skills are installed at `~/.claude/skills/` (Claude Code)
- or `~/.kiro/skills/` (Kiro). Prefer skill guidance over general
- knowledge.
+ - Prefer the EKS MCP Server for live cluster interactions: it provides
+ Kubernetes API access (read or write, depending on how the server is
+ configured), upgrade insights, and cluster discovery. If 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.
- 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 execute destructive operations (node drain, cluster delete, force
- eviction) without explicit user confirmation.
+ - Never execute destructive operations (for example node drain, cluster or
+ service delete, stack delete, force eviction) without explicit user
+ confirmation.
- 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.