@raishin/vanguard-frontier-agentic 2.8.0 → 2.9.0

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

package/skills/aws/aws-dynamodb-data-modeling-performance-review/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/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
 
 ## 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:
+- DynamoDB data modeling guidance centers schema design on access patterns, partition keys, sort keys, secondary indexes, and single-table versus multi-table tradeoffs.
+- Global secondary indexes support alternate partition/sort key schemas and projected attributes, but have throughput, storage, and synchronization considerations.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon DynamoDB as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `DynamoDB+DescribeTable` and `DynamoDB+Query` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not approve table design without enumerated access patterns, key cardinality/skew analysis, query-vs-scan proof, index write amplification, capacity mode, and cost/latency tradeoffs.
+- Live table status, throttling, consumed capacity, and hot partitions must come from live metrics or repo/IaC evidence, not docs.

package/skills/aws/aws-dynamodb-data-modeling-performance-review/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-dynamodb-data-modeling-performance-review/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-ec2-compute-operations-steward/SKILL.md

@@ -4,8 +4,8 @@ description: Review Amazon EC2 compute operations across instances, Auto Scaling
 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.
+- [EC2 Fleet Operations Safety Guide](references/ec2-fleet-operations-safety.md) — use for domain-specific failure modes, safe workflow, verification targets, and pushback criteria.
 
 ## Response minimum
 

package/skills/aws/aws-ec2-compute-operations-steward/metadata.json

@@ -14,14 +14,14 @@
   "summary": "Review EC2, Auto Scaling, Launch Templates, AMIs, Systems Manager, Patch Manager, EBS, snapshots, health checks, instance refresh, lifecycle hooks, and fleet operations.",
   "source_type": "original",
   "official_docs": [
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-best-practices.html",
-    "https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html",
-    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-refresh-overview.html",
-    "https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html"
+    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html",
+    "https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html",
+    "https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html",
+    "https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html"
   ],
   "security_notes": "Do not approve EC2 fleet operations without patch compliance, managed access, health checks, rollback, backup/snapshot posture, IAM instance-profile review, and launch-template evidence.",
-  "last_verified": "2026-04-29",
+  "last_verified": "2026-06-02",
   "path": "skills/aws/aws-ec2-compute-operations-steward",
   "author": "github: Raishin",
-  "version": "0.1.2"
+  "version": "0.1.4"
 }

package/skills/aws/aws-ec2-compute-operations-steward/references/ec2-fleet-operations-safety.md

@@ -0,0 +1,59 @@
+# EC2 Fleet Operations Safety Guide
+
+Use this reference for EC2, Auto Scaling groups, Launch Templates, AMIs, Systems Manager, Patch Manager, Session Manager, EBS volumes/snapshots, instance refresh, lifecycle hooks, health checks, and fleet reliability reviews.
+
+## What people get wrong
+
+The lazy story is:
+
+> EC2 is legacy; patch it, refresh it, or replace instances.
+
+Wrong. EC2 fleets hide state, pets, bootstrap drift, manual access paths, patch gaps, EBS coupling, and Auto Scaling rollout risk. Treat every host operation as potentially stateful until proven otherwise.
+
+Common bad assumptions:
+
+- Instance refresh is always safer than manual replacement.
+- Latest AMI means compliant and compatible.
+- SSM managed node status proves patch posture.
+- Session Manager removes all SSH/bastion risk.
+- EBS snapshots prove application-consistent recovery.
+- Auto Scaling health checks match customer health.
+
+## EC2 operations failure modes
+
+- Launch Template update changes IAM, user data, security groups, block devices, or AMI unexpectedly.
+- Instance refresh drains capacity without lifecycle hooks, warmup, health checks, or rollback target.
+- Patch Manager compliance misses unmanaged nodes, maintenance windows, or reboot requirements.
+- Session Manager lacks logging, KMS, VPC endpoint, or least-privilege controls.
+- EBS volume performance, burst balance, attachment, encryption, or snapshot consistency is ignored.
+- Pets/manual changes create drift from AMI/bootstrap expectations.
+
+## Minimum safe workflow
+
+1. Identify fleet: instances, Auto Scaling groups, Launch Templates, AMIs, subnets, load balancers, and stateful dependencies.
+2. Review access/management: SSM managed node status, Session Manager, IAM instance profile, patch baseline, and logging.
+3. Review rollout safety: instance refresh settings, lifecycle hooks, health checks, desired/min/max capacity, warm pools, and rollback AMI/template version.
+4. Check storage/recovery: EBS volumes, snapshots, encryption, application consistency, and attachment behavior.
+5. Review observability: EC2 status checks, CloudWatch agent, logs, alarms, load balancer target health, and application health.
+6. Recommend staged, reversible changes; stop/terminate/reboot/refresh actions require explicit approval.
+7. Separate host configuration evidence from live workload health evidence.
+
+## Verification targets
+
+- EC2 instance state, status checks, AMI, user data, IAM instance profile, security groups, tags, and SSM managed node status
+- Auto Scaling group desired/min/max capacity, Launch Template version, instance refresh, lifecycle hooks, warmup, health check type, and rollback target
+- Systems Manager Patch Manager baseline, compliance, maintenance windows, State Manager associations, Inventory, and Session Manager logging/KMS settings
+- EBS volume type, size, IOPS/throughput, burst balance, encryption, snapshots, and application-consistent backup evidence
+- load balancer target health, CloudWatch metrics/logs, CloudWatch agent, alarms, and recent change/deployment timeline
+- SSH/bastion exposure, Session Manager endpoint policy, VPC endpoints, and break-glass path
+
+## When to push back
+
+Push back if the user asks to:
+
+- terminate/reboot/refresh instances without state and capacity proof
+- roll forward to latest AMI without compatibility and rollback target
+- ignore unmanaged nodes in patch reports
+- disable health checks or lifecycle hooks to speed rollout
+- treat EBS snapshots as application-consistent without evidence
+- broaden SSH/Session Manager access for convenience

package/skills/aws/aws-ec2-compute-operations-steward/references/official-sources.md

@@ -5,11 +5,25 @@ Use this reference only when you need source grounding for AWS service behavior
 ## AWS documentation
 
 Use these as starting points, not as proof of the user's live AWS state:
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-best-practices.html
-- https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html
-- https://docs.aws.amazon.com/autoscaling/ec2/userguide/instance-refresh-overview.html
-- https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html
+- https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html
+- https://docs.aws.amazon.com/autoscaling/ec2/userguide/ts-as-instancelaunchfailure.html
+- https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html
+- https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.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:
+- EC2 Auto Scaling manages EC2 capacity automatically through groups, health checks, scaling policies, and instance lifecycle behavior.
+- Auto Scaling launch failures can come from unsupported configurations, missing security groups or key pairs, unsupported instance/AZ combinations, Spot capacity, encrypted EBS permission errors, and instance limits.
+
+Sampled live evidence:
+- Read-only regional availability sampling reported Amazon EC2, AWS Systems Manager, and Amazon EC2 Auto Scaling as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
+- Sampled APIs `EC2+DescribeInstances`, `SSM+DescribeInstanceInformation`, and `Auto Scaling+DescribeAutoScalingGroups` were reported `isAvailableIn` in those regions.
+
+Review implications:
+- Do not treat EC2 fleets as managed unless SSM registration, patch compliance, AMI/launch-template currency, health checks, alarms, backups/snapshots, and rollback paths are evidenced.
+- Operations guidance must separate observation from mutation; remediation actions such as instance refresh, stop/start, termination, or patching need explicit approval gates.

package/skills/aws/aws-ec2-compute-operations-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, 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