AGENTS.md@rules ยท diff
git:20261028.d2eaec0 to git:20261029.af52e7c
10 added, 6 removed. Audit A to A.
- # AWS & EKS Guidance
+ # 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 (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.
+ 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 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.