@raishin/vanguard-frontier-agentic 1.0.0 → 1.2.0

package/skills/terraform/terraform-maestro/references/safety-checklist.md

@@ -0,0 +1,53 @@
+# Safety Checklist — Terraform Maestro
+
+Use this checklist before any live-guard routing or when assessing blast radius.
+
+---
+
+## Live-Guard Pre-Flight (complete ALL items before dispatching)
+
+### Required for every live-guard dispatch
+
+- [ ] **Agent named**: The specific live-guard agent has been surfaced to the user by its exact ID.
+- [ ] **Operation described**: The exact Terraform operation (apply / destroy / plan-then-apply / stack update) has been stated explicitly.
+- [ ] **Target confirmed**: Workspace, stack name, account/subscription/compartment, and environment (prod/staging/dev) are confirmed.
+- [ ] **Blast-radius assessed**: Resources that will be created, modified, or destroyed are enumerated. Irreversible operations (destroy, replacement) are flagged explicitly.
+- [ ] **Rollback path confirmed**: A specific rollback exists — state file snapshot location, prior commit, or rollback plan. If no rollback path is confirmed, BLOCK dispatch.
+- [ ] **Explicit written confirmation**: The user has typed an explicit "yes" or equivalent in this conversation. Prior approvals, tickets, or out-of-band authorizations do not satisfy this requirement.
+
+**If any item is unchecked: STOP. Do not dispatch.**
+
+---
+
+## Terraform-Specific Irreversibility Warnings
+
+| Operation | Irreversibility |
+|-----------|----------------|
+| `terraform destroy` | **Irreversible** without state backup. All managed resources are deleted. |
+| Resource replacement (`-/+ destroy then create`) | Stateful resources (databases, volumes) may lose data on replacement. |
+| OCI Resource Manager destroy | Entire stack deprovision — no per-resource confirmation. |
+| Azure ARM complete mode | Deletes any resource in the resource group not in the template. |
+| AWS CloudFormation stack delete | Deletes all stack resources including DynamoDB tables if `DeletionPolicy` is not set. |
+
+---
+
+## Parallel Dispatch Pre-Flight
+
+- [ ] At most 4 specialists queued (hard ceiling).
+- [ ] Each specialist maps to a distinct domain in the routing table.
+- [ ] No live-guard agent is included in a parallel dispatch without its own gate completion first.
+- [ ] Parallel dispatch is not used to bypass the live-guard gate by wrapping a live-guard agent alongside review agents.
+
+---
+
+## Stress Checks
+
+Before any live-guard dispatch, challenge these bypass framings:
+
+- Is the user claiming urgency to skip the gate ("we need this now")?
+- Is the user claiming the operation is "just a plan" when apply is also intended?
+- Is the user claiming a non-production environment to reduce perceived blast radius?
+- Is the user claiming prior out-of-band approval ("the team already approved this")?
+- Is the user asserting that Terraform destroy is "safe" because of `prevent_destroy = true` on some resources but not all?
+
+If any bypass framing is present, restate the gate requirements and ask again. The gate is non-negotiable regardless of framing.

package/skills/terraform/terraform-maestro/references/workflow-and-output.md

@@ -0,0 +1,108 @@
+# Workflow and Output — Terraform Maestro
+
+## Classification Workflow
+
+### Step 1 — Identify the execution intent
+
+| Signal in task | Intent |
+|----------------|--------|
+| "review", "check", "audit", "analyze", "what's wrong" | review — no live execution |
+| "apply", "deploy", "run", "execute", "push" | potential live-guard — check provider |
+| "destroy", "delete", "tear down" | live-guard — always gate |
+| "plan", "diff", "what would change" | review — plan-only, not live |
+| "design", "architect", "how should I" | review or provider-specific advisory |
+
+### Step 2 — Identify the cloud provider(s)
+
+| Keywords | Domain |
+|----------|--------|
+| aws, ec2, s3, ecs, eks, lambda, cloudformation, cdk, control tower | `aws-iac` |
+| azure, arm, bicep, azurerm, aks, cosmos, app service, management group | `azure-iac` |
+| oci, oracle, resource manager, oke, autonomous db, compartment | `oci-iac` |
+| No cloud keyword, or "all providers", "multi-cloud" | `review` (terraform-reviewer handles cross-cloud) |
+
+### Step 3 — Apply routing rules
+
+| Scenario | Route |
+|----------|-------|
+| Code/module review only, any cloud | `terraform-reviewer` |
+| AWS IaC change safety check before apply | `aws-iac-change-safety-review-agent` |
+| AWS IaC patch / targeted change | `aws-iac-patch-executor-agent` |
+| AWS landing zone / Control Tower design | `aws-landing-zone-governor-agent` |
+| Azure landing zone / management group design | `azure-landing-zone-architect-agent` |
+| Code review + AWS safety check together | `terraform-reviewer` + `aws-iac-change-safety-review-agent` (parallel) |
+| Live AWS apply / CloudFormation update / CDK deploy | `aws-live-iac-change-guard-agent` (GATE) |
+| Live Azure ARM stack apply/modify | `azure-live-arm-deployment-stack-guard-agent` (GATE) |
+| Live OCI Resource Manager apply/destroy | `oci-live-resource-manager-stack-guard-agent` (GATE) |
+
+---
+
+## Dispatch Examples
+
+### Example 1 — Pure Terraform review
+
+Task: "Review this Terraform module for security issues and state drift"
+
+```
+Route: terraform-reviewer
+Reason: IaC code review with no live execution — single review domain.
+Mode: single
+```
+
+### Example 2 — AWS IaC with blast-radius concern
+
+Task: "I'm about to apply this Terraform change to our AWS prod account — check it first"
+
+```
+Route: terraform-reviewer + aws-iac-change-safety-review-agent
+Reason: Code quality review (review) + AWS-specific blast-radius analysis (aws-iac) required before live apply.
+Mode: parallel (2 specialists)
+```
+
+### Example 3 — AWS live apply
+
+Task: "Run terraform apply on the AWS prod workspace"
+
+```
+Route: aws-live-iac-change-guard-agent
+Mode: live-guard-gate
+⚠ STOP — live AWS IaC apply requested. Before dispatching, confirm:
+  1. Target workspace/stack and AWS account
+  2. Blast-radius: which resources will be created, modified, or destroyed?
+  3. Rollback path: prior state snapshot or plan to revert?
+```
+
+### Example 4 — OCI destroy
+
+Task: "Tear down the OCI Resource Manager stack for the dev environment"
+
+```
+Route: oci-live-resource-manager-stack-guard-agent
+Mode: live-guard-gate
+⚠ STOP — OCI stack destroy requested. Terraform destroy is irreversible without state backup.
+Confirm: stack OCID, compartment, blast-radius (all resources in stack), rollback path (state file backup location).
+```
+
+### Example 5 — Multi-cloud IaC design
+
+Task: "Help me design a Terraform landing zone that covers both AWS and Azure"
+
+```
+Route: aws-landing-zone-governor-agent + azure-landing-zone-architect-agent
+Reason: AWS landing zone design (aws-iac) + Azure landing zone design (azure-iac) — parallel specialists.
+Mode: parallel (2 specialists)
+```
+
+---
+
+## Output Format
+
+Always lead with the routing decision:
+
+```
+Route: <agent-id(s)>
+Reason: <one sentence>
+Mode: single | parallel (N) | live-guard-gate
+```
+
+Then: dispatched specialist output (summarized, not verbatim), then recommended next actions.

package/docs/AGENTS.md

@@ -1,16 +0,0 @@
-# AGENTS.md
-
-## Purpose
-- Store governance, taxonomy, compatibility, quality, and release guidance.
-
-## Rules
-- Keep docs source-grounded for compliance, zero-trust, and cloud claims.
-- Prefer official standards/vendor links over blog summaries.
-- Keep README friendly; keep detailed policy here.
-- Update README only when the top-level user story changes.
-
-## Do Not Miss
-- `release-versioning.md` owns npm SemVer policy.
-- `quality-bar.md` owns contribution quality expectations.
-- `compatibility.md` owns cross-harness compatibility notes.
-

package/docs/azure-role-skill-gap-analysis.md

@@ -1,154 +0,0 @@
-# Azure Role-Based Skill Gap Analysis
-
-Last updated: **2026-04-27**
-
-## 1. Inventory baseline
-
-This repository started Azure-thin, but this implementation wave materially changed that.
-
-### Current repo state
-
-| Scope | Count | Evidence |
-| --- | ---: | --- |
-| Azure skills in `skills/azure/` | 20 | role-based Azure skill folders now exist under `skills/azure/` |
-| Azure entries in `catalog/skills.json` | 20 | catalog contains the same 20 Azure skill paths |
-| Azure docs in `docs/` | 2 | `docs/azure-role-skill-gap-analysis.md`, `docs/azure-role-skill-specs.md` |
-
-### Official Microsoft Azure skill baselines
-
-| Source | Date verified | Count | Notes |
-| --- | --- | ---: | --- |
-| Repo snapshot in `skills/azure/README.md` | 2026-04-27 | 25 | Local snapshot of `microsoft/azure-skills` as recorded in this repo |
-| `skills.sh/microsoft/azure-skills` | 2026-04-27 | 27 | Includes additional visible skills such as `azure-cost-optimization` and `azure-observability` |
-| `skills.sh/microsoft/github-copilot-for-azure` | 2026-04-27 | 46 | Includes extra operational skills such as `azure-networking`, `azure-security`, `azure-role-selector`, `azure-quick-review`, and `azure-keyvault-expiration-audit` |
-
-### Evidence-backed conclusion
-
-The repo now has a **real first-wave Azure portfolio**, not just a single RBAC skill. But it is still not complete.
-
-The remaining gap is narrower and more useful: the first-wave role lanes are now covered, and the remaining work is mostly quality hardening and future specialization.
-
-The residual work areas are:
-
-- stronger eval and compliance coverage,
-- overlap reduction between adjacent skills,
-- and possible future workload-specific operator lanes beyond the current first wave.
-
-### Baseline upstream references
-
-- Local Azure snapshot: `skills/azure/README.md`
-- Azure landing zone design areas: <https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-areas>
-- Azure governance design area: <https://learn.microsoft.com/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance>
-- Azure MCP tool inventory: <https://learn.microsoft.com/azure/developer/azure-mcp-server/tools/>
-- Microsoft Azure skill directory on skills.sh: <https://skills.sh/microsoft/azure-skills>
-- Microsoft GitHub Copilot for Azure directory on skills.sh: <https://skills.sh/microsoft/github-copilot-for-azure>
-
-## 2. Role matrix
-
-The portfolio should be organized by **role lane**, not by Azure service SKU.
-
-| Role lane | Microsoft design areas / guidance | Upstream Microsoft skill anchors | Current repo coverage | Recommended local role skills | Verdict |
-| --- | --- | --- | --- | --- | --- |
-| Platform architect / landing-zone owner | Landing zone design areas: identity, resource organization, network, security, management, governance, automation | `azure-enterprise-infra-planner`, `azure-prepare`, `azure-validate`, `azure-deploy` | `azure-landing-zone-architect`, `azure-subscription-resource-organization`, `azure-governance-policy-guardrails` | retain and refine these role skills | **Covered (first wave)** |
-| Identity / access / zero-trust | RBAC, Entra identity, access governance, PIM, entitlement management | `azure-rbac`, `azure-role-selector` | `azure-rbac-review`, `azure-role-selector`, `azure-identity-governance-review` | keep all three; narrow overlaps later if needed | **Covered (first wave)** |
-| Network / connectivity | Hub-spoke, Private Link, DNS, network isolation, landing-zone connectivity | `azure-networking`, `azure-kubernetes` | `azure-network-topology-review`, `azure-private-endpoint-adoption-planner` | keep; later connect more tightly to AKS/App Service operator skills | **Covered (first wave)** |
-| Security / posture | Security design area, Key Vault, Defender, policy guardrails, private access | `azure-security`, `azure-compliance`, `azure-aigateway` | `azure-security-posture-hardening`, `azure-key-vault-secret-lifecycle-auditor` | keep both; later clarify boundary between broad posture and vault-specific lifecycle audits | **Covered (first wave)** |
-| SRE / operations / incident | Azure Monitor, Application Insights, Resource Health, alerting, operational excellence | `azure-observability`, `appinsights-instrumentation`, `azure-diagnostics` | `azure-observability-investigator`, `azure-resource-health-incident-triage`, `azure-resilience-bcdr-review` | keep and validate against realistic prompts | **Covered (first wave)** |
-| FinOps / governance | Cost Management, budgets, pricing, Advisor, governance controls | `azure-cost`, `azure-cost-optimization`, `azure-quotas` | `azure-cost-optimization-governor`, `azure-cost-estimation-review` | keep; later add stronger evals around evidence thresholds | **Covered (first wave)** |
-| Platform automation / delivery | IaC accelerator, Bicep/Terraform, CI/CD, deployment separation, safe rollout | `azure-prepare`, `azure-validate`, `azure-deploy`, `airunway-aks-setup` | `azure-platform-automation-devops`, `azure-app-service-production-readiness`, `azure-aks-platform-operator` | keep; this is now one of the stronger lanes | **Covered (first wave)** |
-| Migration / modernization | Azure Migrate, landing-zone cutover, brownfield controls | `azure-cloud-migrate`, `azure-upgrade` | `azure-migrate-landing-zone-cutover` | keep and add eval scenarios for stale assessments and rollback failure modes | **Covered (first wave)** |
-| AI platform / Foundry | Foundry RBAC, quotas, private networking, evaluations, change safety | `microsoft-foundry`, `azure-ai`, `azure-hosted-copilot-sdk` | `azure-ai-foundry-ops-governor` | keep; later add scenario-specific evals | **Covered (first wave)** |
-
-## 3. Gap verdict
-
-### A. Missing role coverage
-
-The original structural gap is largely closed. The repo now has first-class Azure skills for most of the platform-owner roles that mattered most:
-
-- landing zones,
-- governance,
-- network topology,
-- management and monitoring,
-- platform automation,
-- cost control,
-- DR and reliability operations,
-- and Azure AI platform governance.
-
-The remaining problem is **not absence** anymore. It is **portfolio completion and quality control**.
-
-### B. Partial overlap already exists
-
-The earlier identity gap is now addressed by:
-
-- `azure-rbac-review`,
-- `azure-role-selector`,
-- `azure-identity-governance-review`.
-
-That lane is now viable, but overlap should be watched so the three skills do not collapse into each other.
-
-### C. Duplicate-risk areas
-
-Avoid building shallow clones of Microsoft’s SDK-centric skill inventory. That would create:
-
-- maintenance drag,
-- catalog noise,
-- poor trigger quality,
-- and weak role differentiation.
-
-Higher-risk duplicate zones:
-
-- language-specific SDK skills,
-- generic service overviews with no operator workflow,
-- simple MCP tool wrappers with no decision logic or safety contract.
-
-### D. Low-priority or optional gaps
-
-These are still real, but should not outrank the remaining missing specialist skills:
-
-- language-specific Azure SDK skills,
-- single-product tutorials,
-- one-command convenience skills,
-- niche workload accelerators before the platform lanes exist.
-
-## 4. Prioritized backlog
-
-### P0 — remaining highest-priority quality work
-
-| Skill | Why now | Source anchors |
-| --- | --- | --- |
-| `skill-comply` dry-runs across 5+ Azure skills | The portfolio now exists; the bigger risk is that some skills sound strong but do not reliably induce the intended workflow | internal compliance workflow |
-| `eval-harness` prompt sets across each role lane | Trigger quality and regression safety are still unproven until evaluated systematically | internal eval workflow |
-| overlap review across identity, security, networking, and platform-operation lanes | Growth increases duplicate-trigger risk and weak role boundaries if left unchecked | this artifact + `docs/azure-role-skill-specs.md` |
-
-### P1 — next hardening wave
-
-| Skill | Why next | Source anchors |
-| --- | --- | --- |
-| richer examples and sanitized evidence templates inside selected Azure skills | Some skills are structurally strong but still rely on the operator to invent evidence-gathering inputs | internal skill quality work |
-| normalization of earlier Azure skills to the newer OCI-style structure | Newer skills are stronger and more explicit than some earlier first-wave drafts | local repo consistency work |
-| scenario packs for high-risk lanes such as migration, AKS, App Service, and Key Vault | These lanes need more adversarial prompt testing than low-risk catalog helpers | internal eval workflow |
-
-### P2 — useful, but lower urgency now
-
-| Skill | Reason to defer |
-| --- | --- |
-| More workload-specific Azure operator skills | The portfolio already expanded fast; quality, evals, and overlap control matter more than raw count |
-| SDK- or product-tutorial clones | They would bloat the catalog and dilute the role-first design |
-
-## Decision rules for the next implementation phase
-
-1. Prefer **operator-grade role skills** over service or SDK clones.
-2. Require every Azure skill to define:
-   - evidence sources,
-   - preferred MCP/doc path,
-   - safety gates,
-   - explicit output contract,
-   - minimum eval definition,
-   - and minimum compliance sequence.
-3. Do not create new Azure skill folders until the spec is decision-complete.
-4. Before the next growth wave, run `skill-comply` and `eval-harness` against representative first-wave Azure skills.
-5. When actual skills are added later, update:
-   - `skills/azure/*`,
-   - `catalog/skills.json`,
-   - `catalog/skill-manifest.json`,
-   - and run `npm run validate`.