@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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.

package/skills/aws/aws-observability-incident-responder/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-observability-incident-responder/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-pipeline-fix-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Repair AWS pipeline configuration, buildspecs, workflow files, depl
 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: delivery
 ---
 
@@ -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.
+- [Pipeline Failure Analysis Guide](references/pipeline-failure-analysis.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-pipeline-fix-operator/metadata.json

@@ -14,13 +14,14 @@
   "summary": "Repair AWS-oriented CI/CD pipeline definitions, buildspecs, deployment workflow config, and release wiring in-repo without triggering live execution.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html",
-    "https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html",
-    "https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html"
+    "https://docs.aws.amazon.com/codepipeline/latest/userguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html",
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-codepipeline-pipeline.html"
   ],
   "security_notes": "Repo write access only. Do not manually trigger pipelines, rotate secrets, or bypass approval gates from this role. Keep fixes explicit, reviewable, and reversible.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-pipeline-fix-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-pipeline-fix-operator/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
-- https://docs.aws.amazon.com/codebuild/latest/userguide/build-spec-ref.html
-- https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
-- https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.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/codepipeline/latest/userguide/troubleshooting.html
+- https://docs.aws.amazon.com/codebuild/latest/userguide/troubleshooting.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting-deployments.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-resource-codepipeline-pipeline.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:
+- CodeDeploy troubleshooting separates deployment failures by lifecycle event, credentials, PKCS7 validation, file conflicts, DownloadBundle errors, health checks, and platform/script behavior.
+- CodePipeline can be represented as CloudFormation `AWS::CodePipeline::Pipeline`; repo-side fixes must keep pipeline resource semantics and IAM roles intact.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodePipeline+GetPipelineState`, `CodeBuild+BatchGetBuilds`, and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Patch only the failing repo configuration unless explicitly authorized for live action. Require failing stage/action evidence, logs, minimal diff, validation command, and rollback.
+- Do not guess root cause from a failed pipeline status; correlate source revision, build logs, deployment events, roles, artifacts, and environment config.

package/skills/aws/aws-pipeline-fix-operator/references/pipeline-failure-analysis.md

@@ -0,0 +1,60 @@
+# Pipeline Failure Analysis Guide
+
+Use this reference when fixing CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, GitLab, buildspecs, artifact paths, environment variables, or deployment wiring in repository files.
+
+## What people get wrong
+
+The lazy story is:
+
+> The pipeline failed, so patch the line that looks broken.
+
+Wrong. Pipeline failures are often evidence-routing problems: wrong revision, wrong artifact, wrong role, wrong environment, or a deployment failure surfacing as a build failure.
+
+Common bad assumptions:
+
+- The failed stage is the root cause.
+- Re-running is harmless.
+- Build logs contain no secrets.
+- Artifact path changes are low risk.
+- A green build means deploy safety.
+- Fixing CI config authorizes a live pipeline run.
+
+## Failure-mode map
+
+- **Source stage:** wrong branch, webhook, connection, commit, submodule, or artifact format.
+- **Build stage:** buildspec path, runtime image, env var, IAM role, dependency cache, test command, artifact upload.
+- **Deploy stage:** CodeDeploy lifecycle hook, ECS task set, Lambda alias, CloudFormation change set, missing permission.
+- **Approval/gate:** missing manual approval, stale approval, wrong condition, Lambda approval action failure.
+- **Cross-account:** artifact bucket/KMS/key policy, role trust, external ID, region mismatch.
+
+## Minimum safe workflow
+
+1. Identify provider and failing stage/action.
+2. Confirm source revision and artifact that failed.
+3. Inspect logs without exposing secrets.
+4. Patch the smallest repo-side cause.
+5. Preserve gates, approvals, artifact integrity, and rollback settings.
+6. Run local lint/test/build validators relevant to the changed file.
+7. State whether a live pipeline re-run is required and require approval for it.
+
+## Verification targets
+
+- pipeline definition or workflow YAML
+- buildspec and artifact paths
+- CodeBuild project env/runtime/image settings where represented in repo
+- CodeDeploy AppSpec and deployment group references
+- CloudFormation/CDK/Terraform pipeline resource definitions
+- IAM role references and KMS/artifact bucket wiring
+- failing log excerpt sanitized by the user or read-only tool output
+
+## When to push back
+
+Push back if the user asks to:
+
+- remove tests/gates to make the pipeline green
+- print or paste secret-bearing logs
+- re-run production deploys without approval
+- change artifact identity without release-owner signoff
+- widen deploy role permissions as a blind fix
+- ignore a failed post-deploy validation
+

package/skills/aws/aws-private-ca-issuer-review/SKILL.md

@@ -4,8 +4,8 @@ description: Use this skill when reviewing AWS ACM Private CA (Private Certifica
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: security
 ---
 
@@ -32,6 +32,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md)
 - [Safety checklist](references/safety-checklist.md)
 - [Official sources](references/official-sources.md)
+- [Private CA Issuer Trust Boundaries Guide](references/private-ca-issuer-trust-boundaries.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum