@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-compliance-evidence-mapper/SKILL.md

@@ -4,8 +4,8 @@ description: Map AWS compliance evidence for audits across Security Hub controls
 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: compliance
 ---
 
@@ -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.
+- [Compliance Evidence Chain Guide](references/compliance-evidence-chain.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-compliance-evidence-mapper/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html"
   ],
   "security_notes": "Do not claim compliance from tool output alone. Label evidence freshness, scope, inconclusive evidence, missing Config/Security Hub coverage, and need for legal/compliance review.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-compliance-evidence-mapper",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-compliance-evidence-mapper/references/compliance-evidence-chain.md

@@ -0,0 +1,59 @@
+# Compliance Evidence Chain Guide
+
+Use this reference for AWS compliance evidence mapping across Security Hub controls, Config rules/conformance packs, Audit Manager, AWS Artifact, CloudTrail, manual evidence, exceptions, owners, and control narratives.
+
+## What people get wrong
+
+The lazy story is:
+
+> Export dashboard findings and call it audit evidence.
+
+Wrong. Audit evidence needs scope, time period, source, control mapping, ownership, completeness, exception handling, and reproducibility. A dashboard screenshot is usually weak evidence.
+
+Common bad assumptions:
+
+- Security Hub passed controls prove compliance.
+- AWS Config conformance packs cover the full control objective.
+- AWS Artifact reports prove customer workload compliance.
+- Manual evidence is acceptable without owner and timestamp.
+- Audit Manager evidence is complete without checking source coverage.
+- Remediated finding means control operated effectively for the whole period.
+
+## Compliance-evidence failure modes
+
+- Evidence period does not match audit period.
+- Account/Region/resource scope excludes material workloads.
+- Control mapping confuses AWS responsibility with customer responsibility.
+- Exceptions lack risk acceptance, expiry, owner, and compensating controls.
+- Evidence cannot be reproduced from source systems.
+- Sensitive evidence leaks account IDs, customer data, secrets, or vulnerability details unnecessarily.
+
+## Minimum safe workflow
+
+1. Identify framework, control, audit period, in-scope accounts/Regions/workloads, and evidence owner.
+2. Map technical sources to control assertions: Config, Security Hub, CloudTrail, AWS Backup, IAM, logs, tickets, and manual evidence.
+3. Label evidence quality: direct, indirect, sampled, stale, manual, missing, or inference.
+4. Check completeness by scope and time period, not just current pass/fail status.
+5. Separate AWS Artifact/provider evidence from customer workload evidence.
+6. Produce evidence package with source, timestamp, owner, control mapping, gaps, exceptions, and safe redaction.
+7. Avoid remediation recommendations unless routed to the relevant technical hardening skill.
+
+## Verification targets
+
+- AWS Config rules/conformance packs, aggregators, compliance history, and resource scope
+- Security Hub controls/findings, workflow status, standards, suppression rules, and account/Region coverage
+- Audit Manager assessment/evidence folders where available, noting current service availability/maintenance constraints
+- AWS Artifact reports mapped to shared-responsibility claims only
+- CloudTrail organization trail, log integrity, S3/KMS protection, and evidence retention
+- tickets, approvals, exception register, risk acceptance, remediation proof, and control-owner signoff
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat a screenshot as complete evidence
+- use provider reports as proof of customer controls
+- hide exceptions, stale data, or missing accounts
+- include secrets/customer data in evidence packs
+- claim compliance from current-state checks for a historical audit period
+- turn evidence mapping into unapproved remediation

package/skills/aws/aws-compliance-evidence-mapper/references/official-sources.md

@@ -12,4 +12,18 @@ Use these as starting points, not as proof of the user's live AWS state:
 
 ## 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, or operational state. Prefer AWS managed MCP read-only evidence through the user's configured read-only AWS profile, read-only AWS CLI evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- AWS Audit Manager availability-change guidance says Audit Manager is moving into maintenance mode and points customers toward AWS Config Conformance Packs for many compliance use cases.
+- Audit Manager evidence folders, Config conformance packs, Security Hub controls, and AWS Artifact reports are separate evidence sources with different scope and freshness limits.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for AWS Audit Manager and AWS Config in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `Config Service+DescribeConformancePacks` and `Config Service+GetComplianceDetailsByConfigRule` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Audit Manager output, Config compliance, Security Hub findings, and AWS Artifact reports are evidence inputs; none alone proves compliance.
+- Because Audit Manager availability and lifecycle changed, prefer Config conformance packs and exported evidence where AWS docs direct migration, and label legacy Audit Manager usage explicitly.

package/skills/aws/aws-compliance-evidence-mapper/references/safety-checklist.md

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

package/skills/aws/aws-compliance-evidence-mapper/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-cost-anomaly-watch-coordinator/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS cost anomalies using Cost Explorer, Cost Anomaly Detecti
 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: 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.
 - 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.
+- [Cost Anomaly Triage Guide](references/cost-anomaly-triage.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-cost-anomaly-watch-coordinator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review AWS cost anomalies, budget drift, usage spikes, and savings opportunities with non-destructive recommendations and business-facing escalation guidance.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/cost-management/latest/userguide/management-limits.html",
+    "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"
+    "https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html"
   ],
   "security_notes": "Keep the role advisory and non-destructive. Do not stop workloads or alter purchasing commitments from this role. Focus on evidence, hypotheses, safe next checks, and escalation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-cost-anomaly-watch-coordinator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

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