@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

package/skills/aws/aws-bedrock-agent-security-governor/references/bedrock-agent-attack-surface.md

@@ -0,0 +1,59 @@
+# Bedrock Agent Attack Surface Guide
+
+Use this reference for Amazon Bedrock agents, AgentCore, Guardrails, Knowledge Bases, action groups, memory, tool/MCP integrations, prompt-injection defenses, PII handling, encryption, logging, and least-privilege review.
+
+## What people get wrong
+
+The lazy story is:
+
+> Guardrails plus IAM makes a Bedrock agent safe.
+
+Wrong. Agent risk comes from composition: prompt instructions, retrieved data, memory, tool schemas, action-group permissions, logging, and downstream APIs interact in ways a single control cannot prove safe.
+
+Common bad assumptions:
+
+- Guardrails are an authorization boundary.
+- Knowledge Base retrieval is safe if the S3/OpenSearch source is trusted.
+- Action groups are safe because Lambda has IAM.
+- Memory improves UX without creating poisoning or retention risk.
+- Tool descriptions cannot leak sensitive implementation details.
+- Model access availability proves agent production readiness.
+
+## Bedrock-agent failure modes
+
+- Prompt injection causes tool calls, data exfiltration, or policy bypass through retrieved context.
+- Knowledge Base metadata filters do not enforce user-level authorization.
+- Action group Lambda role can mutate or read resources beyond the agent use case.
+- Guardrails block output but not downstream side effects already triggered by tools.
+- Logs/traces capture prompts, PII, retrieved documents, credentials, or tool payloads.
+- Memory or session state stores sensitive data without retention, deletion, or tenant boundary controls.
+
+## Minimum safe workflow
+
+1. Identify agent, model, Region, users, data classification, tools/action groups, knowledge sources, memory, and output channels.
+2. Map trust boundaries: user prompt, system prompt, retrieved context, tool schema, Lambda/action group, downstream API, and logs.
+3. Review Guardrails as defense-in-depth, not authorization; check denied topics, sensitive information filters, contextual grounding, and intervention telemetry.
+4. Verify least privilege for action groups, service roles, knowledge base data sources, KMS keys, and logging destinations.
+5. Define adversarial evals: prompt injection, data leakage, unauthorized retrieval, unsafe tool call, refusal, and jailbreak cases.
+6. Require observability with redaction: guardrail interventions, tool calls, model errors, token/cost, latency, and audit events.
+7. Do not approve production release without eval evidence, rollback/fallback, and owner signoff.
+
+## Verification targets
+
+- Bedrock agent configuration, model, aliases/versions, Guardrails, prompts, orchestration, and action group schemas
+- Knowledge Base data source, sync status, metadata filters, vector store access, S3/KMS policies, and tenant/data boundaries
+- action group Lambda/API permissions, IAM trust, resource policies, network access, and side-effect controls
+- AgentCore runtime/gateway/memory/tool integration boundaries where applicable
+- CloudWatch/CloudTrail logs, GenAI observability, prompt/tool redaction, retention, and alerting
+- eval suite for injection, leakage, unsafe tool invocation, grounding, PII handling, and cost/latency thresholds
+
+## When to push back
+
+Push back if the user asks to:
+
+- treat Guardrails as a complete security boundary
+- allow agent tools to mutate production without approval gates
+- use broad Bedrock, Lambda, S3, or KMS permissions
+- skip adversarial prompt and retrieval evals
+- log raw prompts, retrieved documents, or tool payloads broadly
+- claim agent safety from documentation or service availability alone

package/skills/aws/aws-bedrock-agent-security-governor/references/official-sources.md

@@ -12,4 +12,17 @@ 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:
+- Bedrock prompt-injection guidance says Guardrails can detect prompt attacks, but customers still need application controls such as input validation, guardrail association, and safer prompt design.
+- Bedrock CloudTrail guidance covers Bedrock API activity; logging proves calls occurred, not whether an agent decision was safe.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for Amazon Bedrock in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+
+Review implications:
+- Guardrails and prompt-injection controls reduce risk; they do not prove a specific agent, action group, knowledge base, or tool integration is safe.
+- Require evidence for IAM scope, data-source boundaries, logging, model/tool invocation paths, memory retention, PII handling, and kill-switch behavior before production readiness claims.

package/skills/aws/aws-bedrock-agent-security-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, 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-bedrock-agent-security-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-change-impact-advisor/SKILL.md

@@ -4,8 +4,8 @@ description: Assess AWS change impact using change sets, deployment blast radius
 allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  updated: "2026-06-02"
   category: delivery
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - This role is non-destructive by default. Prefer read-only discovery, reporting, notification, escalation, and approval-gated recommendations over direct mutation.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, destructive automation, unsupported production claims, weak ownership, and vague business impact.
@@ -40,6 +40,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, advisory workflow, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, cost-changing, compliance-impacting, or production-impacting recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [Change Impact Assessment Guide](references/change-impact-assessment.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-change-impact-advisor/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design_principles.html"
   ],
   "security_notes": "This role is advisory only. Do not approve execution from weak evidence. Require explicit rollback, dependency, owner, and communication clarity before treating a change as low-risk.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-change-impact-advisor",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-change-impact-advisor/references/change-impact-assessment.md

@@ -0,0 +1,59 @@
+# Change Impact Assessment Guide
+
+Use this reference when assessing planned AWS changes, rollback readiness, blast radius, maintenance windows, change calendars, dependency risk, and go/no-go recommendations.
+
+## What people get wrong
+
+The lazy story is:
+
+> If the deployment tool accepts the change, impact is understood.
+
+Wrong. Tool acceptance is not impact analysis. A valid change can still replace stateful resources, breach a freeze window, break downstream consumers, or leave the business without a rollback decision.
+
+Common bad assumptions:
+
+- A CloudFormation change set, Terraform plan, or pipeline diff is automatically business-safe.
+- Low line-count equals low blast radius.
+- Rollback exists because Git can revert the commit.
+- Change calendars and maintenance windows are scheduling details, not controls.
+- A service owner approval covers dependent teams.
+- Read-only evidence from one Region proves global readiness.
+
+## Change-specific failure modes
+
+- Change set or plan hides replacement, delete, interruption, or data-retention risk.
+- Dependency owners are missing for shared VPCs, IAM roles, KMS keys, event buses, queues, DNS, or certificates.
+- Rollback requires data migration reversal, alias retargeting, previous image digests, parameter restoration, or manual state repair.
+- Maintenance window conflicts with business freeze, AWS Health event, support case, or downstream release.
+- Monitoring and alarms do not cover the changed path.
+- Approval is given by the implementer instead of an accountable service owner.
+
+## Minimum safe workflow
+
+1. Identify the change type, target account/Region/environment, owner, and requested execution window.
+2. Gather repository diff, change set/plan if available, affected services, dependencies, and rollback artifact.
+3. Classify blast radius: customer-facing, data-bearing, identity/network, cost-affecting, or control-plane only.
+4. Check scheduling controls: change calendar, maintenance window, freeze period, AWS Health context, and stakeholder availability.
+5. Separate confirmed evidence from assumptions; do not fill unknowns with optimism.
+6. Return a go/no-go recommendation with blockers, conditions, rollback notes, and communication plan.
+7. Keep the role advisory; do not approve or execute the change from this skill.
+
+## Verification targets
+
+- change set, Terraform plan, CDK diff, SAM/CloudFormation diff, or pipeline release notes
+- resource replacement/delete/interruption indicators
+- rollback artifact: previous template, alias target, image digest, parameter set, migration rollback, or restore point
+- impacted AWS services, accounts, Regions, VPCs, IAM principals, data stores, queues, DNS records, and certificates
+- maintenance window, Change Calendar/Change Manager request, approval record, and on-call coverage
+- CloudWatch alarms, AWS Health events, support cases, and incident backlog relevant to the change window
+
+## When to push back
+
+Push back if the user asks to:
+
+- declare low risk from a diff without blast-radius evidence
+- ignore replacement/delete risk because validation passed
+- proceed without owner approval or rollback artifact
+- execute during a freeze, health event, or unresolved incident without risk acceptance
+- treat advisory review as deployment approval
+- hide unknowns from stakeholders

package/skills/aws/aws-change-impact-advisor/references/official-sources.md

@@ -10,3 +10,16 @@ Use this reference when grounding current AWS service behavior for this role.
 ## Grounding rule
 
 Docs explain service behavior. They do not prove the user's deployed state, ownership, SLAs, budget posture, or current incident reality.
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- CloudFormation drift-aware change sets support three-way comparison and can use `REVERT_DRIFT` to revert out-of-band changes where supported.
+- Change-set and drift evidence is pre-change evidence only; it does not prove stakeholder approval, runtime health, or rollback readiness.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for AWS CloudFormation and AWS Config in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CloudFormation+CreateChangeSet` and `CloudFormation+DetectStackDrift` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Change sets and drift checks are evidence inputs, not approval by themselves.
+- Require owner, blast radius, dependencies, rollback path, monitoring, communication plan, and explicit decision authority before go/no-go recommendations.

package/skills/aws/aws-ci-cd-release-engineer/SKILL.md

@@ -4,8 +4,8 @@ description: Review AWS CI/CD and release safety across CodePipeline, CodeBuild,
 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: delivery
 ---
 
@@ -26,7 +26,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - 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.
+- [Release Safety and Provenance Guide](references/release-safety-and-provenance.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ci-cd-release-engineer/metadata.json

@@ -20,8 +20,8 @@
     "https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html"
   ],
   "security_notes": "Do not approve production pipelines without artifact integrity, least-privilege deploy roles, quality/security gates, deployment telemetry, rollback criteria, and post-deploy validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ci-cd-release-engineer",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ci-cd-release-engineer/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 Well-Architected operational guidance recommends build/deployment management systems and automated change management to reduce manual deployment error.
+- CodeDeploy rollback documentation is relevant to deployment safety, but rollback behavior still depends on each deployment group/application configuration.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `isAvailableIn` for AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodePipeline+GetPipelineState` and `CodeDeploy+GetDeployment` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Pipeline existence is not release safety. Require gates, test evidence, artifact integrity/provenance, least-privilege deployment roles, telemetry, rollback criteria, and post-deploy validation.
+- Docs do not prove the user's pipeline configuration, branch protections, approvals, or production deployment state.

package/skills/aws/aws-ci-cd-release-engineer/references/release-safety-and-provenance.md

@@ -0,0 +1,59 @@
+# Release Safety and Provenance Guide
+
+Use this reference for AWS release pipeline reviews covering CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, GitLab, artifact provenance, approvals, deployment gates, progressive delivery, rollback, and change correlation.
+
+## What people get wrong
+
+The lazy story is:
+
+> If the pipeline is green, the release is safe.
+
+Wrong. Green means a configured path passed. It does not prove artifact identity, environment isolation, approval quality, rollback readiness, or runtime health after deploy.
+
+Common bad assumptions:
+
+- Build success equals deploy readiness.
+- Manual approval is meaningful without evidence attached.
+- Artifact bucket/KMS policy is plumbing, not supply-chain control.
+- Re-running a failed pipeline is safe.
+- CodeDeploy rollback exists because CodeDeploy is used.
+- GitHub/GitLab workflow permissions are separate from AWS risk.
+
+## Release-specific failure modes
+
+- Source revision, artifact, image digest, and deployment target are not tied together.
+- Pipeline role or OIDC trust allows unintended branch, repo, environment, or account deployment.
+- Tests run against mocks while production deploy changes IAM/network/data paths.
+- Approval gates lack diff, risk, change ticket, owner, rollback, and blast-radius evidence.
+- CodeDeploy canary/blue-green alarms or hooks are absent or not customer-relevant.
+- Parallel/queued execution mode creates out-of-order source revisions or stale definitions.
+
+## Minimum safe workflow
+
+1. Identify source, build, artifact, approval, deploy, verification, and rollback stages.
+2. Trace provenance from commit to artifact/image digest to deployment target.
+3. Review secrets, OIDC/IAM roles, artifact bucket/KMS, and cross-account trust.
+4. Evaluate gates: tests, security scans, policy checks, manual approval evidence, and change windows.
+5. Verify deployment strategy: canary, blue/green, linear, all-at-once, rollback alarms, and post-deploy checks.
+6. Correlate releases with incidents using deployment timestamps and runtime telemetry.
+7. Recommend changes as review guidance; live reruns/deploys require explicit approval.
+
+## Verification targets
+
+- CodePipeline stage/action definitions, execution mode, source revision, artifact store, KMS key, and service role
+- CodeBuild buildspec, environment image, privileged mode, secrets, cache, reports, and artifact outputs
+- CodeDeploy deployment group, AppSpec, hooks, deployment config, alarms, and rollback settings
+- GitHub Actions/GitLab OIDC trust, branch/environment protections, required checks, and secret scoping
+- artifact/image signing, digest pinning, SBOM/provenance, promotion rules, and immutable release IDs
+- post-deploy metrics, synthetic checks, alarms, incident correlation, and rollback runbook
+
+## When to push back
+
+Push back if the user asks to:
+
+- remove tests, gates, or approvals to speed release
+- deploy from mutable tags without digest/provenance controls
+- rerun production pipelines without understanding failed stage and source revision
+- broaden deploy roles or OIDC trust as a shortcut
+- call manual approval sufficient without attached risk evidence
+- skip rollback alarms or post-deploy validation

package/skills/aws/aws-ci-cd-release-engineer/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-ci-cd-release-engineer/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-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"
 }