@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-dynamodb-data-modeling-performance-review/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
-- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html
-- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-indexes.html
-- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html
+- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/data-modeling.html
+- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-table-design.html
+- https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html
+- https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-data-modeling/best-practices.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- DynamoDB data modeling guidance centers schema design on access patterns, partition keys, sort keys, secondary indexes, and single-table versus multi-table tradeoffs.
+- Global secondary indexes support alternate partition/sort key schemas and projected attributes, but have throughput, storage, and synchronization considerations.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon DynamoDB as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `DynamoDB+DescribeTable` and `DynamoDB+Query` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not approve table design without enumerated access patterns, key cardinality/skew analysis, query-vs-scan proof, index write amplification, capacity mode, and cost/latency tradeoffs.
+- Live table status, throttling, consumed capacity, and hot partitions must come from live metrics or repo/IaC evidence, not docs.

package/skills/aws/aws-dynamodb-data-modeling-performance-review/references/safety-checklist.md

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-dynamodb-data-modeling-performance-review/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-ec2-compute-operations-steward/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon EC2 compute operations across instances, Auto Scaling
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [EC2 Fleet Operations Safety Guide](references/ec2-fleet-operations-safety.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ec2-compute-operations-steward/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review EC2, Auto Scaling, Launch Templates, AMIs, Systems Manager, Patch Manager, EBS, snapshots, health checks, instance refresh, lifecycle hooks, and fleet operations.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-best-practices.html",
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html",
-    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-refresh-overview.html",
-    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html"
+    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html",
+    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html",
+    "https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html",
+    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html"
   ],
   "security_notes": "Do not approve EC2 fleet operations without patch compliance, managed access, health checks, rollback, backup/snapshot posture, IAM instance-profile review, and launch-template evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ec2-compute-operations-steward",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ec2-compute-operations-steward/references/ec2-fleet-operations-safety.md

@@ -0,0 +1,59 @@
+# EC2 Fleet Operations Safety Guide
+
+Use this reference for EC2, Auto Scaling groups, Launch Templates, AMIs, Systems Manager, Patch Manager, Session Manager, EBS volumes/snapshots, instance refresh, lifecycle hooks, health checks, and fleet reliability reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> EC2 is legacy; patch it, refresh it, or replace instances.
+
+Wrong. EC2 fleets hide state, pets, bootstrap drift, manual access paths, patch gaps, EBS coupling, and Auto Scaling rollout risk. Treat every host operation as potentially stateful until proven otherwise.
+
+Common bad assumptions:
+
+- Instance refresh is always safer than manual replacement.
+- Latest AMI means compliant and compatible.
+- SSM managed node status proves patch posture.
+- Session Manager removes all SSH/bastion risk.
+- EBS snapshots prove application-consistent recovery.
+- Auto Scaling health checks match customer health.
+
+## EC2 operations failure modes
+
+- Launch Template update changes IAM, user data, security groups, block devices, or AMI unexpectedly.
+- Instance refresh drains capacity without lifecycle hooks, warmup, health checks, or rollback target.
+- Patch Manager compliance misses unmanaged nodes, maintenance windows, or reboot requirements.
+- Session Manager lacks logging, KMS, VPC endpoint, or least-privilege controls.
+- EBS volume performance, burst balance, attachment, encryption, or snapshot consistency is ignored.
+- Pets/manual changes create drift from AMI/bootstrap expectations.
+
+## Minimum safe workflow
+
+1. Identify fleet: instances, Auto Scaling groups, Launch Templates, AMIs, subnets, load balancers, and stateful dependencies.
+2. Review access/management: SSM managed node status, Session Manager, IAM instance profile, patch baseline, and logging.
+3. Review rollout safety: instance refresh settings, lifecycle hooks, health checks, desired/min/max capacity, warm pools, and rollback AMI/template version.
+4. Check storage/recovery: EBS volumes, snapshots, encryption, application consistency, and attachment behavior.
+5. Review observability: EC2 status checks, CloudWatch agent, logs, alarms, load balancer target health, and application health.
+6. Recommend staged, reversible changes; stop/terminate/reboot/refresh actions require explicit approval.
+7. Separate host configuration evidence from live workload health evidence.
+
+## Verification targets
+
+- EC2 instance state, status checks, AMI, user data, IAM instance profile, security groups, tags, and SSM managed node status
+- Auto Scaling group desired/min/max capacity, Launch Template version, instance refresh, lifecycle hooks, warmup, health check type, and rollback target
+- Systems Manager Patch Manager baseline, compliance, maintenance windows, State Manager associations, Inventory, and Session Manager logging/KMS settings
+- EBS volume type, size, IOPS/throughput, burst balance, encryption, snapshots, and application-consistent backup evidence
+- load balancer target health, CloudWatch metrics/logs, CloudWatch agent, alarms, and recent change/deployment timeline
+- SSH/bastion exposure, Session Manager endpoint policy, VPC endpoints, and break-glass path
+
+## When to push back
+
+Push back if the user asks to:
+
+- terminate/reboot/refresh instances without state and capacity proof
+- roll forward to latest AMI without compatibility and rollback target
+- ignore unmanaged nodes in patch reports
+- disable health checks or lifecycle hooks to speed rollout
+- treat EBS snapshots as application-consistent without evidence
+- broaden SSH/Session Manager access for convenience

package/skills/aws/aws-ec2-compute-operations-steward/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-best-practices.html
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html
-- https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-refresh-overview.html
-- https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html
+- https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
+- https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html
+- https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html
+- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- EC2 Auto Scaling manages EC2 capacity automatically through groups, health checks, scaling policies, and instance lifecycle behavior.
+- Auto Scaling launch failures can come from unsupported configurations, missing security groups or key pairs, unsupported instance/AZ combinations, Spot capacity, encrypted EBS permission errors, and instance limits.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon EC2, AWS Systems Manager, and Amazon EC2 Auto Scaling as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `EC2+DescribeInstances`, `SSM+DescribeInstanceInformation`, and `Auto Scaling+DescribeAutoScalingGroups` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not treat EC2 fleets as managed unless SSM registration, patch compliance, AMI/launch-template currency, health checks, alarms, backups/snapshots, and rollback paths are evidenced.
+- Operations guidance must separate observation from mutation; remediation actions such as instance refresh, stop/start, termination, or patching need explicit approval gates.

package/skills/aws/aws-ec2-compute-operations-steward/references/safety-checklist.md

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-ec2-compute-operations-steward/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-ecs-fargate-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon ECS and Fargate platform operations across services,
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [ECS Fargate Service Safety Guide](references/ecs-fargate-service-safety.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ecs-fargate-platform-operator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review Amazon ECS and Fargate services across task roles, execution roles, deployment circuit breakers, blue/green, load balancing, autoscaling, logging, networking, and rollback.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-roles.html"
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html"
   ],
   "security_notes": "Do not approve ECS/Fargate production changes without task-role separation, deployment rollback behavior, health check evidence, logs, secrets posture, and load balancer/target group validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ecs-fargate-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ecs-fargate-platform-operator/references/ecs-fargate-service-safety.md

@@ -0,0 +1,59 @@
+# ECS Fargate Service Safety Guide
+
+Use this reference for Amazon ECS/Fargate platform reviews covering services, task definitions, task role vs execution role, capacity providers, load balancers, deployment circuit breakers, blue/green, autoscaling, health checks, logs, secrets, networking, and rollback.
+
+## What people get wrong
+
+The lazy story is:
+
+> ECS service stable means the platform is healthy.
+
+Wrong. Stable desired count can hide overprivileged task roles, broken health checks, missing circuit breakers, wrong image tags, secret exposure, capacity-provider drift, and weak rollback.
+
+Common bad assumptions:
+
+- Task role and execution role can share permissions.
+- Latest task definition revision is safe.
+- Fargate removes capacity and networking concerns.
+- ALB health checks prove application correctness.
+- Circuit breaker is enough without alarms and rollback validation.
+- Secrets in task definition references are safe without IAM/KMS review.
+
+## ECS/Fargate failure modes
+
+- Execution role cannot pull images, publish logs, or fetch secrets; task role has broad app permissions.
+- Task definition changes CPU/memory, ports, env vars, logging, secrets, or image tag unexpectedly.
+- Deployment min/max healthy percent, circuit breaker, or CodeDeploy blue/green settings cause outage or no rollback.
+- Target group health check path/port/grace period hides app startup failure.
+- Subnet/security group/assignPublicIp/service discovery settings expose or isolate tasks incorrectly.
+- Autoscaling follows CPU while bottleneck is queue depth, latency, memory, or downstream throttling.
+
+## Minimum safe workflow
+
+1. Identify cluster, service, launch type, deployment controller, task definition family, target groups, and capacity provider strategy.
+2. Review task definition diffs: image digest/tag, CPU/memory, ports, env/secrets, logs, roles, health checks, and platform version.
+3. Separate execution role from task role and verify least privilege for ECR, CloudWatch Logs, Secrets Manager, SSM, KMS, and app APIs.
+4. Check deployment safety: circuit breaker, alarms, desired count, min/max healthy percent, blue/green hooks, and rollback revision.
+5. Review networking and exposure: subnets, security groups, public IPs, load balancer, service discovery, and VPC endpoints.
+6. Validate observability: service events, stopped task reasons, target health, logs, metrics, and deployment state changes.
+7. Require approval before update-service, force-new-deployment, task definition registration, or scaling changes.
+
+## Verification targets
+
+- ECS service definition, deployments, events, desired/running/pending counts, deployment controller, and circuit breaker
+- task definition image digest, CPU/memory, roles, secrets, logging, health checks, ports, volumes, and platform version
+- task execution role and task role IAM/KMS/Secrets Manager/ECR/CloudWatch Logs permissions
+- ALB/NLB target groups, health check path/port/grace, listener rules, and target health
+- capacity providers, Fargate/Fargate Spot mix, autoscaling policies, CloudWatch alarms, and queue/business metrics
+- CodeDeploy AppSpec, lifecycle hooks, alarms, rollback config, and previous task definition target
+
+## When to push back
+
+Push back if the user asks to:
+
+- force new deployment without root-cause evidence
+- widen task or execution role blindly
+- deploy mutable image tags without digest/provenance
+- disable health checks or circuit breakers to reach steady state
+- scale desired count to hide crash loops
+- treat service stable as proof of security or readiness

package/skills/aws/aws-ecs-fargate-platform-operator/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-failure-detection.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-blue-green.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/security-iam-roles.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- Fargate for ECS provides serverless container management with task definitions, platform versions, capacity providers, service load balancing, and usage metrics.
+- The ECS task execution role lets the ECS agent perform AWS API calls such as pulling ECR images, retrieving Secrets Manager or Systems Manager values, and accessing configured storage; it is distinct from the application task role.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon ECS and AWS Fargate as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ECS+DescribeServices` and `ECS+DescribeTasks` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Require evidence for task role vs execution role separation, image-pull path, secrets access, network mode/security groups, load balancer health, deployment controller, circuit breaker/rollback, logs, and autoscaling.
+- Fargate availability does not prove platform-version compatibility, quota, subnet capacity, or service health in the user's account.

package/skills/aws/aws-ecs-fargate-platform-operator/references/safety-checklist.md

@@ -5,10 +5,10 @@ Use this reference before privileged, destructive, traffic-changing, cost-changi
 ## Non-negotiables
 
 - Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
-- Prefer official AWS MCP tools when exposed by the active runtime. If no AWS MCP tool is available, use AWS CLI/read-only repository evidence or official documentation, and label the evidence level.
+- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
 - Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
 - Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting actions.
-- Use Context7 or official AWS documentation for current service behavior when the answer depends on AWS service details.
+- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
 - Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.
 
 ## Stress checks

package/skills/aws/aws-ecs-fargate-platform-operator/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-ecs-service-remediation-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Correct AWS ECS and Fargate service definitions, task definition co
 allowed-tools: Read Edit Write MultiEdit Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -25,7 +25,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - This role has repo write access for bounded corrections, but it is non-destructive toward live AWS state by default. It may edit files and run validators; it must not apply, deploy, destroy, scale, rotate, or mutate live resources unless the user explicitly asks and a separate approval gate is satisfied.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, hidden blast radius, unsafe hotfixes, and vague production claims.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full patch workflow, validation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, production-impacting, or rollback-sensitive recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [ECS Remediation Playbook](references/ecs-remediation-playbook.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ecs-service-remediation-operator/metadata.json

@@ -14,13 +14,14 @@
   "summary": "Correct ECS/Fargate service definitions, task settings, deployment parameters, and environment configuration in-repo with bounded write access and no live service mutation by default.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html",
-    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html"
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html",
+    "https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html"
   ],
   "security_notes": "Repo write access only. Do not force new deployments, scale services, or alter live task state from this role by default. Surface rollout and rollback implications explicitly.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ecs-service-remediation-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-ecs-service-remediation-operator/references/ecs-remediation-playbook.md

@@ -0,0 +1,59 @@
+# ECS Remediation Playbook
+
+Use this reference when correcting ECS/Fargate task definitions, services, deployment parameters, load balancer health checks, secrets, logging, capacity providers, or CodeDeploy blue/green wiring in repository files.
+
+## What people get wrong
+
+The lazy story is:
+
+> ECS service is unhealthy, so tweak desired count or task definition and redeploy.
+
+Wrong. ECS failures often come from task role/execution role confusion, image pull, secrets, target health, capacity provider, deployment controller, or container health checks.
+
+Common bad assumptions:
+
+- Task role and execution role are interchangeable.
+- Increasing desired count fixes failing tasks.
+- Health check grace period can hide root cause.
+- Latest task definition revision is automatically safe.
+- Container logs are enough without service events and target health.
+- A repo service definition fix authorizes forcing a new deployment.
+
+## Failure-mode map
+
+- **Image pull:** ECR permissions, VPC endpoints, registry creds, platform architecture.
+- **Startup:** env var/secrets, command/entrypoint, health check, dependency readiness.
+- **Networking:** subnet, security group, assignPublicIp, target group, service discovery.
+- **IAM:** task role for app calls, execution role for pull/log/secrets.
+- **Capacity:** Fargate quota, capacity provider weights/base, CPU/memory mismatch.
+- **Deployment:** circuit breaker, min/max healthy percent, CodeDeploy task sets, alarms.
+
+## Minimum safe workflow
+
+1. Identify service, cluster, launch type, deployment controller, and task definition family.
+2. Correlate service events, stopped-task reasons, target health, and logs before patching.
+3. Patch only the repo field tied to the evidence.
+4. Preserve rollback task definition or previous service config.
+5. Validate IaC/task-definition schema and project tests.
+6. State whether force-new-deployment/register-task-definition/update-service is still required and approval-gated.
+
+## Verification targets
+
+- task definition: image, CPU/memory, roles, secrets, logs, health checks, ports
+- service definition: desired count, deployment config, circuit breaker, capacity providers, subnets/security groups
+- load balancer target group health and health check path/port
+- CodeDeploy AppSpec and task set config for blue/green
+- CloudWatch logs and ECS service events/stopped-task reasons
+- validation commands for CloudFormation/CDK/Terraform/task definition JSON
+
+## When to push back
+
+Push back if the user asks to:
+
+- force a new deployment without root-cause evidence
+- disable health checks or circuit breaker to get green status
+- swap task/execution role permissions blindly
+- increase desired count to mask crash loops
+- remove secrets/logging to simplify a task definition
+- deploy latest task revision without rollback target
+

package/skills/aws/aws-ecs-service-remediation-operator/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html
-- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-ecs.html
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
+
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-deployment.html
+- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html
+
+## Grounding rule
+
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- ECS troubleshooting guidance covers task, service, agent, Docker, EBS, Service Connect, Fargate, and throttling errors as distinct failure classes.
+- ECS service deployments track lifecycle states, circuit breaker failures, CloudWatch alarms, rollbacks, and service history for recent deployments.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon ECS, AWS Fargate, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `ECS+DescribeServices`, `ECS+DescribeTasks`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Repo-side fixes must identify the failing service/task-definition field, expected deployment behavior, validation command, and rollback diff; they must not force live service updates by default.
+- Do not infer root cause from one ECS error string; correlate service events, stopped-task reasons, target health, deployment controller, task/execution roles, image pull, secrets, and logs.

package/skills/aws/aws-eks-platform-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon EKS Kubernetes platform operations across cluster acc
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: platform
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, public exposure, destructive automation, untested recovery, hidden cost, and vague production claims.
 - Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [EKS Platform Operations Guide](references/eks-platform-operations.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-eks-platform-operator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review Amazon EKS platform operations across cluster identity, access entries, node strategy, networking, autoscaling, upgrades, reliability, security, observability, and cost.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/eks/latest/best-practices/introduction.html",
-    "https://docs.aws.amazon.com/eks/latest/best-practices/security.html",
-    "https://docs.aws.amazon.com/eks/latest/best-practices/reliability.html",
+    "https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html",
+    "https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html",
+    "https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html",
     "https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html"
   ],
   "security_notes": "Do not call an EKS cluster production-ready without explicit identity, network isolation, upgrade, node disruption, image/runtime security, and observability evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-eks-platform-operator",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }