@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/aws/aws-cost-anomaly-watch-coordinator/references/cost-anomaly-triage.md

@@ -0,0 +1,60 @@
+# Cost Anomaly Triage Guide
+
+Use this reference when reviewing AWS spend spikes, Cost Anomaly Detection alerts, Budgets variance, Cost Explorer deltas, usage surges, commitment mismatch, or tagging gaps.
+
+## What people get wrong
+
+The lazy story is:
+
+> Find the expensive service and tell someone to turn it off.
+
+Wrong. Cost anomalies need evidence, attribution, business context, and safe containment. Stopping workloads from a FinOps watch role can become an outage.
+
+Common bad assumptions:
+
+- The largest service delta is the root cause.
+- Cost Explorer data is real-time enough for incident response.
+- Budget alerts prove waste.
+- Anomaly root-cause fields prove ownership.
+- Tag gaps are minor reporting issues.
+- Savings Plans or RI changes are safe short-term fixes.
+
+## Cost-specific failure modes
+
+- Spend increase is legitimate business demand, data backfill, migration, or incident mitigation.
+- Usage type, operation, linked account, Region, or tag dimension points to a different owner than the service name suggests.
+- Data transfer, NAT Gateway, CloudWatch Logs, KMS requests, Bedrock tokens, or support charges are missed because the review stops at top-level service.
+- Forecast/budget period does not align with anomaly window.
+- Commitment coverage/utilization is interpreted without amortized vs unblended cost context.
+- Proposed containment would stop production, delete data, or break compliance evidence.
+
+## Minimum safe workflow
+
+1. Define anomaly window, baseline period, account scope, payer/member visibility, and data freshness.
+2. Break down spend by service, linked account, Region, usage type, operation, tag, and resource where available.
+3. Separate confirmed cost drivers from hypotheses and missing dimensions.
+4. Check business/change context: releases, migrations, tests, incidents, backfills, traffic growth, or new services.
+5. Recommend non-destructive containment first: owner escalation, budget/anomaly subscription tuning, log retention review, quota check, tagging correction, or deeper domain review.
+6. Escalate destructive containment only to the correct service owner with approval and rollback/impact notes.
+7. State uncertainty caused by billing latency, missing tags, unsupported resource granularity, or limited account visibility.
+
+## Verification targets
+
+- Cost Anomaly Detection monitor, alert, root-cause dimensions, and subscription recipients
+- Cost Explorer grouped by service, linked account, Region, usage type, operation, tag, and resource where supported
+- Budgets actual/forecast threshold, time period, alert recipients, and action settings
+- pricing/usage context for the suspected service
+- recent deployments, batch jobs, migrations, incidents, or traffic changes
+- tag coverage, cost category mapping, account owner, and commitment coverage/utilization
+- safe follow-up owner and impact assessment before any workload change
+
+## When to push back
+
+Push back if the user asks to:
+
+- stop, delete, downscale, or revoke resources from cost evidence alone
+- buy or modify commitments as an emergency reaction
+- blame an owner from incomplete tags or payer-only aggregates
+- ignore billing latency or missing account scope
+- publish customer/resource-sensitive billing details broadly
+- treat a cost anomaly as waste without business validation

package/skills/aws/aws-cost-anomaly-watch-coordinator/references/official-sources.md

@@ -1,12 +1,28 @@
 # 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/cost-management/latest/userguide/management-limits.html
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html
+- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-enable.html
 - https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html
 - https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html
-- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.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:
+- Cost Explorer access is permission-controlled; member-account visibility also depends on management-account Cost Explorer preferences.
+- Enabling Cost Explorer activates machine-learning anomaly detection alerts according to AWS Cost Management guidance, but alert coverage still depends on monitors, subscriptions, thresholds, and account scope.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `Cost Explorer+GetAnomalies` and `Cost Explorer+GetAnomalyMonitors` as `isAvailableIn` in `us-east-1`; the same filters returned `Not Found` in `us-west-2`, `eu-west-1`, and `ap-southeast-1`, so treat Cost Explorer anomaly APIs as global/home-region-style evidence, not broad regional deployment proof.
+
+Review implications:
+- Do not claim a cost spike root cause without Cost Explorer time-series evidence, anomaly monitor/subscription scope, service/account/tag attribution, and known deployment or usage-change correlation.
+- Keep this role non-destructive: recommend containment, owner escalation, budget alert review, tagging fixes, and approval-gated remediation instead of stopping resources directly.

package/skills/aws/aws-cost-optimization-governor/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS cost optimization and FinOps posture across Cost Explore
 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: finops
 ---
 
@@ -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.
+- [Cost Optimization Risk Governance Guide](references/cost-optimization-risk-governance.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-cost-optimization-governor/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS cost posture across Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, commitments, tagging, showback, idle waste, and rightsizing.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/cost-management/latest/userguide/cost-optimization-hub.html",
-    "https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html",
-    "https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-api-best-practices.html/",
+    "https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is.html",
+    "https://docs.aws.amazon.com/compute-optimizer/latest/ug/savings-estimation-mode.html",
+    "https://docs.aws.amazon.com/cost-management/latest/userguide/understanding-rr-calc.html",
     "https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html"
   ],
   "security_notes": "Do not recommend cost cuts that remove backups, logging, security controls, redundancy, or tested capacity without explicit risk acceptance and rollback evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-cost-optimization-governor",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-cost-optimization-governor/references/cost-optimization-risk-governance.md

@@ -0,0 +1,59 @@
+# Cost Optimization Risk Governance Guide
+
+Use this reference for AWS Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, Savings Plans, Reserved Instances, tagging, showback, idle resources, rightsizing, storage, data transfer, and forecast-risk reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> Cost optimization is a list of savings recommendations.
+
+Wrong. Savings are not neutral. Every cost action has reliability, security, compliance, performance, and delivery tradeoffs. Unowned recommendations become shelfware or outages.
+
+Common bad assumptions:
+
+- Cost Optimization Hub or Compute Optimizer estimates are implementation-ready.
+- Rightsizing is safe from average utilization.
+- Commitments are good if discount percentage is high.
+- Idle resources can be deleted without owner and recovery evidence.
+- Tagging is just reporting hygiene.
+- Data transfer and observability costs are secondary details.
+
+## Cost-governance failure modes
+
+- Recommendation ignores business seasonality, migration, incidents, batch windows, or growth.
+- Savings Plans/RI purchase conflicts with architecture roadmap or account ownership.
+- Deleting logs, backups, NAT gateways, replicas, or endpoints reduces auditability or resilience.
+- Rightsizing compute/storage causes latency, failover, or scale-out regressions.
+- Untagged/shared resources make owner attribution and chargeback wrong.
+- Forecasts and anomaly baselines are treated as real-time truth.
+
+## Minimum safe workflow
+
+1. Confirm account scope, billing view, owner, business unit, monthly spend, forecast period, and optimization target.
+2. Break down cost by service, account, Region, usage type, operation, tag, resource, and commitment coverage where available.
+3. Classify opportunities: no-risk governance, low-risk configuration, engineering change, commitment purchase, or risky workload reduction.
+4. For each recommendation, state savings estimate, confidence, owner, risk, validation evidence, rollback path, and pillar tradeoff.
+5. Prefer reversible governance first: tags, budgets, anomaly alerts, dashboards, owner assignment, and idle-resource investigation.
+6. Require approval for deletion, downscale, retention reduction, commitment purchase, or architecture changes.
+7. Validate post-change savings and regressions after implementation.
+
+## Verification targets
+
+- Cost Explorer, Budgets, Cost Optimization Hub, Compute Optimizer, Savings Plans/RI coverage and utilization
+- amortized/unblended/net cost basis, billing view, payer/member account scope, and data freshness
+- tag coverage, cost categories, owner mapping, showback/chargeback, and budget/anomaly subscriptions
+- utilization metrics, performance headroom, business seasonality, incident/release context, and growth forecast
+- reliability/security/compliance impact for logs, backups, replicas, endpoints, encryption, monitoring, and support plans
+- implementation owner, approval, rollback, and post-change measurement plan
+
+## When to push back
+
+Push back if the user asks to:
+
+- delete/downscale resources from cost data alone
+- buy commitments without usage stability and roadmap evidence
+- reduce backup/log/security spend without risk acceptance
+- blame owners from incomplete tags
+- present savings without confidence and tradeoff labels
+- treat recommendation tools as approval authority

package/skills/aws/aws-cost-optimization-governor/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/cost-management/latest/userguide/cost-optimization-hub.html
-- https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html
-- https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-api-best-practices.html/
+- https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is.html
+- https://docs.aws.amazon.com/compute-optimizer/latest/ug/savings-estimation-mode.html
+- https://docs.aws.amazon.com/cost-management/latest/userguide/understanding-rr-calc.html
 - https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/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:
+- Compute Optimizer analyzes resource configuration and utilization for EC2 instances, Auto Scaling groups, Lambda functions, EBS volumes, and ECS services on Fargate, then reports optimization recommendations.
+- Cost Explorer rightsizing recommendations use usage and billing context; savings estimates can be affected by On-Demand hours, RI/Savings Plans coverage, and payer/member-account scope.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `Compute Optimizer+GetEC2InstanceRecommendations` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- `TrustedAdvisor+ListRecommendations` was reported `isAvailableIn` in `us-east-1`, `us-west-2`, and `eu-west-1`, and `Not Found` in `ap-southeast-1`; treat this as sampled API availability, not proof of support-plan entitlement or recommendation quality.
+
+Review implications:
+- Do not delete, downsize, or purchase commitments from recommendation output alone. Require utilization windows, performance/SLO impact, reservation or Savings Plans interaction, owner approval, rollback path, and change calendar context.
+- Cost tools can identify candidates; they do not prove business criticality or safe remediation.

package/skills/aws/aws-cost-optimization-governor/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-cost-optimization-governor/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-daily-operations-briefing-coordinator/SKILL.md

@@ -4,8 +4,8 @@ description: Prepare AWS daily operations briefings using CloudWatch, Personal H
 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: 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.
 - 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.
+- [Operations Briefing Signal Quality Guide](references/operations-briefing-signal-quality.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-daily-operations-briefing-coordinator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Prepare non-destructive AWS daily operations briefings across health signals, incidents, deployments, cost drift, open risks, and action backlog for business and engineering stakeholders.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html",
     "https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html",
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/introduction.html",
-    "https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html",
-    "https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html"
+    "https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html",
+    "https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html"
   ],
   "security_notes": "Do not treat dashboards as proof. Keep reporting read-only, evidence-based, and explicit about unknowns. Never recommend mutation or production changes without separate approval and deeper technical review.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-daily-operations-briefing-coordinator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-daily-operations-briefing-coordinator/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.
 
+## AWS documentation
+
+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/health/latest/ug/what-is-aws-health.html
-- https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/introduction.html
-- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html
 - https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html
+- https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.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:
+- CloudWatch provides operational visibility through metrics, alarms, dashboards, logs, application performance monitoring, infrastructure monitoring, cross-account monitoring, and network/internet monitoring.
+- Trusted Advisor inspects AWS environments and can surface recommendations for cost, performance, availability, security, and service limits depending on support plan and feature availability.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `CloudWatch+DescribeAlarms` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- `Health+DescribeEvents` was reported `isAvailableIn` in `us-east-1` and `Not Found` in `us-west-2`, `eu-west-1`, and `ap-southeast-1`; treat Health as account/global-style evidence unless local tooling proves otherwise.
+
+Review implications:
+- A daily brief must separate live alarms/incidents, AWS Health events, cost anomalies, deployment changes, security/compliance signals, and backlog risks.
+- Do not summarize unknown systems as healthy; say exactly which sources were queried and which were not.

package/skills/aws/aws-daily-operations-briefing-coordinator/references/operations-briefing-signal-quality.md

@@ -0,0 +1,60 @@
+# Operations Briefing Signal Quality Guide
+
+Use this reference when preparing AWS daily or weekly operations briefings from CloudWatch, AWS Health, Trusted Advisor, cost, deployment, incident, and backlog signals.
+
+## What people get wrong
+
+The lazy story is:
+
+> Summarize dashboards and call it an ops brief.
+
+Wrong. A briefing is an evidence-weighted decision artifact. Dashboards show slices of reality, not ownership, impact, trend, or actionability.
+
+Common bad assumptions:
+
+- No active alarms means no operational risk.
+- AWS Health events automatically map to impacted workloads.
+- Trusted Advisor checks are always current and universally available.
+- Cost spikes are operational incidents without business context.
+- Deployment success means customer impact is zero.
+- Open tickets can be summarized without owner, age, severity, and blocker state.
+
+## Briefing-specific failure modes
+
+- Mixing confirmed incidents, unverified alerts, and stale backlog as equal-priority items.
+- Reporting alarm counts without affected service, owner, severity, duration, and customer/business impact.
+- Ignoring deployment timeline around incident onset.
+- Presenting cost variance without service, account, usage type, tag, or commitment context.
+- Omitting AWS Health or support-case context during regional/service disruption.
+- Producing action items without single owners or deadlines.
+
+## Minimum safe workflow
+
+1. Define audience and time window: executive daily, engineering handoff, weekly risk review, or incident standup.
+2. Gather read-only signals: alarms, incidents, AWS Health, deployments, cost deltas, Trusted Advisor, open tickets, and known risks.
+3. Label each item as confirmed, sampled, stale, inferred, or missing evidence.
+4. Rank by customer impact, security/compliance risk, operational urgency, and business cost.
+5. Convert noise into actions: owner, next step, due time, blocker, and escalation path.
+6. Separate “watch” items from “act now” items.
+7. State blind spots explicitly; do not imply the account is healthy from narrow evidence.
+
+## Verification targets
+
+- CloudWatch alarms and metric trends for the reporting window
+- AWS Health events and account/organization visibility scope
+- Trusted Advisor check status and support-plan/access limitations
+- Cost Explorer or Budgets variance by service/account/tag/usage type
+- deployment and change timeline from pipeline, change calendar, or release notes
+- incident records, OpsItems, support cases, tickets, and unresolved postmortem actions
+- stale data markers: last updated time, Region/account coverage, and missing telemetry
+
+## When to push back
+
+Push back if the user asks to:
+
+- claim “all clear” from one dashboard or Region sample
+- hide uncertainty, stale data, or missing account coverage
+- turn briefing coordination into live remediation
+- publish raw sensitive evidence in a broad audience brief
+- assign action items without owners or deadlines
+- merge security, cost, availability, and backlog risk into one vague priority

package/skills/aws/aws-data-protection-backup-steward/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS backup and data protection implementation across AWS Bac
 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: resilience
 ---
 
@@ -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.
+- [Backup Restore Evidence Guide](references/backup-restore-evidence.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-data-protection-backup-steward/metadata.json

@@ -15,13 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html",
+    "https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html",
     "https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html",
-    "https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-account-backup.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html"
+    "https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-account-backup.html"
   ],
   "security_notes": "Do not treat snapshots as sufficient data protection. Check restore permissions, KMS access, vault policy, immutability, cross-account isolation, and tested recovery evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-data-protection-backup-steward",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-data-protection-backup-steward/references/backup-restore-evidence.md

@@ -0,0 +1,59 @@
+# Backup Restore Evidence Guide
+
+Use this reference for AWS Backup, backup plans, vaults, vault lock, restore testing, cross-account/cross-Region copy, EBS/RDS/EFS/S3 recovery patterns, retention, lifecycle, encryption, and recoverability evidence.
+
+## What people get wrong
+
+The lazy story is:
+
+> Backup jobs are successful, so the data is protected.
+
+Wrong. Protection means recoverability, immutability where required, correct retention, tested restore permissions, and business-aligned recovery evidence.
+
+Common bad assumptions:
+
+- Successful backup job equals successful restore.
+- Cross-Region copy equals disaster recovery.
+- Vault Lock protects against every deletion path.
+- KMS encryption is operationally invisible during restore.
+- Lifecycle cold/archive transitions have no recovery-time impact.
+- Native service backups and AWS Backup coverage are equivalent for every resource.
+
+## Backup-specific failure modes
+
+- Backup selection misses resources because tags, opt-in services, or new accounts are not covered.
+- Restore role lacks KMS, network, IAM, or target service permissions.
+- Vault policies allow deletion, copy disablement, or ransomware-impacting changes.
+- Cross-account/cross-Region copies fail or are not monitored.
+- Retention/lifecycle conflicts with legal hold, compliance, or RTO.
+- Restore test validates infrastructure but not application consistency.
+
+## Minimum safe workflow
+
+1. Identify protected resources, business owner, data classification, RPO/RTO, retention, and compliance requirements.
+2. Review AWS Backup plans, selections, vaults, copy actions, lifecycle, encryption, vault policies, and Vault Lock posture.
+3. Verify coverage gaps across accounts, Regions, services, tags, and newly created resources.
+4. Demand restore evidence: restore job, operator, target environment, application validation, and elapsed time.
+5. Check recovery permissions, KMS keys, network, secrets, and dependency readiness.
+6. Recommend non-destructive fixes first; deletion, retention reduction, or vault policy changes need explicit approval.
+7. Label evidence as configuration, job success, restore test, or business acceptance.
+
+## Verification targets
+
+- AWS Backup plans, backup rules, selections, copy actions, lifecycle, continuous backup/PITR, and protected resource inventory
+- backup vault policies, Vault Lock mode, access policy, KMS key policy, and cross-account/cross-Region copy jobs
+- restore jobs, restore testing plans, restore role permissions, elapsed restore time, and application validation evidence
+- EBS snapshots, RDS/Aurora backups, EFS backups, DynamoDB PITR, S3 versioning/Object Lock/replication, and service-native backup overlap
+- AWS Organizations backup policies, Control Tower/account coverage, Config/Backup Audit Manager evidence, and compliance reports
+- alerting for failed/missed backup jobs, copy failures, vault policy changes, and backup age
+
+## When to push back
+
+Push back if the user asks to:
+
+- claim recoverability from backup-job success alone
+- reduce retention or delete recovery points without compliance approval
+- skip restore tests because backups are encrypted and replicated
+- ignore KMS/permission dependencies for restore
+- treat cross-Region copy as full DR without runbook and application validation
+- mutate vault lock or backup policies from advisory evidence alone

package/skills/aws/aws-data-protection-backup-steward/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/aws-backup/latest/devguide/whatisbackup.html
+- https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-account-backup.html
-- https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.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 Backup logically air-gapped vaults are isolated vaults intended to secure backups, support cross-account sharing, multi-party approval recovery, and cross-Region copies.
+- AWS Backup vault lock, cross-account backup, lifecycle, encryption, and restore workflows are design inputs; recoverability is proven only by successful restore evidence against the required RTO/RPO.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Backup as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `Backup+ListBackupVaults` and `Backup+ListRecoveryPointsByBackupVault` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Backup existence is not recovery readiness. Require restore-test results, restore IAM/KMS access, backup selection scope, lifecycle/retention evidence, vault lock posture, copy status, and recovery-account access.
+- Treat ransomware-resilience claims as unproven without isolation, immutability or lock controls, cross-account/cross-Region strategy, and tested recovery.

package/skills/aws/aws-data-protection-backup-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, 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-data-protection-backup-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-deployment-hotfix-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Patch AWS deployment hotfix config, release parameters, manifest mi
 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.
+- [Deployment Hotfix Safety Guide](references/deployment-hotfix-safety.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum