@raishin/vanguard-frontier-agentic 2.7.1 → 2.9.0

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

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

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

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

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

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

package/skills/aws/aws-data-protection-backup-steward/references/official-sources.md

@@ -6,10 +6,24 @@ Use this reference only when you need source grounding for AWS service behavior
 
 Use these as starting points, not as proof of the user's live AWS state:
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html
+- https://docs.aws.amazon.com/aws-backup/latest/devguide/logicallyairgappedvault.html
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
 - https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-account-backup.html
-- https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html
 
 ## Grounding rule
 
-Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, or operational state. Prefer live AWS MCP/CLI evidence or sanitized user-provided evidence for current-state claims.
+Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.
+
+## Current MCP/documentation refresh (2026-06-02)
+
+Service facts from official docs:
+- AWS Backup logically air-gapped vaults are isolated vaults intended to secure backups, support cross-account sharing, multi-party approval recovery, and cross-Region copies.
+- AWS Backup vault lock, cross-account backup, lifecycle, encryption, and restore workflows are design inputs; recoverability is proven only by successful restore evidence against the required RTO/RPO.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS Backup as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `Backup+ListBackupVaults` and `Backup+ListRecoveryPointsByBackupVault` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Backup existence is not recovery readiness. Require restore-test results, restore IAM/KMS access, backup selection scope, lifecycle/retention evidence, vault lock posture, copy status, and recovery-account access.
+- Treat ransomware-resilience claims as unproven without isolation, immutability or lock controls, cross-account/cross-Region strategy, and tested recovery.

package/skills/aws/aws-data-protection-backup-steward/references/safety-checklist.md

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

package/skills/aws/aws-data-protection-backup-steward/references/workflow-and-output.md

@@ -19,7 +19,7 @@ Check these areas before giving a verdict:
    - Required outcome:
    - Explicit non-goals:
 2. **Collect evidence**
-   - Prefer live AWS MCP read-only evidence if available.
+   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
    - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
    - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
 3. **Stress-test risk**

package/skills/aws/aws-deployment-hotfix-operator/SKILL.md

@@ -4,8 +4,8 @@ description: Patch AWS deployment hotfix config, release parameters, manifest mi
 allowed-tools: Read Edit Write MultiEdit Grep Glob
 metadata:
   author: "github: Raishin"
-  version: "0.1.0"
-  updated: "2026-05-05"
+  version: "0.1.2"
+  updated: "2026-06-02"
   category: delivery
 ---
 
@@ -25,7 +25,7 @@ Use this skill for:
 
 ## Lean operating rules
 
-- Prefer `AwsDocumentationMcpServer` when available via `uvx awslabs.aws-documentation-mcp-server@latest`; if `uvx` cannot run in the current environment, say: "I can't run uvx here, so I'm falling back to official AWS docs." Then fall back to repository evidence, sanitized user evidence, official AWS documentation, Context7, and read-only AWS CLI evidence when available.
+- Prefer current AWS documentation tools for service behavior. Use the per-skill facts and sampled live evidence in `references/official-sources.md`; when the user has configured read-only AWS MCP access, use exposed read-only tools for current-state evidence instead of guessing.
 - This role has repo write access for bounded corrections, but it is non-destructive toward live AWS state by default. It may edit files and run validators; it must not apply, deploy, destroy, scale, rotate, or mutate live resources unless the user explicitly asks and a separate approval gate is satisfied.
 - Separate confirmed facts from inference. If state was not queried or shown, say so.
 - Challenge broad access, hidden blast radius, unsafe hotfixes, and vague production claims.
@@ -39,6 +39,7 @@ Load these only when needed:
 - [Workflow and output contract](references/workflow-and-output.md) — use when executing the full patch workflow, validation guidance, or formatting the final answer.
 - [Safety checklist](references/safety-checklist.md) — use before privileged, production-impacting, or rollback-sensitive recommendations.
 - [Official sources](references/official-sources.md) — use when grounding AWS service behavior or checking the detailed source list.
+- [Deployment Hotfix Safety Guide](references/deployment-hotfix-safety.md) — use for domain-specific failure modes, safe patch workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-deployment-hotfix-operator/metadata.json

@@ -14,12 +14,14 @@
   "summary": "Patch AWS deployment manifests, environment config, release toggles, and rollout settings quickly in-repo with explicit rollback notes and no live-cloud mutation by default.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/plan-your-change-management-strategy.html",
-    "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design_principles.html"
+    "https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html",
+    "https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html",
+    "https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html",
+    "https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html"
   ],
   "security_notes": "Repo write access only. Do not deploy, apply, destroy, or mutate live AWS resources from this role by default. Require explicit human approval for any step beyond repo patching and validation.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-deployment-hotfix-operator",
   "author": "github: Raishin",
-  "version": "0.1.0"
+  "version": "0.1.2"
 }

package/skills/aws/aws-deployment-hotfix-operator/references/deployment-hotfix-safety.md

@@ -0,0 +1,64 @@
+# Deployment Hotfix Safety Guide
+
+Use this reference for repo-side deployment hotfixes involving manifests, release parameters, environment wiring, deployment groups, pipeline inputs, rollback blockers, or emergency config correction.
+
+## What people get wrong
+
+The lazy story is:
+
+> Hotfix means speed matters more than process.
+
+Wrong. Hotfixes need less surface area, not less discipline. The fastest unsafe diff is how incidents become outages.
+
+Common bad assumptions:
+
+- Emergency context justifies broad config changes.
+- A successful validator means production is safe.
+- Rollback is obvious because Git has history.
+- Deployment parameters are not security-sensitive.
+- Temporarily disabling checks is acceptable if we re-enable later.
+- The deployment tool will catch blast-radius issues.
+
+## Hotfix risk classes
+
+Classify the patch before editing:
+
+- **Parameter fix:** wrong environment, ARN, image tag, feature flag, or region.
+- **Manifest/schema fix:** invalid YAML/JSON/IaC shape blocking deploy.
+- **Rollback unblocker:** restore previous deployment path or remove a bad forward-only change.
+- **Guardrail fix:** re-enable alarm, approval, rollback, or validation control.
+- **Risky workaround:** disables checks, widens permissions, changes traffic, or hides evidence.
+
+Only the first four are normal for this skill. The fifth needs explicit risk acceptance.
+
+## Minimum safe workflow
+
+1. State the failed deployment symptom and evidence source.
+2. Identify the exact file/field causing the blocker.
+3. Make the smallest diff that corrects only that blocker.
+4. Preserve or improve rollback controls; never remove them silently.
+5. Run syntax/schema/project validators.
+6. Explain runtime effect and non-effect: what will change only after a separate deployment.
+7. Provide rollback diff or revert command.
+
+## Verification targets
+
+- deployment manifest diff
+- release parameter source and target environment
+- deployment group rollback settings
+- pipeline approval/gate settings
+- image/artifact/revision identity
+- IaC template validation or buildspec/workflow lint
+- CloudFormation/CodeDeploy/CodePipeline docs when service behavior matters
+
+## When to push back
+
+Push back if the user asks to:
+
+- bypass approvals to “save time”
+- disable rollback alarms or deployment gates
+- widen IAM to unblock a deploy without root cause
+- change multiple environments in one hotfix
+- patch secrets or credentials into repo files
+- treat repo edit as proof that production is fixed
+

package/skills/aws/aws-deployment-hotfix-operator/references/official-sources.md

@@ -1,4 +1,29 @@
 # Official sources
 
-- https://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/plan-your-change-management-strategy.html
-- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design_principles.html
+Use this reference only when you need source grounding for AWS service behavior or the detailed source list.
+
+## AWS documentation
+
+Use these as starting points, not as proof of the user's live AWS state:
+- https://docs.aws.amazon.com/config/latest/developerguide/codedeploy-deployment-group-auto-rollback-enabled.html
+- https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html
+- https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
+- https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.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:
+- AWS Config has a managed rule for CodeDeploy deployment groups with auto rollback enabled, marking deployment groups non-compliant when rollback is disabled.
+- Deployment hotfix safety depends on rollback plan, change-management context, and actual deployment service configuration; repository edits alone do not prove production rollback readiness.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported AWS CodeDeploy, AWS CodePipeline, and AWS CloudFormation as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `CodeDeploy+GetDeployment`, `CodePipeline+GetPipelineState`, and `CloudFormation+DescribeStacks` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Keep hotfixes repo-scoped unless the user explicitly asks for live action and approval gates are satisfied.
+- Require smallest-diff patching, validation command output, rollback instructions, and clear separation between file correction and live deployment execution.

package/skills/aws/aws-devops-agent-skill-designer/SKILL.md

@@ -4,8 +4,8 @@ description: Design, review, and improve AWS DevOps Agent-compatible skills, inv
 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.
+- [DevOps Agent Skill Quality Guide](references/devops-agent-skill-quality.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-devops-agent-skill-designer/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Design AWS DevOps Agent-compatible skills, investigation workflows, learned skills, tool-use best practices, agent targeting, frontmatter triggers, and operational output contracts.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html",
-    "https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-learned-skills.html",
+    "https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-proactive-incident-prevention.html",
+    "https://docs.aws.amazon.com/devops-guru/latest/userguide/monitoring-cloudwatch.html",
     "https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html",
-    "https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html"
+    "https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html"
   ],
   "security_notes": "Do not create AWS DevOps Agent skills with vague descriptions, broad agent targeting, secret-handling instructions, unsupported executable assumptions, or missing success criteria.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-devops-agent-skill-designer",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-devops-agent-skill-designer/references/devops-agent-skill-quality.md

@@ -0,0 +1,59 @@
+# DevOps Agent Skill Quality Guide
+
+Use this reference when designing or reviewing AWS DevOps Agent skills, learned skills, incident investigation workflows, tool-use best practices, frontmatter descriptions, and operational output contracts.
+
+## What people get wrong
+
+The lazy story is:
+
+> A good skill is a detailed runbook pasted into SKILL.md.
+
+Wrong. A useful DevOps Agent skill triggers correctly, loads progressively, constrains tool use, separates evidence from inference, and has deterministic evaluation criteria.
+
+Common bad assumptions:
+
+- More instructions mean better behavior.
+- Broad descriptions improve triggering.
+- Learned skills can safely encode environment-specific secrets or account details.
+- Tool guidance is safe if it says “read-only” once.
+- RCA/mitigation/evaluation can live in one vague workflow.
+- A skill is done without tests or example failure cases.
+
+## Skill-design failure modes
+
+- Frontmatter description is too broad and steals unrelated tasks.
+- SKILL.md bloats with reference material instead of progressive disclosure.
+- Tool instructions allow mutation without approval gates.
+- Incident workflow claims root cause from weak evidence.
+- Learned skill contains internal role names, customer identifiers, account IDs, or secret-bearing commands.
+- Output contract lacks verdict, evidence level, blockers, safe next actions, and open questions.
+
+## Minimum safe workflow
+
+1. Define target agent type, use cases, non-use cases, and trigger boundaries.
+2. Keep SKILL.md lean: purpose, when to use, operating rules, references, and response minimum.
+3. Move domain depth into references with failure modes, workflow, verification targets, and pushback criteria.
+4. Specify allowed tools and mutation boundaries; require approval for live changes.
+5. Add eval criteria before editing: trigger fit, safety gates, source grounding, output contract, and no internal identifiers.
+6. Validate schema, manifests, links, and examples.
+7. Document what evidence the skill can and cannot prove.
+
+## Verification targets
+
+- AWS DevOps Agent skill structure, SKILL.md frontmatter, references, and packaging constraints
+- trigger description clarity, anti-triggers, role targeting, and allowed tools
+- learned-skill content for topology, tool patterns, automatic updates, activation/deactivation implications
+- safety checklist, source grounding, live evidence labels, mutation gates, and final response contract
+- eval files, deterministic graders, schema validation, manifest validation, and no-secret/no-internal-identifier scans
+- example incident or workflow prompts that prove the skill triggers only where intended
+
+## When to push back
+
+Push back if the user asks to:
+
+- paste a giant runbook into SKILL.md
+- include account IDs, internal role names, tokens, or environment-specific secrets
+- make a skill trigger for every AWS problem
+- allow remediation tools without approval and rollback rules
+- skip evals because the skill “reads well”
+- mix unrelated domains into one agent skill for convenience

package/skills/aws/aws-devops-agent-skill-designer/references/official-sources.md

@@ -5,11 +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/devopsagent/latest/userguide/about-aws-devops-agent-devops-agent-skills.html
-- https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent-learned-skills.html
+- https://docs.aws.amazon.com/devopsagent/latest/userguide/working-with-devops-agent-proactive-incident-prevention.html
+- https://docs.aws.amazon.com/devops-guru/latest/userguide/monitoring-cloudwatch.html
 - https://docs.aws.amazon.com/devopsagent/latest/userguide/about-aws-devops-agent.html
-- https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html
+- https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-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:
+- AWS DevOps Agent proactive incident prevention analyzes incident patterns, ranks improvements, and can generate agent-ready specifications.
+- DevOps Guru monitoring guidance exposes insight and usage metrics through CloudWatch; those metrics are evidence inputs for operational skill design, not proof that a skill is effective.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported `DevOps Guru+DescribeInsight` and `DevOps Guru+ListInsights` as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+
+Review implications:
+- Skill design must define trigger boundaries, evidence collection steps, output contracts, and evaluation criteria; vague incident prose is not enough.
+- Treat DevOps Agent recommendations as candidates that need owner approval, validation, rollback planning, and eval coverage before implementation.

package/skills/aws/aws-devops-agent-skill-designer/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-devops-agent-skill-designer/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-dynamodb-data-modeling-performance-review/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon DynamoDB data modeling and performance across access
 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: data
 ---
 
@@ -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.
+- [DynamoDB Access Patterns and Capacity Guide](references/dynamodb-access-patterns-capacity.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-dynamodb-data-modeling-performance-review/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review DynamoDB table design, partition keys, sort keys, GSIs/LSIs, hot partitions, query/scan patterns, capacity, global tables, TTL, DAX, and cost/performance tradeoffs.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html",
-    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html",
-    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-indexes.html",
-    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Query.html"
+    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/data-modeling.html",
+    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-table-design.html",
+    "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GSI.html",
+    "https://docs.aws.amazon.com/prescriptive-guidance/latest/dynamodb-data-modeling/best-practices.html"
   ],
   "security_notes": "Do not recommend DynamoDB schemas without explicit access patterns, partition cardinality, index tradeoffs, capacity/cost implications, and migration or backfill safety.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-dynamodb-data-modeling-performance-review",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-dynamodb-data-modeling-performance-review/references/dynamodb-access-patterns-capacity.md

@@ -0,0 +1,59 @@
+# DynamoDB Access Patterns and Capacity Guide
+
+Use this reference for DynamoDB table design, partition/sort keys, GSIs/LSIs, hot partitions, capacity mode, adaptive capacity, TTL, streams, global tables, transactions, DAX, and cost/performance reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> Pick a partition key and add GSIs when queries need them.
+
+Wrong. DynamoDB design starts with access patterns, cardinality, item size, write distribution, consistency needs, and growth model. Indexes are not a rescue plan for unknown queries.
+
+Common bad assumptions:
+
+- High-cardinality key always avoids hot partitions.
+- Adaptive capacity fixes bad key design.
+- Scans are acceptable until scale arrives.
+- On-demand capacity eliminates throttling and cost planning.
+- GSI backfill is operationally harmless.
+- Global tables solve DR without conflict and latency tradeoffs.
+
+## DynamoDB-specific failure modes
+
+- Partition key concentrates reads/writes on tenant, status, date, or celebrity keys.
+- Sort key does not support required range, prefix, ordering, or uniqueness patterns.
+- GSI projection/backfill doubles write cost or throttles production.
+- LSI item collection limits or large items break growth assumptions.
+- TTL deletion timing is treated as immediate business logic.
+- Transactions, conditional writes, streams, and idempotency are not modeled for retries.
+
+## Minimum safe workflow
+
+1. List concrete access patterns: operation, key condition, filter, consistency, frequency, latency, and expected cardinality.
+2. Model entities and item collections against partition/sort keys before proposing tables/indexes.
+3. Check write/read distribution, hot-key risk, item size, projected growth, and capacity mode.
+4. Review indexes: GSI/LSI keys, projection, sparse behavior, backfill risk, and query shapes.
+5. Validate operational controls: autoscaling/on-demand, alarms, Contributor Insights, TTL, streams, backups, and global tables.
+6. Estimate cost and failure mode for peak traffic, backfills, retries, and scans.
+7. State what cannot be proven without production traffic or representative workload tests.
+
+## Verification targets
+
+- access pattern matrix with key condition expressions, not just entity names
+- table partition/sort keys, item collection examples, GSI/LSI definitions, projections, and sparse-index behavior
+- CloudWatch metrics: throttles, consumed capacity, account/table limits, latency, system errors, and hot key signals
+- Contributor Insights, adaptive capacity symptoms, split-for-heat context, and key distribution evidence
+- capacity mode, autoscaling targets, reserved capacity, on-demand cost, backfill plan, and alarms
+- TTL, streams, transactions, conditional writes, DAX, global tables, PITR/backups, and restore testing
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve a table without access patterns
+- use scans or filters as primary query strategy
+- add GSIs blindly for every future query
+- ignore hot partition risk because adaptive capacity exists
+- use TTL for exact deletion workflows
+- enable global tables without conflict, replication, and failover design