@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-migration-cutover-architect/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Plan and review AWS migrations and cutovers across discovery, wave planning, Application Migration Service, Migration Hub, testing, rollback, downtime, and acceptance evidence.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/mgn/latest/ug/best_practices_mgn.html",
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-database-rehost-tools/mgn.html",
-    "https://docs.aws.amazon.com/decision-guides/latest/migration-on-aws-how-to-choose/migration-on-aws-how-to-choose.html",
-    "https://docs.aws.amazon.com/whitepapers/latest/aws-overview/migration-services.html"
+    "https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html",
+    "https://docs.aws.amazon.com/mgn/latest/ug/getting-started.html",
+    "https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-cutover-runbook/welcome.html",
+    "https://docs.aws.amazon.com/prescriptive-guidance/latest/cutover-traffic/welcome.html"
   ],
   "security_notes": "Do not approve migration cutover without dependency evidence, tested launch, acceptance checks, rollback, security baseline, observability, and clear business owner signoff.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-migration-cutover-architect",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-migration-cutover-architect/references/migration-cutover-readiness.md

@@ -0,0 +1,59 @@
+# Migration Cutover Readiness Guide
+
+Use this reference for AWS migration and cutover planning across Application Migration Service, Migration Hub, wave planning, test launches, DNS, data consistency, acceptance tests, downtime windows, rollback, and post-cutover validation.
+
+## What people get wrong
+
+The lazy story is:
+
+> Replication is healthy, so the cutover is ready.
+
+Wrong. Healthy replication is only one prerequisite. Cutover fails on dependencies, identity, DNS, data consistency, acceptance criteria, rollback authority, and stakeholder timing.
+
+Common bad assumptions:
+
+- Application Migration Service launch success proves application acceptance.
+- DNS TTL change is a small operational detail.
+- Rollback means power on the source again.
+- Migration Hub status proves business readiness.
+- Test launch can be skipped if the workload is simple.
+- Data consistency is a database team problem only.
+
+## Migration-specific failure modes
+
+- Dependency map misses batch jobs, file shares, identity providers, DNS, certificates, licenses, firewall rules, or third-party integrations.
+- Test launch differs from production cutover subnet, IAM, security group, DNS, or load balancer path.
+- Source and target accept writes simultaneously without reconciliation plan.
+- Cutover window lacks owner, go/no-go criteria, rollback decision point, or communication plan.
+- Route 53/DNS, TTL, cache, certificate, and client endpoint behavior are untested.
+- Post-cutover monitoring cannot distinguish migration regression from normal workload behavior.
+
+## Minimum safe workflow
+
+1. Define wave scope: applications, servers, databases, dependencies, owners, downtime budget, and business acceptance criteria.
+2. Verify replication health, test launches, target configuration, security controls, and performance baseline.
+3. Build cutover runbook with timestamps, owners, commands, validation checks, decision points, and rollback criteria.
+4. Plan DNS/traffic switch, data freeze, final sync, app startup, smoke tests, and stakeholder communication.
+5. Define rollback before execution: source state, write reconciliation, DNS reversal, target shutdown, and data-loss risk.
+6. Validate post-cutover: functional tests, latency/errors, logs, security controls, backup, monitoring, and user acceptance.
+7. Keep destructive migration steps approval-gated and evidence-based.
+
+## Verification targets
+
+- Application Migration Service source server state, replication health, launch template, test launch, cutover launch, and post-launch actions
+- Migration Hub wave/application status, owner mapping, dependencies, and automation unit outputs where used
+- source/target network, IAM, security groups, routes, DNS, certificates, load balancers, and secrets
+- database/file/data consistency plan, freeze window, final sync, and reconciliation evidence
+- acceptance tests, smoke tests, performance baseline, monitoring dashboards, and rollback runbook
+- stakeholder communication plan, support coverage, change record, and go/no-go approvals
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve cutover from replication health alone
+- skip test launch or acceptance tests
+- change DNS without TTL/cache rollback plan
+- run source and target writes without reconciliation
+- hide rollback data-loss risk from stakeholders
+- treat Migration Hub status as business acceptance

package/skills/aws/aws-migration-cutover-architect/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/mgn/latest/ug/best_practices_mgn.html
-- https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-database-rehost-tools/mgn.html
-- https://docs.aws.amazon.com/decision-guides/latest/migration-on-aws-how-to-choose/migration-on-aws-how-to-choose.html
-- https://docs.aws.amazon.com/whitepapers/latest/aws-overview/migration-services.html
+- https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
+- https://docs.aws.amazon.com/mgn/latest/ug/getting-started.html
+- https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-cutover-runbook/welcome.html
+- https://docs.aws.amazon.com/prescriptive-guidance/latest/cutover-traffic/welcome.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:
+- AWS Application Migration Service is an automated lift-and-shift service for migrating physical, virtual, or cloud servers to AWS.
+- MGN getting-started guidance covers initialization, launch templates/settings, best practices, quotas, and scaling migration workflows.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Application Migration Service as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `mgn+DescribeSourceServers` and `Migration Hub Refactor Spaces+ListApplications` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Cutover readiness requires replication health, launch template correctness, DNS/network plan, data freeze, test launch results, rollback/rollback-window plan, owner approvals, and business validation.
+- Service availability does not prove source servers are replicated, tested, or ready to cut over.

package/skills/aws/aws-migration-cutover-architect/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, 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-migration-cutover-architect/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-network-architect/SKILL.md

@@ -4,8 +4,8 @@ description: Design, review, and troubleshoot AWS network, hybrid, and multi-clo
 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: networking
 ---
 
@@ -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.
+- [Network Routing and DNS Guide](references/network-routing-and-dns.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-network-architect/metadata.json

@@ -14,16 +14,14 @@
   "summary": "Design and review AWS VPC, Transit Gateway, Direct Connect, VPN, Cloud WAN, Route 53 Resolver, private DNS, routing, private endpoints, segmentation, ingress, egress, inspection, and hybrid/multi-cloud connectivity patterns.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html",
-    "https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html",
-    "https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html",
-    "https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html",
-    "https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html",
-    "https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html"
+    "https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html",
+    "https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html",
+    "https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html",
+    "https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html"
   ],
   "security_notes": "Do not recommend public exposure, broad routes, overlapping CIDRs, route propagation, hybrid connectivity, DNS forwarding, or centralized inspection changes without traffic-flow evidence, rollback, and blast-radius analysis.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-network-architect",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-network-architect/references/network-routing-and-dns.md

@@ -0,0 +1,59 @@
+# Network Routing and DNS Guide
+
+Use this reference for AWS network architecture reviews involving VPCs, subnets, route tables, Transit Gateway, Direct Connect, Site-to-Site VPN, Cloud WAN, Route 53 Resolver, private endpoints, ingress, egress, and inspection paths.
+
+## What people get wrong
+
+The lazy story is:
+
+> If packets route in the diagram, the network design is fine.
+
+Wrong. AWS networking fails at the boundaries: overlapping CIDRs, asymmetric routing, DNS resolver loops, endpoint policy gaps, inspection bypass, quota limits, and failover paths nobody tested.
+
+Common bad assumptions:
+
+- Transit Gateway centralization automatically simplifies routing.
+- Security groups and NACLs are interchangeable controls.
+- Private subnets are private if they lack public IPs.
+- Route 53 private DNS works the same across VPCs, accounts, and hybrid networks.
+- Direct Connect or VPN redundancy exists because two links are drawn.
+- VPC endpoints remove all egress and data-exfiltration risk.
+
+## Network-specific failure modes
+
+- Overlapping or exhausted CIDR ranges block peering, TGW attachments, or future account expansion.
+- Asymmetric routing breaks stateful firewalls, NAT, inspection appliances, or hybrid return paths.
+- Route propagation leaks reachability across environments or bypasses inspection VPCs.
+- Resolver forwarding rules create split-horizon surprises, loops, or missing conditional forwarding.
+- Interface endpoint policies, private DNS, security groups, or shared services accounts are mis-scoped.
+- Failover path lacks BGP, health checks, route priority, DNS TTL, or operational runbook evidence.
+
+## Minimum safe workflow
+
+1. Identify scope: VPCs, accounts, Regions, CIDRs, routing domains, DNS zones, and hybrid links.
+2. Draw actual traffic flows for ingress, east-west, egress, service endpoints, and management access.
+3. Verify route-table, TGW route-table, propagation, association, DNS resolver, and endpoint-policy boundaries.
+4. Classify exposure: public internet, partner network, on-premises, shared services, workload VPC, and control plane.
+5. Check availability and failover: AZ independence, NAT/endpoint placement, DX/VPN redundancy, DNS TTL, and runbook.
+6. Identify least risky next actions; do not mutate routes, DNS, or firewall rules without change approval.
+7. State what evidence is live, documented, user-provided, or inferred.
+
+## Verification targets
+
+- VPC/subnet CIDRs, route tables, NAT gateways, internet gateways, egress-only gateways, and NACL/security group intent
+- Transit Gateway attachments, route tables, propagation, associations, appliance mode, and blackhole/static routes
+- Direct Connect gateway/VIF, Site-to-Site VPN tunnels, BGP routes, and failover test evidence
+- Route 53 Resolver inbound/outbound endpoints, forwarding rules, private hosted zones, DHCP options, and split-horizon behavior
+- VPC interface/gateway endpoints, private DNS, endpoint policies, and service control boundaries
+- flow logs, reachability analyzer output, packet path evidence, and recent network-change timeline
+
+## When to push back
+
+Push back if the user asks to:
+
+- add broad routes such as `0.0.0.0/0` or propagated access without blast-radius proof
+- bypass inspection to fix latency or connectivity quickly
+- accept overlapping CIDRs as a temporary problem
+- change DNS forwarding without rollback and test queries
+- claim private connectivity prevents exfiltration without endpoint/resource policy evidence
+- treat a diagram as proof of live routing state

package/skills/aws/aws-network-architect/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/vpc/latest/userguide/what-is-amazon-vpc.html
-- https://docs.aws.amazon.com/vpc/latest/tgw/tgw-best-design-practices.html
-- https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/network-to-amazon-vpc-connectivity-options.html
-- https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/transit-gateway.html
+- https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-best-practices.html
+- https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html
+- https://docs.aws.amazon.com/vpc/latest/tgw/tgw-vpc-attachments.html
+- https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.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:
+- VPC security best practices include security groups, network ACLs, VPC Flow Logs, Network Firewall, and GuardDuty threat detection.
+- Transit Gateway acts as a hub to interconnect VPCs and on-premises networks using attachments and route tables.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported VPC, Transit Gateway, and PrivateLink as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `EC2+DescribeVpcs`, `EC2+DescribeTransitGateways`, and `EC2+DescribeVpcEndpoints` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Network design review needs CIDR/IPAM, routing, segmentation, DNS, ingress/egress, endpoint policies, inspection path, logs, and failure-domain evidence.
+- Service availability does not prove route-table correctness, asymmetric path safety, or blast-radius control.

package/skills/aws/aws-network-architect/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, 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-network-architect/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-non-destructive-task-automation-advisor/SKILL.md

@@ -4,8 +4,8 @@ description: Design AWS non-destructive task automation using EventBridge, Step
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  updated: "2026-06-02"
   category: delivery
 ---
 
@@ -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.
 - This role is non-destructive by default. Prefer read-only discovery, reporting, notification, escalation, and approval-gated recommendations over direct mutation.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, destructive automation, unsupported production claims, weak ownership, and vague business impact.
@@ -40,6 +40,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, advisory workflow, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, 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.
+- [Non-Destructive Automation Patterns Guide](references/non-destructive-automation-patterns.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-non-destructive-task-automation-advisor/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Design AWS-native, non-destructive automation for reporting, notification, evidence gathering, approvals, and workflow coordination using serverless and event-driven services.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html",
-    "https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html",
+    "https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-troubleshooting.html",
     "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html"
+    "https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html",
+    "https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html"
   ],
   "security_notes": "This role must stay non-destructive. Prefer notification, approval, reporting, and evidence-collection flows. Escalate if the request drifts into mutation, remediation, or destructive operational automation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-non-destructive-task-automation-advisor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-non-destructive-task-automation-advisor/references/non-destructive-automation-patterns.md

@@ -0,0 +1,60 @@
+# Non-Destructive Automation Patterns Guide
+
+Use this reference when designing AWS automation for reporting, evidence gathering, notification, approvals, and coordination without direct remediation or destructive mutation.
+
+## What people get wrong
+
+The lazy story is:
+
+> It only automates an operator task, so it is safe.
+
+Wrong. Automation changes risk shape. A read-only inventory flow can become destructive if it adds broad IAM, invokes remediation runbooks, changes approvals, or leaks sensitive evidence into messages.
+
+Common bad assumptions:
+
+- Systems Manager Automation is non-destructive by default.
+- Step Functions orchestration is safe because each step is small.
+- EventBridge rules cannot cause incidents if the target is serverless.
+- Notifications may include raw logs, ARNs, account IDs, or secret-looking values.
+- Manual approval steps are enough without least-privilege execution roles.
+- Retry policies are harmless for ticket creation or notifications.
+
+## Automation-specific failure modes
+
+- Runbook step calls mutating APIs such as update, delete, stop, detach, revoke, or put-policy.
+- Lambda or Step Functions role has wildcard permissions beyond read/report/notify.
+- EventBridge rule fans out noisy events into duplicate tickets or alert storms.
+- SNS/SQS messages expose sensitive log excerpts or customer identifiers.
+- Approval path is bypassable because the automation role can execute the final action directly.
+- Retry/catch logic hides partial failure or repeats side effects.
+
+## Minimum safe workflow
+
+1. Classify every step as read, calculate, notify, approve, ticket, or mutate.
+2. Reject or isolate mutate steps; this skill should design non-destructive flows only.
+3. Choose the simplest orchestration: EventBridge schedule/rule, Lambda report, Step Functions approval flow, SNS/SQS fanout, or Systems Manager Automation read-only runbook.
+4. Define least-privilege role boundaries and data-redaction rules before workflow shape.
+5. Add idempotency, deduplication, retry limits, and failure visibility.
+6. Make human approvals explicit and external to any role that could perform mutation.
+7. Provide implementation guidance as design or repo patch only; live deployment remains approval-gated.
+
+## Verification targets
+
+- IAM policy actions: prove no destructive verbs are needed for the workflow
+- EventBridge pattern/schedule and target list
+- Step Functions states, retries, catches, approval waits, and terminal failure paths
+- Lambda/reporting code paths and sanitized output fields
+- Systems Manager Automation document steps and `assumeRole` permissions
+- SNS/SQS topic/queue policy, retention, DLQ, and message content boundaries
+- evidence contract: what is collected, redacted, stored, and sent to whom
+
+## When to push back
+
+Push back if the user asks to:
+
+- include remediation in a non-destructive automation
+- grant wildcard IAM because the workflow is “just reporting”
+- send raw logs, credentials, account IDs, or customer data into notifications
+- suppress alarms/tickets automatically instead of routing them
+- make approval a checkbox while the automation can still mutate directly
+- deploy the automation without testing event volume and retry behavior

package/skills/aws/aws-non-destructive-task-automation-advisor/references/official-sources.md

@@ -1,12 +1,29 @@
 # Official sources
 
-Use this reference when grounding current AWS service behavior for this role.
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-- https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html
-- https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html
+## 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/automation-troubleshooting.html
 - https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html
-- https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
+- https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html
+- https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-runbook-reference.html
 
 ## Grounding rule
 
-Docs explain service behavior. They do not prove the user's deployed state, ownership, SLAs, budget posture, or current incident reality.
+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:
+- Systems Manager Automation troubleshooting highlights common failures such as IAM PassRole errors, assume-role misconfiguration, VPC errors, RunInstances failures, and timeouts.
+- Automation runbooks can still perform mutations; non-destructive advisory work must distinguish read-only discovery from execution steps.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Systems Manager as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `SSM+DescribeAutomationExecutions` and `SSM+GetAutomationExecution` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Recommend automation only after identifying read-only commands, mutation boundaries, approval gates, rollback path, and operator confirmation points.
+- Do not present a runbook as safe because it is managed; inspect actions, permissions, targets, and outputs.

package/skills/aws/aws-observability-incident-responder/SKILL.md

@@ -4,8 +4,8 @@ description: Investigate broad AWS incidents and observability gaps using CloudW
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.2"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: observability
 ---
 
@@ -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.
+- [Incident Evidence Correlation Guide](references/incident-evidence-correlation.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-observability-incident-responder/metadata.json

@@ -15,13 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html",
-    "https://docs.aws.amazon.com/IDR/latest/userguide/observe-idr.html",
-    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Investigations-IncidentReports-terms.html",
-    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/incident-report-5whys.html"
+    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html",
+    "https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html",
+    "https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html"
   ],
   "security_notes": "Do not claim root cause without evidence. Separate live telemetry, service health, deployment changes, AI-derived insights, and human inference; require rollback or containment for active incidents.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-observability-incident-responder",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-observability-incident-responder/references/incident-evidence-correlation.md

@@ -0,0 +1,59 @@
+# Incident Evidence Correlation Guide
+
+Use this reference for AWS incident investigation across CloudWatch metrics/logs/alarms, X-Ray traces, CloudTrail, EventBridge, AWS Health, deployment timelines, runbooks, and post-incident corrective actions.
+
+## What people get wrong
+
+The lazy story is:
+
+> Find the alarm that fired first and call it root cause.
+
+Wrong. First visible symptom is rarely root cause. Incidents need timeline discipline, blast-radius mapping, competing hypotheses, and evidence quality labels.
+
+Common bad assumptions:
+
+- Dashboard red equals customer impact.
+- CloudWatch anomaly or generated insight proves root cause.
+- No active alarm means the incident is over.
+- Logs can be pasted raw into tickets or summaries.
+- Deployment correlation proves deployment causation.
+- Restart/retry remediation can happen before preserving evidence.
+
+## Incident failure modes
+
+- Metrics, logs, traces, and events use different clocks, dimensions, sampling, and retention.
+- Alert storm hides the primary failing dependency or customer-facing symptom.
+- CloudTrail control-plane changes are ignored during data-plane incidents.
+- AWS Health/service events are not checked for the right account/Region/service scope.
+- Runbook actions mutate state before evidence capture.
+- Post-incident actions fix symptoms but not detection, rollback, ownership, or capacity gaps.
+
+## Minimum safe workflow
+
+1. Define incident window, affected users/services, severity, owner, and current mitigation state.
+2. Build a timeline from alarms, metrics, logs, traces, CloudTrail, EventBridge, deployments, and AWS Health.
+3. Separate symptoms, contributing factors, root-cause hypotheses, and confirmed causes.
+4. Preserve sensitive data boundaries: summarize logs, redact payloads, and avoid secrets/customer identifiers.
+5. Recommend safe read-only checks first; mutation or rollback requires explicit approval and owner alignment.
+6. Produce next actions: containment, validation, communication, monitoring, and post-incident follow-up.
+7. Mark unknowns honestly and list the exact evidence needed to close them.
+
+## Verification targets
+
+- CloudWatch alarm history, metric math, dimensions, dashboards, and anomaly bands
+- CloudWatch Logs Insights queries, sanitized log excerpts, retention, and ingestion delay
+- X-Ray traces, service maps, error/latency annotations, and sampling notes
+- CloudTrail events for deployments, IAM, networking, scaling, KMS, and data-store changes
+- EventBridge events, AWS Health events, Incident Manager engagement, OpsItems, and support cases
+- deployment/change timeline, rollback status, customer-impact metrics, and postmortem action tracker
+
+## When to push back
+
+Push back if the user asks to:
+
+- claim root cause from correlation alone
+- suppress or close alarms before recovery validation
+- paste raw secret-bearing logs into the response
+- mutate production before evidence capture and approval
+- ignore AWS Health or recent change history
+- skip post-incident corrective actions because service recovered

package/skills/aws/aws-observability-incident-responder/references/official-sources.md

@@ -6,10 +6,24 @@ Use this reference only when you need source grounding for AWS service behavior
 
 Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html
-- https://docs.aws.amazon.com/IDR/latest/userguide/observe-idr.html
-- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Investigations-IncidentReports-terms.html
-- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/incident-report-5whys.html
+- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html
+- https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html
+- https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.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:
+- CloudWatch provides metrics, alarms, dashboards, logs, APM, infrastructure monitoring, cross-account monitoring, and network/internet monitoring.
+- The CloudWatch agent can collect metrics, logs, and traces from EC2 and on-premises servers via StatsD, collectd, OpenTelemetry, and X-Ray SDKs.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon CloudWatch and AWS X-Ray as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CloudWatch+DescribeAlarms` and `XRay+GetTraceSummaries` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Incident response must separate symptoms, time window, affected services, alarms, logs/traces, recent changes, customer impact, and unknown telemetry gaps.
+- Absence of queried alarms is not proof of health if logs, traces, canaries, dashboards, or AWS Health were not checked.