@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

package/skills/aws/aws-serverless-rollout-corrector/metadata.json

@@ -14,13 +14,14 @@
   "summary": "Patch serverless deployment definitions, Lambda rollout settings, event wiring, and alias/version configuration in-repo while keeping live rollout actions out of scope by default.",
   "source_type": "original",
   "official_docs": [
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-example.html",
     "https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html",
-    "https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html"
+    "https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html"
   ],
   "security_notes": "Can edit serverless rollout definitions in repo files only. Must not invoke live deploys, traffic shifts, or destructive remediation without separate explicit approval.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-serverless-rollout-corrector",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-serverless-rollout-corrector/references/lambda-rollout-correction.md

@@ -0,0 +1,64 @@
+# Lambda Rollout Correction Guide
+
+Use this reference when fixing Lambda aliases, versions, CodeDeploy/SAM traffic shifting, event-source mappings, destinations, DLQs, or serverless rollout wiring in repository files.
+
+## What people get wrong
+
+The lazy story is:
+
+> It is just a Lambda config fix; update the template and redeploy.
+
+Wrong. Serverless rollout defects often hide in alias/version traffic, event-source semantics, retries, and alarms. A repo patch can make the next deployment worse if it ignores those boundaries.
+
+Common bad assumptions:
+
+- `$LATEST` is acceptable in production rollout wiring.
+- Alias changes are harmless because code is immutable.
+- Event-source mapping changes are not production-impacting.
+- CodeDeploy hooks are optional ceremony.
+- DLQ/destination changes do not affect audit or replay.
+- A SAM/AppSpec diff proves runtime rollback readiness.
+
+## Service-specific failure modes
+
+- Alias points to the wrong published version or shifts traffic to unvalidated code.
+- Provisioned concurrency is attached to the wrong alias/version.
+- CodeDeploy deployment preference lacks alarms or lifecycle validation hooks.
+- Event source mapping batch size, maximum batching window, filter criteria, or starting position changes replay/latency behavior.
+- SQS/Lambda partial batch response settings are missing or inconsistent.
+- Async destinations or DLQs are removed during a hotfix.
+- IAM permission changes break event-source polling, log writes, or downstream calls.
+
+## Minimum safe workflow
+
+1. Identify the rollout mechanism: SAM, CloudFormation, CDK, Terraform, Serverless Framework, or raw config.
+2. Identify the release primitive: Lambda version, alias, CodeDeploy deployment group, event source mapping, API stage, or EventBridge rule.
+3. Patch the smallest repo field that corrects the defect.
+4. Preserve existing rollback path: previous alias target, previous mapping config, previous deployment preference, or previous template version.
+5. Run local validators for the IaC/framework in use.
+6. State what the patch changes at runtime and what it does not execute.
+7. Require explicit approval before deploy, rollback, publish-version, alias update, or event-source mutation.
+
+## Verification targets
+
+Use repo and read-only evidence where available:
+
+- Lambda alias/version references in templates
+- CodeDeploy deployment preference, alarms, and lifecycle hooks
+- event-source mapping config: source ARN, batch size, filters, enabled state, destinations
+- function timeout, memory, reserved/provisioned concurrency
+- DLQ and async destination configuration
+- IAM permissions for invoke, poll, log, and downstream calls
+- validation commands such as `sam validate`, `cfn-lint`, `cdk synth`, `terraform validate`, or project tests
+
+## When to push back
+
+Push back if the user asks to:
+
+- patch rollout config and immediately deploy without approval
+- remove alarms/hooks to make a deployment pass
+- point production aliases at `$LATEST`
+- disable event-source mappings without a replay plan
+- “fix” retries by dropping failures silently
+- claim rollback is safe without a previous alias/version target
+

package/skills/aws/aws-serverless-rollout-corrector/references/official-sources.md

@@ -1,5 +1,29 @@
 # Official sources
 
+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/codedeploy/latest/userguide/welcome.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file-example.html
 - https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html
 - https://docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html
-- https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
+
+## Grounding rule
+
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, 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 can automate Lambda deployments with traffic shifting, AppSpec files, lifecycle hooks, and rollback behavior depending on deployment configuration.
+- Lambda versions and aliases are release-control primitives; aliases can route traffic to published versions while function code/config versions remain immutable.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Lambda, CodeDeploy, and CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `Lambda+GetFunction` and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Repo-side rollout correction must identify alias/version, traffic shift, lifecycle hook, alarm, and rollback target; it must not execute live rollback/deploy unless explicitly approved.
+- Syntax-correct SAM/AppSpec is not proof of safe rollout behavior.

package/skills/aws/aws-solution-architect/SKILL.md

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

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

@@ -14,15 +14,14 @@
   "summary": "Design and stress-test AWS solution architectures across identity, networking, compute, data, security, resilience, operations, and cost with Well-Architected evidence discipline.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/wellarchitected/latest/framework/definitions.html",
     "https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html",
     "https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html"
+    "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html",
+    "https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html"
   ],
   "security_notes": "Do not approve an AWS architecture without account-boundary, IAM, network exposure, data protection, observability, recovery, and cost evidence. Label unknowns instead of pretending the diagram is proof.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-solution-architect",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-solution-architect/references/architecture-decision-stress-test.md

@@ -0,0 +1,59 @@
+# Architecture Decision Stress-Test Guide
+
+Use this reference for cross-domain AWS solution architecture decisions, ADRs, tradeoff reviews, target architectures, and production-readiness stress testing.
+
+## What people get wrong
+
+The lazy story is:
+
+> Pick the AWS best-practice pattern and fill in the diagram.
+
+Wrong. Architecture is tradeoff management under constraints. A design is not good until assumptions, failure modes, owners, validation paths, and rollback/migration paths survive scrutiny.
+
+Common bad assumptions:
+
+- Serverless, containers, or managed services are always the right default.
+- A Well-Architected answer is enough without evidence.
+- Security, reliability, cost, and delivery tradeoffs can be optimized independently.
+- Multi-Region is always more resilient.
+- Architecture diagrams show data boundaries, quotas, or operational ownership.
+- Future flexibility justifies complexity now.
+
+## Architecture-specific failure modes
+
+- Missing workload context: users, data sensitivity, SLOs, RTO/RPO, traffic, regulatory needs, and team capability.
+- Hidden coupling through IAM roles, KMS keys, DNS, event schemas, shared VPCs, databases, queues, and CI/CD.
+- Control-plane dependencies are mistaken for data-plane resilience.
+- Operational model lacks observability, runbooks, cost accountability, support plan, or ownership.
+- Migration path lacks strangler steps, rollback point, data cutover, or coexistence design.
+- Design optimizes a favorite service rather than stated constraints.
+
+## Minimum safe workflow
+
+1. Restate problem, constraints, non-goals, assumptions, and decision drivers.
+2. Identify workload domains: identity, network, compute, data, integration, observability, security, resilience, cost, and delivery.
+3. Compare at least two viable options when the decision is material.
+4. Stress-test each option against failure modes, data boundaries, quotas, operational ownership, migration, rollback, and cost.
+5. Choose the minimum viable architecture that satisfies constraints; call out rejected complexity.
+6. Produce an ADR-style decision: context, options, decision, consequences, risks, validation plan, and revisit triggers.
+7. Route single-domain deep work to narrower AWS skills when needed.
+
+## Verification targets
+
+- workload context: users, traffic, data classification, compliance, SLO/RTO/RPO, cost target, and team capability
+- architecture diagram plus trust/data boundaries, network paths, identity paths, and event/data flows
+- dependency inventory for managed services, third parties, DNS, KMS, shared accounts/VPCs, and pipelines
+- Well-Architected pillar impacts, risks, and explicit tradeoffs
+- validation plan: load test, threat model, DR test, cost model, proof of concept, migration rehearsal, and rollback criteria
+- implementation roadmap with owners, milestones, guardrails, and decision revisit date
+
+## When to push back
+
+Push back if the user asks to:
+
+- rubber-stamp a preferred architecture without alternatives
+- add multi-Region, Kubernetes, microservices, or AI because it sounds modern
+- ignore data classification, IAM, cost, or recovery constraints
+- produce a diagram without operating model and validation plan
+- treat official best practices as proof that this workload is ready
+- design beyond team capability or budget without naming the risk

package/skills/aws/aws-solution-architect/references/official-sources.md

@@ -5,12 +5,24 @@ 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/wellarchitected/latest/framework/definitions.html
 - https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/operational-excellence.html
 - https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html
 - https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.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:
+- The AWS Well-Architected Framework helps evaluate tradeoffs and best practices for reliable, secure, efficient, and cost-effective cloud systems.
+- Security, reliability, and cost optimization pillars each provide separate guidance; a solution decision can improve one pillar while increasing risk in another.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `WellArchitected+GetWorkload` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+
+Review implications:
+- Architecture recommendations must state workload context, constraints, assumptions, tradeoffs, pillar impacts, validation path, and migration/rollback path.
+- Well-Architected tool/API availability does not prove a workload has been reviewed or that risks are remediated.

package/skills/aws/aws-solution-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-solution-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-ticket-triage-escalation-coordinator/SKILL.md

@@ -4,8 +4,8 @@ description: Triage AWS tickets and alerts using priority, owner, evidence, inci
 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.
+- [Ticket Triage and Escalation Guide](references/ticket-triage-escalation.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ticket-triage-escalation-coordinator/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Triage AWS operational tickets, alerts, and requests into priority, owner, evidence needs, and safe escalation paths without taking destructive actions.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html",
+    "https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html",
+    "https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-ta.html",
     "https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html",
-    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/prepare.html"
+    "https://docs.aws.amazon.com/systems-manager-incidents/latest/userguide/what-is-incident-manager.html"
   ],
   "security_notes": "Do not mutate infrastructure, suppress alerts, or close issues without evidence and approval. This role classifies, routes, and escalates; it does not perform destructive remediation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ticket-triage-escalation-coordinator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-ticket-triage-escalation-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.
 
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/awssupport/latest/user/trusted-advisor.html
+- https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-ta.html
 - https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html
-- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
-- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/prepare.html
+- https://docs.aws.amazon.com/systems-manager-incidents/latest/userguide/what-is-incident-manager.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:
+- Trusted Advisor inspects AWS environments and can recommend cost, performance, availability, security, and service-limit improvements depending on support plan and feature access.
+- Trusted Advisor can integrate with AWS Organizations for delegated-administrator visibility across member accounts.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `Support+DescribeCases` as `isAvailableIn` in `us-east-1`, `us-west-2`, and `eu-west-1`, and `Not Found` in `ap-southeast-1`.
+- `Health+DescribeEvents` was `isAvailableIn` in `us-east-1` and `Not Found` in the other sampled regions, consistent with account/global-style evidence rather than a normal regional workload API.
+
+Review implications:
+- Triage must capture severity, customer/business impact, affected accounts/regions/services, evidence source, owner, escalation target, support entitlement, and next update time.
+- Do not claim an AWS Support or Health state unless the relevant account/source was queried or the user provided sanitized evidence.

package/skills/aws/aws-ticket-triage-escalation-coordinator/references/ticket-triage-escalation.md

@@ -0,0 +1,60 @@
+# Ticket Triage and Escalation Guide
+
+Use this reference when classifying AWS tickets, alerts, OpsItems, incidents, support cases, health events, or operational requests into priority, owner, evidence gap, and escalation path.
+
+## What people get wrong
+
+The lazy story is:
+
+> Triage means sort by severity label and assign a queue.
+
+Wrong. Severity labels are often wrong, stale, duplicated, or missing impact context. Good triage protects responders from noise while escalating real risk fast.
+
+Common bad assumptions:
+
+- The ticket title states the root cause.
+- CloudWatch alarm severity equals business severity.
+- Duplicate tickets can be closed without checking shared impact.
+- AWS Health events affect every workload in the same way.
+- Trusted Advisor findings are urgent by default.
+- Escalation is complete once a team is tagged.
+
+## Triage-specific failure modes
+
+- Misrouting IAM, KMS, networking, or data-store issues to generic platform queues.
+- Treating symptoms as root cause and assigning to the wrong owner.
+- Closing duplicates while losing the best evidence trail.
+- Escalating without logs, timeframe, resource identifiers, Region, account scope, or customer impact.
+- Ignoring incident-manager engagement, support case status, or change/deployment context.
+- Allowing ticket backlog age to hide high-risk security or compliance issues.
+
+## Minimum safe workflow
+
+1. Identify ticket type: incident, alert, request, change, cost anomaly, security finding, or informational health event.
+2. Extract evidence: affected service/resource class, account/Region, timeframe, severity, owner hints, and customer/business impact.
+3. Classify priority using impact plus urgency, not label alone.
+4. Map to accountable owner and backup escalation path.
+5. Identify missing evidence required before remediation or closure.
+6. Deduplicate carefully: link related tickets and preserve the strongest evidence record.
+7. Return safe next actions; do not mutate resources, suppress alerts, or close tickets without approval.
+
+## Verification targets
+
+- alarm or event source, timestamp, affected account/Region/service, and current state
+- AWS Health event scope and status
+- OpsCenter OpsItem or Incident Manager incident status, engagement plan, and runbook reference
+- support case severity, correspondence, and pending action owner
+- deployment/change timeline around first occurrence
+- previous related tickets, duplicate candidates, and known problem record
+- owner mapping, escalation policy, and on-call coverage
+
+## When to push back
+
+Push back if the user asks to:
+
+- close or suppress alerts because they look noisy
+- assign a ticket without sufficient evidence or owner mapping
+- paste secret-bearing logs into the ticket summary
+- downgrade priority without impact evidence
+- skip escalation for identity, encryption, data-loss, or customer-facing symptoms
+- treat triage as root-cause analysis or remediation completion

package/skills/aws/aws-waf-cost-optimization-review/SKILL.md

@@ -4,8 +4,8 @@ description: "Review AWS workload cost posture against the Well-Architected Fram
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: finops
 ---
 
@@ -36,3 +36,4 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full WAF cost review, formatting findings, or generating the savings opportunity report.
 - [Safety checklist](references/safety-checklist.md) — use before recommending any resource deletion, commitment purchase, or billing configuration change.
 - [Official sources](references/official-sources.md) — use when grounding AWS pricing models, Savings Plans, or cost management tooling.
+- [Well-Architected Cost Optimization Review Guide](references/well-architected-cost-review.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.

package/skills/aws/aws-waf-cost-optimization-review/metadata.json

@@ -15,11 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html",
-    "https://aws.amazon.com/aws-cost-management/"
+    "https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html",
+    "https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management.html",
+    "https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_manage_demand_resources.html"
   ],
   "security_notes": "Read-only advisory. Do not cancel Reserved Instances, Savings Plans, or delete resources without explicit approval and resource inventory confirmation.",
-  "last_verified": "2026-05-09",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-waf-cost-optimization-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }

package/skills/aws/aws-waf-cost-optimization-review/references/official-sources.md

@@ -1,28 +1,29 @@
-# Official Sources
+# Official sources
 
-Use when grounding AWS WAF Cost Optimization Pillar behavior or citing documentation.
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
 
-## AWS WAF Cost Optimization Pillar
+## AWS documentation
 
+Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
-- https://docs.aws.amazon.com/wellarchitected/latest/framework/a-cost-optimization.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-optimization.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_cloud_financial_management.html
+- https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_manage_demand_resources.html
 
-## Cost management tooling
-
-- https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.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
-
-## Commitment discounts
+## Grounding rule
 
-- https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
-- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
+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.
 
-## Rightsizing
+## Current MCP/documentation refresh (2026-06-02)
 
-- https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-aws-compute-optimizer.html
-- https://docs.aws.amazon.com/aws-cost-management/latest/APIReference/API_GetRightsizingRecommendation.html
+Service facts from official docs:
+- The Well-Architected Cost Optimization Pillar focuses on avoiding unnecessary cost while meeting business outcomes.
+- Cost optimization review areas include cloud financial management, expenditure awareness, cost-effective resources, demand/resource management, and continuous optimization.
 
-## Grounding rule
+Sampled live evidence:
+- Read-only API availability sampling reported `WellArchitected+GetWorkload` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Cost-review evidence still requires workload, billing, tagging, utilization, and commitment data from the user's account; Well-Architected API availability alone does not prove review status.
 
-Official documentation explains service behavior and pricing models — not the user's current account spend or commitment portfolio. Always use Cost Explorer data or user-provided evidence for spend claims.
+Review implications:
+- Require spend owner, cost allocation/tags, unit economics, utilization, rightsizing, commitment coverage, idle resources, and risk of reliability/security regression before recommending savings.
+- Do not treat Well-Architected answers or tool access as proof that cost risks are remediated.

package/skills/aws/aws-waf-cost-optimization-review/references/well-architected-cost-review.md

@@ -0,0 +1,59 @@
+# Well-Architected Cost Optimization Review Guide
+
+Use this reference for AWS Well-Architected Framework Cost Optimization Pillar reviews. In this repository, `aws-waf-cost-optimization-review` means Well-Architected Framework review, not AWS Web Application Firewall configuration.
+
+## What people get wrong
+
+The lazy story is:
+
+> Cost optimization means find idle resources and buy commitments.
+
+Wrong. Good cost review preserves business outcomes. Savings that degrade reliability, security, observability, or delivery speed are not automatically good recommendations.
+
+Common bad assumptions:
+
+- Current month spend alone proves waste.
+- Low utilization means safe rightsizing.
+- Reserved Instances or Savings Plans are safe if the discount is large.
+- Untagged resources are minor accounting issues.
+- Spot is always a cost win.
+- Deleting logs, backups, or redundancy is acceptable savings.
+
+## Cost-specific failure modes
+
+- No owner, cost allocation tags, unit-cost metric, or budget accountability.
+- Recommendations ignore seasonality, migration, incident recovery, test load, or business growth.
+- Commitment purchase locks in wrong family/Region/account or hides architecture change plans.
+- Rightsizing ignores burst, memory, I/O, latency, failover, or compliance requirements.
+- Observability, backup, security, or resilience costs are cut without risk acceptance.
+- Savings estimate uses list pricing or aggregates without amortized/unblended context.
+
+## Minimum safe workflow
+
+1. Confirm workload, payer/member account scope, monthly spend, business owner, unit economics, and cost target.
+2. Break down cost by service, account, Region, usage type, operation, tag, and resource where supported.
+3. Evaluate governance: tagging, budgets, anomaly detection, chargeback/showback, and owner accountability.
+4. Separate quick wins from structural optimization, commitment strategy, and risky workload changes.
+5. Estimate savings with assumptions, confidence, operational risk, and pillar tradeoffs.
+6. Require owner approval before deletion, downscaling, commitment purchase, retention reduction, or architecture change.
+7. Track recommendations as experiments with rollback criteria and post-change cost validation.
+
+## Verification targets
+
+- Cost Explorer/Billing data grouped by service, account, Region, usage type, operation, tag, and resource where available
+- budget, anomaly detection, cost category, and tag coverage evidence
+- utilization metrics, performance headroom, workload seasonality, and business-critical periods
+- Savings Plans/RI coverage, utilization, expiration, and purchase constraints
+- idle/underused resources with owner and purpose confirmation
+- reliability/security/observability impact for any proposed savings action
+
+## When to push back
+
+Push back if the user asks to:
+
+- recommend commitments without usage stability and roadmap evidence
+- delete backups/logs/redundancy for savings without risk acceptance
+- rights-size production from average utilization only
+- blame teams from untagged or payer-level aggregates
+- ignore security or reliability tradeoffs
+- confuse this Well-Architected Framework review with AWS Web Application Firewall cost tuning

package/skills/aws/aws-waf-reliability-review/SKILL.md

@@ -4,8 +4,8 @@ description: "Review AWS workload reliability posture against the Well-Architect
 allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-09"
+  version: "0.1.4"
+  updated: "2026-06-02"
   category: resilience
 ---
 
@@ -36,3 +36,4 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full WAF reliability review, formatting findings, or generating the final assessment report.
 - [Safety checklist](references/safety-checklist.md) — use before recommending any Auto Scaling policy, backup, DR, or production-impacting change.
 - [Official sources](references/official-sources.md) — use when grounding AWS service reliability behavior or citing WAF documentation.
+- [Well-Architected Reliability Review Guide](references/well-architected-reliability-review.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.

package/skills/aws/aws-waf-reliability-review/metadata.json

@@ -15,11 +15,13 @@
   "source_type": "original",
   "official_docs": [
     "https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html",
-    "https://aws.amazon.com/architecture/well-architected/"
+    "https://docs.aws.amazon.com/wellarchitected/latest/framework/reliability.html",
+    "https://docs.aws.amazon.com/wellarchitected/2023-10-03/framework/rel_planning_for_recovery_disaster_recovery.html",
+    "https://docs.aws.amazon.com/resilience-hub/latest/userguide/resilience-checks.html"
   ],
   "security_notes": "Read-only advisory. Do not modify Auto Scaling policies, backup schedules, or DR configurations without explicit approval.",
-  "last_verified": "2026-05-09",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-waf-reliability-review",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.4"
 }