@raishin/vanguard-frontier-agentic 1.0.0 → 1.2.0

package/skills/aws/README.md

@@ -0,0 +1,69 @@
+# AWS Skills
+
+<img src="../../assets/logos/cloud/aws/aws-cdnlogo.png" alt="AWS logo" width="140" />
+
+
+This folder contains AWS-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+As of **2026-04-29**, this folder contains **42** local AWS skills:
+
+- `aws-agentcore`
+- `aws-api-edge-delivery-review`
+- `aws-bedrock-agent-security-governor`
+- `aws-change-impact-advisor`
+- `aws-ci-cd-release-engineer`
+- `aws-compliance-evidence-mapper`
+- `aws-cost-anomaly-watch-coordinator`
+- `aws-cost-optimization-governor`
+- `aws-daily-operations-briefing-coordinator`
+- `aws-data-protection-backup-steward`
+- `aws-deployment-hotfix-operator`
+- `aws-devops-agent-skill-designer`
+- `aws-dynamodb-data-modeling-performance-review`
+- `aws-ec2-compute-operations-steward`
+- `aws-ecs-fargate-platform-operator`
+- `aws-ecs-service-remediation-operator`
+- `aws-eks-platform-operator`
+- `aws-event-driven-architecture-review`
+- `aws-generative-ai-developer`
+- `aws-iac-change-safety-review`
+- `aws-iac-patch-executor`
+- `aws-iam-least-privilege-review`
+- `aws-kms-secrets-lifecycle-steward`
+- `aws-landing-zone-governor`
+- `aws-live-deployment-guarded-operator`
+- `aws-live-ecs-rollout-guard`
+- `aws-live-iac-change-guard`
+- `aws-live-pipeline-approval-operator`
+- `aws-live-serverless-release-guard`
+- `aws-migration-cutover-architect`
+- `aws-network-architect`
+- `aws-non-destructive-task-automation-advisor`
+- `aws-observability-incident-responder`
+- `aws-pipeline-fix-operator`
+- `aws-rds-aurora-performance-investigator`
+- `aws-resilience-bcdr-review`
+- `aws-s3-data-perimeter-governor`
+- `aws-security-posture-hardening`
+- `aws-serverless-production-readiness`
+- `aws-serverless-rollout-corrector`
+- `aws-solution-architect`
+- `aws-ticket-triage-escalation-coordinator`
+
+## Portfolio posture
+
+Role-based AWS skills for evidence-backed architecture, operations, security, resilience, migration, agentic systems, FinOps workflows, bounded execution, and guarded live-environment operations.
+
+These skills are intentionally conservative:
+
+- prefer `AwsDocumentationMcpServer` via `uvx awslabs.aws-documentation-mcp-server@latest` when available for AWS documentation grounding,
+- 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 official AWS docs, Context7, repo evidence, and read-only AWS CLI evidence when available,
+- prefer read-only discovery before mutation,
+- separate repo patching from live AWS mutation,
+- require explicit target confirmation, approval, rollback posture, and verification for guarded live actions,
+- challenge broad IAM, public exposure, untested recovery, skipped previews, and unclear ownership,
+- use official AWS documentation and Context7 grounding when service behavior matters.
+
+Run `npm run validate` after changing cataloged AWS skills.

package/skills/aws/aws-agentcore/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: aws-agentcore
+description: Build, test, migrate, integrate, and deploy Amazon Bedrock AgentCore agents. Use for AgentCore runtime, local development, import/migration, deployment, Memory, Gateway/MCP tools, Identity, Observability, Browser, Code Interpreter, policy, and harness-vs-code-path decisions. Load references only when that component is needed.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.6"
+---
+
+# AWS AgentCore
+
+## Purpose
+
+Build and operate Amazon Bedrock AgentCore agents without stuffing runtime, harness, Memory, Gateway, Identity, Observability, Browser, Code Interpreter, policy, and environment/skills details into every prompt.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- create or adapt an AgentCore project,
+- configure local development, invocation, packaging, deployment, runtime settings, harness settings, or environment/skills paths,
+- integrate AgentCore Memory, Gateway, MCP tools, Identity, Observability, Browser, or Code Interpreter,
+- review AgentCore security, least privilege, policy, tool exposure, credential handling, migration, or production readiness.
+
+## Lean operating rules
+
+- First decide whether the user has an existing agent or needs a new project. Do not scaffold over an existing codebase.
+- For new projects, prefer the npm AgentCore CLI package `@aws/agentcore` because current AWS documentation recommends it.
+- Treat the Python starter toolkit as legacy/migration-oriented unless the user is explicitly working inside an existing Python-based toolkit workflow.
+- Separate code-based agents from config-based harnesses. Do not mix their guidance casually; current AWS docs describe the harness path as preview.
+- 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 current official AWS AgentCore docs, Context7, or configured AgentCore MCP tools.
+- Treat CLI syntax as version-sensitive; verify exact commands with installed tooling before production use.
+- Treat Gateway policy, identity propagation, skill-path loading, and observability prerequisites as first-class concerns, not afterthoughts.
+- Never ask users to paste AWS credentials, client secrets, access tokens, account IDs, customer data, or private keys into chat.
+- Load only the reference needed for the component in scope.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use for end-to-end AgentCore project, local test, deployment, and output formatting.
+- [Safety checklist](references/safety-checklist.md) — use before deployment, tool exposure, credential integration, Memory/Gateway changes, or production recommendations.
+- [Official sources](references/official-sources.md) — use when grounding current AgentCore service behavior and docs URLs.
+- [Getting started](references/getting-started.md) — use for project/runtime/harness/local workflow details, then verify commands against current toolkit version.
+- [Memory integration](references/memory-integration.md) — use only for AgentCore Memory resource and agent wiring work.
+- [Gateway integration](references/gateway-integration.md) — use only for Gateway, MCP tools, and tool target integration.
+
+## Response minimum
+
+Return, at minimum:
+
+- the AgentCore component in scope,
+- evidence level and docs/tooling used,
+- safest next action,
+- command or code path to verify,
+- security and rollback caveats.

package/skills/aws/aws-agentcore/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "AWS AgentCore"
+  short_description: "Build and deploy AWS AgentCore agents with CLI-first, docs-verified workflow boundaries"
+  default_prompt: "Use $aws-agentcore to build, test, migrate, or deploy an AWS Bedrock AgentCore agent. Prefer the recommended @aws/agentcore CLI for new projects, distinguish code-based agents from preview harness workflows, and verify commands against current local CLI help before proposing automation."
+dependencies:
+  tools:
+    - type: "mcp"
+      value: "agentcore-mcp-server"
+      description: "Optional AgentCore MCP server for docs, runtime, memory, and gateway workflows when available; do not assume it exists in every environment"
+policy:
+  allow_implicit_invocation: true

package/skills/aws/aws-agentcore/metadata.json

@@ -0,0 +1,42 @@
+{
+  "id": "aws-agentcore",
+  "name": "AWS AgentCore",
+  "type": "skill",
+  "provider": "aws",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Build, test, migrate, and deploy Amazon Bedrock AgentCore code-based agents and harness workflows with runtime, policy, environment/skills, Memory, Gateway, Identity, Observability, Browser, Code Interpreter, and security guidance loaded progressively.",
+  "source_type": "adapted",
+  "official_docs": [
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/develop-agents.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-get-started-cli.md",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-get-started.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-environment.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-security.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/what-is-bedrock-agentcore.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/memory.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-configure.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-tool.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/code-interpreter.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-tools.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-create-policies.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-core-concepts.html",
+    "https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/harness-operations.html"
+  ],
+  "security_notes": "Do not hardcode credentials, tokens, client secrets, account IDs, or customer data. Prefer AgentCore Identity/Gateway for managed credentials, enforce Cedar policy where Gateway is used, verify region and preview-feature constraints, keep least-privilege roles, and require explicit approval before deployment or tool-exposure changes.",
+  "last_verified": "2026-04-29",
+  "path": "skills/aws/aws-agentcore",
+  "author": "github: Raishin",
+  "version": "0.1.6"
+}

package/skills/aws/aws-agentcore/references/gateway-integration.md

@@ -0,0 +1,137 @@
+# AgentCore Gateway Integration Guide
+
+> Version note: AgentCore tooling is evolving. Verify exact CLI syntax against the installed toolkit and current official AWS docs before production use. Do not paste secrets into commands or files.
+
+## What people get wrong
+
+The naive story is:
+
+> Gateway exposes tools, so once I create a gateway I’m done.
+
+Wrong.
+
+Official AWS docs imply at least five separate concerns:
+
+1. **inbound authentication** — who is allowed to call the gateway
+2. **outbound authentication** — how the gateway authenticates to downstream tools
+3. **target modeling** — Lambda, OpenAPI/API, Smithy/AWS-service style targets, or MCP servers
+4. **policy enforcement** — Cedar-based controls over who can call what
+5. **tool discovery** — including optional semantic search
+
+If you only think “endpoint + tool,” you are missing the real security model.
+
+## Officially grounded gateway shape
+
+AWS docs describe Gateway as:
+
+- a managed MCP-compatible gateway
+- a way to connect APIs, Lambda functions, existing services, and pre-existing MCP servers
+- a service that handles both **ingress auth** and **egress auth**
+- a policy-enforced surface where Cedar-based policies gate tool calls
+
+That is the key insight:
+
+> Gateway is not just transport. It is identity + auth + policy + discovery.
+
+## Non-negotiable design rules
+
+### 1. Split inbound auth from outbound auth
+
+Do not collapse them mentally.
+
+- **Inbound auth** answers: who may invoke the gateway?
+- **Outbound auth** answers: how does the gateway authenticate to the target system?
+
+If you confuse those, you will either overgrant downstream access or break end-user delegation.
+
+### 2. Do not hardcode raw secrets into examples unless there is no alternative
+
+Official docs emphasize managed auth paths and Gateway/Identity capabilities.
+
+So prefer:
+
+- managed credential storage
+- OAuth / JWT-based inbound flows
+- clearly scoped outbound credentials
+
+Do **not** normalize:
+
+- pasting API keys into chat
+- embedding bearer tokens in code samples casually
+- pretending headers alone are a security model
+
+### 3. Policy is first-class, not optional cleanup
+
+Official AWS policy docs show:
+
+- Gateway traffic can be mediated by a **policy engine**
+- policies use **Cedar**
+- policies control which principals can perform which actions on which resources, with conditions
+
+If the skill recommends Gateway without also asking “what is the policy boundary?”, the skill is incomplete.
+
+### 4. Semantic search is useful, but it changes governance
+
+Gateway docs mention semantic tool selection / search to reduce prompt size and scale tool discovery.
+
+That is powerful, but it also means:
+
+- tool metadata quality matters more
+- broad catalogs can cause accidental reach
+- policy boundaries matter even more
+
+Do not recommend semantic search as pure upside.
+
+### 5. Gateway target type changes the failure mode
+
+Different targets mean different risks:
+
+- **Lambda** → IAM, payload schema, side effects
+- **OpenAPI / API** → credential placement, scope creep, request shaping
+- **Smithy / AWS service models** → AWS auth/permissions and service blast radius
+- **MCP servers** → remote tool governance, protocol trust, capability sprawl
+
+One gateway pattern does not fit all four.
+
+## Minimal safe implementation flow
+
+1. Identify target type
+2. Define inbound auth path
+3. Define outbound auth path
+4. Define Cedar policy boundary
+5. Add one target only
+6. Verify tool schema and least-privilege behavior
+7. Add semantic search only if tool catalog size justifies it
+
+## High-risk assumptions to kill
+
+- “Gateway automatically makes this secure”
+- “Cognito exists, so auth is solved”
+- “If the agent can see a tool, it should be allowed to use it”
+- “Semantic search will pick the right tool”
+- “OpenAPI import means safe invocation”
+- “MCP server connected means MCP server trusted”
+
+Those are lazy assumptions.
+
+## Safe command/code verification targets
+
+Verify against current docs and local tooling before use:
+
+- `agentcore gateway ...`
+- gateway create / target create / inspect flows
+- inbound authorization requirements
+- outbound authorization setup
+- policy engine wiring and mode
+
+## When to push back
+
+Push back if the user asks for:
+
+- one gateway with broad access to everything
+- raw secret injection into headers as the default pattern
+- no policy layer
+- no per-target review
+- semantic search over sensitive tools without policy constraints
+
+That is not “faster.” It is reckless.

package/skills/aws/aws-agentcore/references/getting-started.md

@@ -0,0 +1,163 @@
+# Getting Started with AgentCore
+
+> Version note: AgentCore tooling is evolving. Verify exact CLI syntax against the installed toolkit and current official AWS docs before production use. Do not paste secrets into commands or files.
+
+## First: classify the path
+
+Do not blur these together:
+
+1. **New project** — use the recommended npm CLI `@aws/agentcore`
+2. **Existing code-based agent** — adapt/configure what exists; do not scaffold over it
+3. **Import/migration from Amazon Bedrock Agents** — use the import flow if the goal is migration, not greenfield creation
+4. **Managed harness** — a config-based path that current AWS docs describe as preview
+
+If you pick the wrong path, your advice becomes cargo cult.
+
+## Prerequisites
+
+- Node.js **20 or later**
+- npm
+- AWS credentials configured through AWS CLI, environment variables, or a named profile
+- Python **3.10 or later** for agent code
+- IAM permissions to call AgentCore APIs and assume the CDK bootstrap roles used during deployment
+
+Install the current recommended CLI for new projects:
+
+```bash
+npm install -g @aws/agentcore
+```
+
+Use the Python `bedrock-agentcore-starter-toolkit` only for legacy Python-based workflows or migration-era examples.
+
+## Current local CLI surface to assume only after verification
+
+Verified locally in this environment:
+
+- `agentcore create`
+- `agentcore dev`
+- `agentcore deploy`
+- `agentcore invoke`
+- `agentcore status`
+- `agentcore destroy`
+- `agentcore stop-session`
+- `agentcore configure`
+- `agentcore identity`
+- `agentcore gateway`
+- `agentcore memory`
+- `agentcore obs`
+- `agentcore policy`
+- `agentcore eval`
+
+Do not promise undocumented or unverified commands just because a README or blog post mentioned them.
+
+## New project path
+
+Use `agentcore create` only when the user actually wants a new project.
+
+```bash
+agentcore create --non-interactive --project-name MyAgent
+```
+
+Useful flags verified locally:
+
+- `--template basic|production`
+- `--agent-framework Strands|LangChain_LangGraph|GoogleADK|OpenAIAgents|AutoGen|CrewAI`
+- `--model-provider Bedrock|OpenAI|Anthropic|Gemini`
+- `--iac CDK|Terraform`
+- `--memory STM_ONLY|STM_AND_LTM|NO_MEMORY`
+- `--venv` / `--no-venv`
+
+Key assumption many people miss:
+
+- For non-Bedrock providers, official harness docs say you need an **API key ARN**, not just “some secret somewhere”.
+
+## Existing code-based agent path
+
+If the agent already exists, do **not** run `agentcore create` on top of it.
+
+Start by inspecting configuration:
+
+```bash
+agentcore configure --help
+```
+
+Current official docs say project configuration lives under:
+
+- `agentcore/agentcore.json`
+- `agentcore/aws-targets.json`
+
+So stop assuming old one-file layouts are the only truth.
+
+## Import / migration path
+
+If the user is migrating an existing Amazon Bedrock Agent, treat that as a separate path.
+
+Local CLI help currently shows import under `create`:
+
+```bash
+agentcore create import --help
+```
+
+Starter-toolkit docs and Context7 also reference `import-agent` style flows. That mismatch means you must verify the installed CLI before giving automation steps.
+
+## Local development loop
+
+Run the dev server:
+
+```bash
+agentcore dev
+```
+
+Useful verified flags:
+
+- `--port`
+- `--env KEY=VALUE`
+
+Then test locally:
+
+```bash
+agentcore invoke --dev '{"prompt":"Hello"}'
+```
+
+Useful verified flags:
+
+- `--agent`
+- `--session-id`
+- `--bearer-token`
+- `--local`
+- `--dev`
+- `--port`
+- `--user-id`
+- `--headers`
+
+## Harness-specific cautions
+
+Official AWS docs describe:
+
+- a **code-based agent** path
+- a **managed harness** path
+
+These are not the same thing. Current AWS docs describe the harness as preview. Do not casually recommend harness-only features as if they are universal AgentCore behavior.
+
+Also:
+
+- harness skills are **filesystem paths inside the runtime environment**
+- `--skill-path` references a path; it does **not** upload the skill for you
+- some harness docs mention `agentcore invoke --exec` shell access, but installed CLIs may not expose that surface the same way yet
+
+## Security-critical realities
+
+- SigV4 authentication does **not** give per-user identity propagation into downstream tool calls the way the OAuth bearer-token path can.
+- Gateway security is not “create gateway and done”; policy design is a separate concern.
+- Custom observability requires more than default metrics; official docs call out ADOT and CloudWatch prerequisites for richer traces.
+
+## Minimum safe workflow
+
+1. Verify CLI help locally
+2. Classify new project vs existing agent vs import vs harness
+3. Confirm region and feature support
+4. Confirm IAM/bootstrap permissions
+5. Create or adapt minimally
+6. Run `agentcore dev`
+7. Test with `agentcore invoke --dev`
+8. Only then discuss deploy, Memory, Gateway, Policy, Browser, or Code Interpreter wiring

package/skills/aws/aws-agentcore/references/memory-integration.md

@@ -0,0 +1,146 @@
+# AgentCore Memory Integration Guide
+
+> Version note: AgentCore tooling is evolving. Verify exact CLI syntax against the installed toolkit and current official AWS docs before production use. Do not paste secrets into commands or files.
+
+## What people get wrong
+
+The common bad assumption is:
+
+> “Memory” is just chat history persistence.
+
+That is incomplete.
+
+AgentCore Memory design has at least four separate concerns:
+
+1. **resource lifecycle** — create, wait for `ACTIVE`, inspect, delete
+2. **identity model** — `actor_id` and `session_id` are not interchangeable
+3. **namespace design** — what gets stored where
+4. **retention / expiry / deletion** — what survives, for how long, and how you remove it
+
+If you do not model those explicitly, you create memory bugs that look like “the AI is weird.”
+
+## Officially grounded building blocks
+
+AWS docs and Context7 show Memory supports:
+
+- short-term session memory
+- long-term strategies such as:
+  - session summarization
+  - user preference extraction
+  - semantic / fact extraction
+
+Typical namespace patterns in official examples include:
+
+- `/summaries/{actorId}/{sessionId}/`
+- `/preferences/{actorId}/`
+- `/facts/{actorId}/`
+
+That pattern is not cosmetic. It is your isolation boundary.
+
+## Non-negotiable design rules
+
+### 1. Keep `actor_id` and `session_id` stable and intentional
+
+- `actor_id` is the user or principal identity dimension
+- `session_id` is the conversational/session boundary
+
+If you generate random IDs carelessly on every call, memory will look “broken” because nothing reconnects.
+
+If you reuse the same actor/session pair across unrelated contexts, memory will look “smart” while actually leaking state.
+
+### 2. Design namespaces before writing code
+
+Do not dump everything into one namespace.
+
+Use separate namespaces for:
+
+- per-session summaries
+- per-user preferences
+- reusable semantic facts
+
+If you cannot explain why a memory belongs in a namespace, you are not ready to store it.
+
+### 3. Retention is a product decision, not just an implementation detail
+
+Official examples show `eventExpiryDuration` and long-term memory strategies.
+
+You need to decide:
+
+- which memories expire
+- which are durable
+- how deletions work
+- what counts as user-requested forgetfulness
+
+If your skill does not surface expiry/deletion, it is not production-ready.
+
+### 4. Wait for resource readiness
+
+Official examples explicitly poll until the memory resource becomes `ACTIVE`.
+
+Do not assume “create returned” means “safe to wire into the agent.”
+
+## Minimal safe implementation flow
+
+1. Create the memory resource
+2. Wait until it is `ACTIVE`
+3. Decide namespace strategy
+4. Wire `memory_id`, `actor_id`, and `session_id` into the agent intentionally
+5. Test:
+   - same actor + same session
+   - same actor + new session
+   - different actor
+6. Verify expiry/deletion behavior before broad rollout
+
+## Example patterns from official docs
+
+### Create a memory resource with strategies
+
+Official AWS examples show CLI / SDK flows with long-term strategies such as summarization, preferences, and semantic facts. Treat these as design templates, not copy-paste truth for every app.
+
+### Strands integration shape
+
+Official examples show Strands integration using:
+
+- `AgentCoreMemoryConfig`
+- `AgentCoreMemorySessionManager`
+- optional retrieval configuration for long-term namespaces
+
+That means your real integration surface is not just “turn memory on”; it is:
+
+- resource ID
+- actor/session mapping
+- retrieval behavior
+
+## Adversarial checklist
+
+Before recommending Memory, answer these:
+
+- What is the source of truth for `actor_id`?
+- What causes a new `session_id`?
+- Which namespace stores preferences vs facts vs summaries?
+- What expires automatically?
+- What is the deletion story?
+- What happens if two applications share the same memory resource?
+- What is the fallback behavior if Memory is unavailable?
+
+If you cannot answer those, your guidance is shallow.
+
+## Safe command/code verification targets
+
+Verify against current docs and local tooling before use:
+
+- `agentcore memory ...`
+- memory create/get/list/delete flows
+- integration package names and examples
+- resource status / readiness checks
+
+## When to push back
+
+Push back if the user says:
+
+- “just remember everything”
+- “reuse one memory for all users”
+- “we’ll figure out deletion later”
+- “generate IDs automatically somehow”
+
+Those are not shortcuts. They are design failures.