@raishin/vanguard-frontier-agentic 1.2.0 → 1.4.0

package/skills/argocd/argo-rollouts-progressive-delivery-review/references/workflow-and-output.md

@@ -0,0 +1,248 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify scope and collect raw evidence
+
+1. Confirm the review target: a specific Rollout resource, an AnalysisTemplate, a traffic provider configuration, or a PDB compatibility question.
+2. List all Rollouts and their strategies:
+   ```bash
+   kubectl get rollout -A -o yaml
+   ```
+   For each Rollout, note the strategy type (`canary` or `blueGreen`) and whether `spec.strategy.canary.steps` is non-empty.
+3. List all AnalysisTemplates:
+   ```bash
+   kubectl get analysistemplate -A -o yaml
+   kubectl get clusteranalysistemplate -o yaml 2>/dev/null
+   ```
+4. Check current Rollout status and any active AnalysisRuns:
+   ```bash
+   kubectl argo rollouts status <rollout-name> -n <namespace>
+   kubectl get analysisrun -A -o yaml
+   ```
+
+### Step 2 — Audit Rollout strategy and steps
+
+A Rollout without steps behaves like a standard Deployment — no progressive traffic shifting occurs.
+
+1. Check whether `spec.strategy.canary.steps` is non-empty and includes analysis gates:
+   ```yaml
+   # CORRECT: canary with weight steps and analysis gate
+   strategy:
+     canary:
+       canaryService: my-app-canary
+       stableService: my-app-stable
+       trafficRouting:
+         nginx:
+           stableIngress: my-app-ingress
+       steps:
+         - setWeight: 10
+         - pause: {duration: 5m}
+         - analysis:
+             templates:
+               - templateName: error-rate-check
+         - setWeight: 50
+         - pause: {duration: 10m}
+         - analysis:
+             templates:
+               - templateName: error-rate-check
+
+   # RISKY: no steps — immediately shifts all traffic
+   strategy:
+     canary:
+       maxSurge: "100%"
+       maxUnavailable: 0
+   ```
+2. Flag as **HIGH** if `maxSurge: 100%` is set with no steps — 100% of replicas are replaced before any analysis runs.
+3. For blue-green Rollouts, check whether `autoPromotionEnabled` is set:
+   ```yaml
+   # Requires manual promotion
+   strategy:
+     blueGreen:
+       activeService: my-app-active
+       previewService: my-app-preview
+       autoPromotionEnabled: false
+   ```
+   `autoPromotionEnabled: true` in production without a `prePromotionAnalysis` is a high finding.
+
+### Step 3 — Audit AnalysisTemplate success and failure conditions
+
+This is the most critical control — conditions that always evaluate true defeat automated rollback entirely.
+
+1. For each AnalysisTemplate metric, inspect:
+   - `spec.metrics[].successCondition` — when is the metric considered passing?
+   - `spec.metrics[].failureCondition` — when should it fail?
+   - `spec.metrics[].failureLimit` — how many failures are tolerated?
+   - `spec.metrics[].provider` — Prometheus, Datadog, web, job, etc.
+2. Example of a correctly configured error-rate AnalysisTemplate:
+   ```yaml
+   apiVersion: argoproj.io/v1alpha1
+   kind: AnalysisTemplate
+   metadata:
+     name: error-rate-check
+   spec:
+     metrics:
+       - name: error-rate
+         interval: 2m
+         count: 5
+         failureLimit: 0
+         provider:
+           prometheus:
+             address: http://prometheus.monitoring.svc.cluster.local:9090
+             query: |
+               sum(rate(http_requests_total{status=~"5..",deployment="{{args.deployment-name}}"}[2m]))
+               /
+               sum(rate(http_requests_total{deployment="{{args.deployment-name}}"}[2m]))
+         successCondition: result[0] < 0.01
+         failureCondition: result[0] >= 0.05
+   ```
+3. Flag as **CRITICAL** if `successCondition` evaluates true for all possible metric values:
+   - `result >= 0` (always true for any non-negative counter)
+   - `true` (literal boolean true)
+   - `result != "error"` (only fails on error, never on bad metric values)
+4. Flag as **HIGH** if `failureCondition` is absent — the metric can only succeed, never explicitly fail.
+5. Flag as **MEDIUM** if `failureLimit` is set to 100 or greater on an error-rate metric — 100 failures will be tolerated before marking Degraded.
+6. Flag as **HIGH** if the Prometheus query template references `{{args.deployment-name}}` but no `args` are passed in the Rollout's analysis step — the query evaluates against all deployments, returning misleading results.
+
+### Step 4 — Audit canaryService and stableService isolation
+
+Without separate Services, canary pods receive the same traffic distribution as stable — canary traffic isolation does not exist.
+
+1. Check whether both `canaryService` and `stableService` are specified:
+   ```bash
+   kubectl get rollout <name> -o jsonpath='{.spec.strategy.canary.canaryService},{.spec.strategy.canary.stableService}'
+   ```
+2. Verify the Services exist and have the correct selector labels:
+   ```bash
+   kubectl get svc <canaryService> <stableService> -o yaml | grep -A 5 "selector"
+   ```
+   Argo Rollouts manages the `rollouts-pod-template-hash` selector on these Services automatically — verify neither has a hardcoded hash that bypasses Rollouts management.
+3. Flag as **HIGH** if `canaryService` is absent — all traffic hits the stable Service regardless of setWeight steps.
+
+### Step 5 — Audit traffic provider alignment
+
+A misconfigured traffic provider silently ignores all weight changes.
+
+1. Check the traffic routing provider specified in the Rollout:
+   ```bash
+   kubectl get rollout <name> -o jsonpath='{.spec.strategy.canary.trafficRouting}'
+   ```
+2. Verify the specified provider is actually installed:
+   ```bash
+   # For Istio
+   kubectl get virtualservice -A | head -5
+   kubectl get destinationrule -A | head -5
+
+   # For Nginx
+   kubectl get ingressclass | grep nginx
+
+   # For AWS ALB
+   kubectl get ingressclass | grep alb
+
+   # For Traefik
+   kubectl get traefikservice -A 2>/dev/null | head -5
+   ```
+3. Common mismatches:
+   - Rollout specifies `trafficRouting.nginx` but the cluster uses AWS ALB Ingress Controller.
+   - Rollout specifies `trafficRouting.istio` but Istio is not installed or not managing the service's namespace.
+4. Flag as **HIGH** if the provider specified does not match installed ingress — weight steps are silently no-ops and all traffic remains on stable.
+
+### Step 6 — Audit PDB compatibility with Rollout surge settings
+
+A PDB that prevents pod eviction can deadlock a canary rollout that requires replacing existing pods.
+
+1. Check PDBs in the same namespace as the Rollout:
+   ```bash
+   kubectl get pdb -n <namespace> -o yaml
+   ```
+2. Check Rollout maxUnavailable and maxSurge:
+   ```bash
+   kubectl get rollout <name> -o jsonpath='{.spec.strategy.canary.maxUnavailable},{.spec.strategy.canary.maxSurge}'
+   ```
+3. Identify deadlock conditions:
+   - `maxUnavailable: 0` in the Rollout means old pods cannot be removed until new pods are Ready.
+   - A PDB with `minAvailable: 100%` (or `maxUnavailable: 0`) means no pod can be evicted.
+   - Combined: new pods can never start because the cluster has no capacity, and old pods cannot be removed due to PDB — **deadlock**.
+4. Example of a safe PDB configuration alongside a canary Rollout:
+   ```yaml
+   # PDB: allow 1 unavailable pod during updates
+   apiVersion: policy/v1
+   kind: PodDisruptionBudget
+   metadata:
+     name: my-app-pdb
+   spec:
+     maxUnavailable: 1
+     selector:
+       matchLabels:
+         app: my-app
+
+   # Rollout: maxSurge allows creating new pods above desired count
+   strategy:
+     canary:
+       maxSurge: "25%"
+       maxUnavailable: 0
+   ```
+5. Flag as **HIGH** if `maxUnavailable: 0` in the Rollout and `maxUnavailable: 0` (or `minAvailable: 100%`) in a PDB matching the same pods.
+
+### Step 7 — Audit rollback posture and history
+
+1. Verify `revisionHistoryLimit` is set to retain enough history for a safe rollback:
+   ```bash
+   kubectl get rollout <name> -o jsonpath='{.spec.revisionHistoryLimit}'
+   ```
+   The default is 10. A limit of 1 means only one previous revision is retained — if the rollback target was already overwritten, rollback fails.
+2. Check `abortScaleDownDelaySeconds` for the canary:
+   ```bash
+   kubectl get rollout <name> -o jsonpath='{.spec.strategy.canary.abortScaleDownDelaySeconds}'
+   ```
+   Default is 30 seconds. Setting this to 0 means canary pods are immediately deleted on abort — useful for fast rollback but removes the ability to inspect the canary pods post-abort.
+3. To manually trigger a rollback:
+   ```bash
+   kubectl argo rollouts abort <rollout-name> -n <namespace>
+   kubectl argo rollouts undo <rollout-name> -n <namespace>
+   ```
+4. Verify automated abort is wired to the AnalysisRun:
+   ```bash
+   kubectl get analysisrun -A -o yaml | grep -A 5 "phase"
+   ```
+   An AnalysisRun in `Failed` phase should trigger the Rollout to transition to `Degraded` and initiate rollback automatically.
+
+### Step 8 — Verify Argo Rollouts controller health
+
+A degraded or missing Argo Rollouts controller means all Rollout objects are frozen — no progression, no rollback, no weight changes.
+
+1. Check controller health:
+   ```bash
+   kubectl get pods -n argo-rollouts
+   kubectl describe deployment argo-rollouts -n argo-rollouts
+   ```
+2. Check for recent controller errors:
+   ```bash
+   kubectl logs -n argo-rollouts -l app.kubernetes.io/name=argo-rollouts --tail=50 | grep -i error
+   ```
+3. Flag as **HIGH** if the argo-rollouts controller has unavailable replicas and any Rollout is mid-canary — the canary will not progress or roll back automatically until the controller recovers.
+
+## Output
+
+Return:
+
+- **target**: Rollout name, namespace, and strategy type, with evidence source,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **strategy correctness**: steps present/absent, analysis gates present/absent, blue-green autoPromotion setting,
+- **AnalysisTemplate audit**: successCondition and failureCondition correctness, failureLimit values, Prometheus query argument wiring,
+- **service isolation**: canaryService and stableService presence, selector management,
+- **traffic provider alignment**: specified provider vs installed ingress controller,
+- **PDB compatibility**: deadlock risk with Rollout maxSurge/maxUnavailable settings,
+- **rollback posture**: revisionHistoryLimit, abortScaleDownDelaySeconds, automated abort wiring,
+- **controller health**: argo-rollouts controller pod state,
+- **risk findings** (with severity: critical / high / medium / low),
+- **safest next actions** with sample YAML,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend bypassing AnalysisTemplate gates to force a canary promotion — fix the underlying metric or analysis query instead.
+- Never recommend setting `successCondition: true` or equivalent always-passing conditions to unblock a stuck rollout.
+- A Rollout with `autoPromotionEnabled: true` and no `prePromotionAnalysis` in production is equivalent to a standard Deployment — progressive delivery provides no safety gate.
+- Always verify the AnalysisTemplate Prometheus query actually targets the canary deployment specifically, not the entire service or namespace — a query that averages stable and canary traffic can mask canary errors.
+- Do not recommend increasing `failureLimit` as a fix for a legitimate analysis failure — investigate the root cause first.

package/skills/argocd/argocd-gitops-review/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: argocd-gitops-review
+description: Use this skill for Argo CD GitOps review across Application, AppProject, ApplicationSet, sync windows, RBAC, sync impersonation, and Argo CD Agent multi-cluster topologies. Trigger when the user asks whether an Argo CD configuration is safe for production, whether automated sync should be enabled, whether prune+selfHeal is appropriate, whether AppProject scope is too wide, or how to enforce least-privilege sync identity.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-05-05"
+  category: delivery
+---
+
+# Argo CD GitOps Review
+
+## Purpose
+
+Review Argo CD `Application`, `AppProject`, `ApplicationSet`, sync windows, RBAC, and the central `argocd-cm` / `argocd-rbac-cm` configuration against blast radius, drift handling, and least-privilege sync identity. Argo CD's controller defaults to cluster-admin permissions on every destination cluster — the security posture lives in `AppProject` boundaries, sync impersonation, and explicit RBAC, not in the controller defaults.
+
+## Lean operating rules
+
+- Prefer live cluster evidence (`kubectl get applications,appprojects,applicationsets -n argocd -o yaml` plus the `argocd-cm` and `argocd-rbac-cm` ConfigMaps) when the active client exposes it; otherwise fall back to official Argo CD documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If sync history, current health, or RBAC binding state was not queried, say so.
+- Treat `application.sync.impersonation.enabled: false` (default) in production as a critical finding — every sync runs as the controller's cluster-admin ServiceAccount.
+- Treat `AppProject` with `sourceRepos: ['*']` and `destinations: ['*']` as a wide-blast-radius finding — any commit in any repo can deploy anywhere.
+- Treat `automated.prune: true` + `automated.selfHeal: true` on production Applications as critical without an explicit allowlist of authorized Git refs and a tested rollback runbook — Git divergence becomes irreversible deletion.
+- Challenge `ApplicationSet` generators that include unbounded clusters (`clusters: {}`) or label selectors with no exclusion — one mis-labeled cluster joins the rollout.
+- Challenge `syncOptions: ['Replace=true']` and `syncOptions: ['ServerSideApply=false']` on stateful resources — Replace deletes-then-creates, breaking PVC bindings.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+
+## References
+
+Load these only when needed:
+
+- [Evidence path and tooling](references/mcp-and-evidence.md) — use when choosing live cluster evidence, confirming Argo CD install state and version, or switching to documentation mode.
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, applying stress checks on Application / AppProject / ApplicationSet, or formatting the final answer.
+- [Official sources](references/official-sources.md) — use when you need the detailed Argo CD documentation list, RBAC syntax, and grounded insights from the project.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target (`Application`, `AppProject`, `ApplicationSet`, or `argocd-rbac-cm` policy) and evidence level,
+- the sync identity (controller default cluster-admin, impersonated ServiceAccount, or `destinationServiceAccount`),
+- the blast radius assessment (`sourceRepos`, `destinations`, `clusterResourceWhitelist`, `namespaceResourceBlacklist`),
+- the drift handling posture (`automated`, `prune`, `selfHeal`, `syncWindows`),
+- the safest next actions and rollback plan,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/argocd/argocd-gitops-review/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "argocd-gitops-review",
+  "name": "Argo CD GitOps Review",
+  "type": "skill",
+  "provider": "argocd",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Argo CD Application, AppProject, ApplicationSet, sync windows, RBAC, sync impersonation, and Argo CD Agent multi-cluster topologies for blast radius, drift handling, and least-privilege sync identity.",
+  "source_type": "original",
+  "official_docs": [
+    "https://argo-cd.readthedocs.io/en/stable/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/",
+    "https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/",
+    "https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/",
+    "https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-cm-yaml/"
+  ],
+  "security_notes": "Sync impersonation is disabled by default — controller runs as cluster-admin on every destination. AppProject sourceRepos and destinations wildcards remove blast-radius bounds. Automated prune+selfHeal on Git divergence is irreversible. ApplicationSet unbounded cluster generators auto-onboard misconfigured clusters.",
+  "last_verified": "2026-05-01",
+  "path": "skills/argocd/argocd-gitops-review",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/argocd/argocd-gitops-review/references/mcp-and-evidence.md

@@ -0,0 +1,53 @@
+# Evidence Path and Tooling
+
+## Evidence path
+
+1. Prefer live cluster evidence when a Kubernetes MCP server, `kubectl`, or the `argocd` CLI is available against the Argo CD control-plane cluster.
+2. Fall back to official Argo CD documentation (argo-cd.readthedocs.io) and the upstream argo-cd GitHub repository when live inspection is unavailable.
+3. Ask only for sanitized `Application` / `AppProject` / `ApplicationSet` YAML, the redacted `argocd-cm` and `argocd-rbac-cm` ConfigMaps, and `argocd app history` output when current-state proof matters.
+4. Label conclusions as `live evidence`, `documentation-based`, `sanitized user evidence`, or `inference`.
+
+## Useful live-evidence commands
+
+```shell
+# All Applications, AppProjects, and ApplicationSets in the argocd namespace
+kubectl -n argocd get applications,appprojects,applicationsets -o yaml
+
+# Detailed Application status (sync, health, lastSyncRevision)
+kubectl -n argocd get application <app-name> -o yaml
+argocd app get <app-name>
+argocd app history <app-name>
+
+# Argo CD configuration (the global config knobs)
+kubectl -n argocd get configmap argocd-cm -o yaml
+kubectl -n argocd get configmap argocd-rbac-cm -o yaml
+kubectl -n argocd get configmap argocd-cmd-params-cm -o yaml
+
+# RBAC effective policy
+argocd account list
+argocd account get-user-info <user>
+
+# Cluster registrations (every destination cluster has its own Secret)
+kubectl -n argocd get secrets -l argocd.argoproj.io/secret-type=cluster -o yaml
+
+# Sync windows on an AppProject
+kubectl -n argocd get appproject <project> -o jsonpath='{.spec.syncWindows}'
+
+# Argo CD Agent (hub-and-spoke deployments)
+kubectl -n argocd get agents -o yaml
+```
+
+## Argo CD install state to confirm before review
+
+- Argo CD version (`kubectl -n argocd get deploy argocd-server -o jsonpath='{.spec.template.spec.containers[0].image}'`) — sync impersonation, RBAC granular actions, and ApplicationSet RollingSync arrived in different versions.
+- `application.sync.impersonation.enabled` in `argocd-cm` — `false` (default) means every sync runs as the controller's ServiceAccount on every destination.
+- `application.sync.requireOverridePrivilegeForRevisionSync` in `argocd-cm` — `true` requires explicit override permission for ad-hoc revision syncs.
+- `webhook.maxPayloadSizeMB` in `argocd-cm` — large Helm value files may exceed the default.
+- Whether Argo CD Agent (argocd-agent) is in use for hub-and-spoke multi-cluster — different security model.
+- Whether Argo CD Autopilot manages Argo CD itself via GitOps — change review must include the Autopilot repo.
+
+## Sanitization rules
+
+- Never request kubeconfig contents, cluster Secret contents, repository SSH keys, or webhook signing secrets in chat.
+- Replace identifiable cluster URLs and namespaces with placeholders unless the user provides them and confirms it is safe to use them.
+- Do not print Git repository tokens, OCI registry tokens, or Helm OCI credentials.

package/skills/argocd/argocd-gitops-review/references/official-sources.md

@@ -0,0 +1,32 @@
+# Official Sources
+
+Load these only when needed:
+
+- [Argo CD documentation home](https://argo-cd.readthedocs.io/en/stable/) — use as the entry point for any Argo CD authoring, install, or operator-side question.
+- [Declarative setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/) — use for `Application`, `AppProject`, cluster Secret, repository Secret, and ConfigMap structure.
+- [argocd-cm reference](https://argo-cd.readthedocs.io/en/stable/operator-manual/argocd-cm-yaml/) — use for global controller knobs including `application.sync.impersonation.enabled`, `application.sync.requireOverridePrivilegeForRevisionSync`, and `webhook.maxPayloadSizeMB`.
+- [Auto-sync](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/) — use for `automated`, `prune`, `selfHeal` semantics and operational guidance.
+- [Sync Options](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/) — use for `Replace`, `Force`, `ServerSideApply`, `PruneLast`, `CreateNamespace`, `Validate=false`, `RespectIgnoreDifferences`.
+- [Sync Windows](https://argo-cd.readthedocs.io/en/stable/user-guide/sync_windows/) — use for deploy-freeze enforcement at the AppProject level.
+- [ApplicationSet Generators](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/) — use for `list`, `cluster`, `git`, `matrix`, `merge`, `pullRequest`, `scmProvider` generator semantics.
+- [ApplicationSet Progressive Syncs (RollingSync)](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/) — use for staged ApplicationSet rollouts.
+- [Argo CD RBAC](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/) — use for `policy.csv` syntax, default role, group bindings, and granular action permissions.
+- [Sync impersonation proposal](https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/) — use for the AppProject `destinationServiceAccounts` field and the least-privilege sync identity model.
+- [Argo CD upgrading guide](https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/) — use when version-specific RBAC actions or API fields matter.
+- [Argo CD User Management](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/) — use for SSO via OIDC / SAML / Dex and group claims.
+- [Argo CD Webhook](https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/) — use for repository webhook setup and signature verification.
+- [Argo CD Agent](https://github.com/argoproj-labs/argocd-agent) — use for hub-and-spoke multi-cluster topologies replacing direct cluster registrations.
+- [Argo CD Autopilot](https://github.com/argoproj-labs/argocd-autopilot) — use when Argo CD itself is managed via GitOps.
+
+## Grounded insights worth carrying into the skill
+
+- The Argo CD controller defaults to running as cluster-admin on every destination cluster. The `application.sync.impersonation.enabled` flag in `argocd-cm` is the switch that activates per-Application ServiceAccount impersonation via `destinationServiceAccounts` on the AppProject.
+- `AppProject` boundaries are the only enforced isolation between teams sharing one Argo CD instance. Wildcards in `sourceRepos`, `destinations`, `clusterResourceWhitelist`, or empty `namespaceResourceBlacklist` collapse the boundary.
+- `automated.selfHeal: true` combined with `automated.prune: true` means a Git revert (or Git outage that exposes a stale ref) deletes prod resources. There is no built-in confirmation step.
+- ApplicationSet's `cluster` generator with an empty selector auto-onboards every newly registered cluster. This is the most-cited blast-radius mode in Argo CD post-incident reviews.
+- ApplicationSet RollingSync intentionally forces auto-sync **disabled** on generated Applications (the controller logs warnings if any have auto-sync enabled). RollingSync drives sync via OutOfSync detection, not auto-sync.
+- The `Replace=true` sync option is destructive on `StatefulSet`, `Service`, `PersistentVolumeClaim`, and any resource with finalizers. Argo CD's default three-way merge (or server-side apply on newer versions) is safer.
+- Argo CD RBAC granular actions (e.g., `action/apps/Deployment/restart`, `action/argoproj.io/Rollout/abort`) shipped in v2.8+. Older policies that don't list these still work but won't grant the action — operators may discover gaps after upgrade.
+- The `requireOverridePrivilegeForRevisionSync: true` flag in `argocd-cm` requires explicit `override` permission to sync to a non-tracked revision (e.g., a branch instead of HEAD of the configured target). This blocks easy ad-hoc syncs that bypass Git review.
+- Argo CD Autopilot's bootstrap repo manages Argo CD itself — changes to that repo can disable RBAC, weaken AppProject scopes, or rotate the admin password. Treat the Autopilot repo as a tier-0 control surface.
+- The Argo CD Agent (argocd-agent) introduces a hub-and-spoke topology where the central Argo CD installation does not hold cluster credentials for spoke clusters; agents connect outbound. Different threat model from the classic direct-cluster registration.

package/skills/argocd/argocd-gitops-review/references/workflow-and-output.md

@@ -0,0 +1,120 @@
+# Workflow and Output Contract
+
+## Workflow
+
+### Step 1 — Identify the target and the surrounding AppProject
+
+1. Confirm the kind: `Application`, `AppProject`, `ApplicationSet`, or a global ConfigMap (`argocd-cm`, `argocd-rbac-cm`).
+2. For an `Application`, locate the `spec.project` reference and review the `AppProject` first — the AppProject defines the boundary the Application operates within.
+3. For an `AppProject`, list every `Application` referencing it (`kubectl -n argocd get applications -o jsonpath='{range .items[?(@.spec.project=="<project>")]}{.metadata.name}{"\n"}{end}'`).
+4. For an `ApplicationSet`, identify the generator type (`list`, `cluster`, `git`, `matrix`, `merge`, `pullRequest`, `scmProvider`) and the `spec.template`.
+
+### Step 2 — Audit the AppProject blast radius
+
+The AppProject defines four boundary surfaces. Each is a potential blast-radius finding:
+
+1. **`sourceRepos`** — the Git or Helm repos this project may pull from. `['*']` means any repo. Recommended: explicit list.
+2. **`destinations`** — the (cluster, namespace) tuples this project may deploy to. `[{server: '*', namespace: '*'}]` means anywhere. Recommended: explicit cluster URLs and namespace allowlist (or `namespace: 'team-*'` for multi-tenant patterns).
+3. **`clusterResourceWhitelist`** — cluster-scoped resources this project may manage. Empty or `['*/*']` means any cluster-scoped resource (including ClusterRoleBindings, Namespaces). Recommended: empty for application projects; explicit list for platform projects.
+4. **`namespaceResourceBlacklist`** — namespace-scoped resources this project may NOT manage. Recommended: include `[{group: 'rbac.authorization.k8s.io', kind: '*'}]` for application projects to prevent applications from binding their own RBAC.
+
+Reference: [AppProject in declarative setup](https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/).
+
+### Step 3 — Audit sync identity (the most under-reviewed control)
+
+Three sync identity modes exist; pick one and verify:
+
+1. **Controller default** — Argo CD controller's ServiceAccount on the destination cluster. Default is broad (cluster-admin in many installs). **Critical finding** if production Applications use this without an audit trail of what the controller can do.
+2. **Sync impersonation** (preferred for least privilege) — `application.sync.impersonation.enabled: true` in `argocd-cm` plus `destinationServiceAccounts` on the AppProject. Each Application syncs as a per-namespace ServiceAccount with scoped RBAC. See the [sync impersonation proposal](https://argo-cd.readthedocs.io/en/stable/proposals/decouple-application-sync-user-using-impersonation/).
+3. **Cluster credentials** (legacy multi-cluster) — Argo CD has its own bearer token for each registered cluster. Rotate regularly.
+
+Stress-tests:
+
+- An Application with `spec.destination.namespace: kube-system` plus controller-default identity = sync runs as cluster-admin in kube-system.
+- An AppProject with `destinationServiceAccounts` listing `defaultServiceAccount: 'default'` = effectively no impersonation; the default SA is always present.
+
+### Step 4 — Audit the drift-handling posture
+
+`spec.syncPolicy.automated` controls whether Argo CD reconciles drift. Three flags govern blast radius:
+
+1. **`automated: {}` (auto-sync)** — every Git commit triggers a sync. Production-safe only with `syncWindows` and a tested CI gate.
+2. **`automated.prune: true`** — resources removed from Git are deleted from the cluster. **Critical** without a rollback runbook: a misconfigured commit deletes prod resources.
+3. **`automated.selfHeal: true`** — manual cluster changes are reverted on the next sync. Combined with `prune`, divergence becomes a hard reset to Git state.
+
+Stress-tests:
+
+- `automated.prune: true` on a `StatefulSet` Application = deletion cascades to PVCs (if `persistentVolumeClaimRetentionPolicy.whenDeleted: Delete`). Data loss path.
+- `automated.selfHeal: true` on an Application managing CRDs from a third-party operator = the operator's runtime status updates may be reverted as drift.
+- `automated` with no `syncWindow` covering deploy-freeze periods = a freeze window can be bypassed by a Git commit.
+
+Reference: [Auto-Sync](https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/) and [Sync Windows](https://argo-cd.readthedocs.io/en/stable/user-guide/sync_windows/).
+
+### Step 5 — Audit `syncOptions` for stateful or sensitive resources
+
+`spec.syncPolicy.syncOptions` overrides default sync behavior. Flag these as findings:
+
+- **`Replace=true`** — Argo CD deletes the resource and recreates it instead of patching. For `StatefulSet`, `PersistentVolume`, `PersistentVolumeClaim`, `Service` (ClusterIP rotation), `ConfigMap` consumed by hot-reload — this is data loss or downtime.
+- **`Force=true`** — passes `--force` to `kubectl apply`. Disables conflict detection.
+- **`ServerSideApply=false`** when Argo CD's default is server-side apply on newer versions — falls back to client-side three-way merge, which can re-introduce drift loops.
+- **`PruneLast=true`** missing on Applications that delete resources — pruning happens before resource creation, briefly leaving the namespace in an unhealthy state.
+- **`CreateNamespace=true`** with no namespace finalizer or RBAC scope — creates namespaces outside AppProject `destinations`.
+
+### Step 6 — Audit `ApplicationSet` generators
+
+ApplicationSet generators expand into multiple Applications. Risk surface depends on generator type:
+
+- **`list` generator** — explicit list of clusters/parameters. Lowest risk.
+- **`cluster` generator** — generates an Application for every registered cluster matching a label selector. **Critical** when the selector is empty (`{}`) or matches all clusters — a new cluster automatically receives the workload before review.
+- **`git` generator** — generates an Application for every directory or file pattern in a Git repo. Risk: a malicious or accidental commit adds a new directory and triggers a new Application.
+- **`matrix` and `merge` generators** — combine other generators. Risk multiplies.
+- **`pullRequest` generator** — generates Applications for open PRs. Risk: any PR can trigger an ephemeral deployment with the PR's manifests.
+- **`scmProvider` generator** — generates Applications for every repo in an org. Risk: org-wide auto-onboarding.
+
+Reference: [ApplicationSet Generators](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators/) and [Progressive Syncs (RollingSync)](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/).
+
+Stress-tests:
+
+- ApplicationSet with `cluster` generator + no selector + auto-sync = every cluster auto-onboarded in seconds.
+- ApplicationSet with `pullRequest` generator + no namespace isolation = PRs deploy to shared namespaces.
+- ApplicationSet with `goTemplate: true` and unsanitized template inputs = template injection if PR titles are templated into manifests.
+
+### Step 7 — Audit `argocd-rbac-cm` policy
+
+The Argo CD RBAC ConfigMap (`argocd-rbac-cm`) defines who can do what in the Argo CD UI/CLI/API. Check:
+
+1. The default role (`policy.default`) — `role:readonly` is safe; `role:admin` is wrong.
+2. Specific actions on resources — newer Argo CD versions ship granular actions like `action/apps/Deployment/restart` or `action/argoproj.io/Rollout/abort`. Each granted action should map to a real on-call runbook.
+3. RBAC subject scopes — `g, <group>, role:admin` on broad SSO groups is a finding.
+
+Reference: [Argo CD RBAC](https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/).
+
+### Step 8 — Multi-cluster (Argo CD Agent) topology
+
+If Argo CD Agent is in use:
+
+- The control plane stores `Application` specs; each spoke runs an agent that pulls assigned Applications.
+- Each agent has its own credentials and authentication path — verify rotation cadence.
+- Network path from spoke to hub must be authenticated and encrypted.
+
+Reference: [argocd-agent](https://github.com/argoproj-labs/argocd-agent).
+
+## Output
+
+Return:
+
+- **target**: `Application`, `AppProject`, `ApplicationSet`, or RBAC ConfigMap, with the project boundary,
+- **evidence level**: `live evidence` / `documentation-based` / `sanitized user evidence` / `inference`,
+- **sync identity**: controller default vs impersonated SA vs cluster credential, with judgment on least privilege,
+- **blast radius**: `sourceRepos`, `destinations`, `clusterResourceWhitelist`, `namespaceResourceBlacklist` audit,
+- **drift posture**: `automated.prune`, `automated.selfHeal`, sync windows, syncOptions concerns,
+- **risk findings** (with severity: high / medium / low) — covering sync identity, blast radius, drift, ApplicationSet generators, RBAC,
+- **safest next actions** with sample manifest changes,
+- **rollback plan**: how to revert auto-sync, disable selfHeal, narrow AppProject scope without breaking running Applications,
+- **assumptions and missing facts**.
+
+## Security notes
+
+- Never recommend `automated.prune: true` + `automated.selfHeal: true` on production Applications without a tested rollback runbook.
+- Never recommend `AppProject` with `sourceRepos: ['*']` and `destinations: ['*']` for application projects. Platform projects may need this; document the justification.
+- Never recommend disabling sync impersonation as a default in production after it has been enabled.
+- Never request or print Argo CD admin tokens, repo SSH keys, or destination cluster bearer tokens.

package/skills/aws/README.md

@@ -1,6 +1,8 @@
 # AWS Skills
 
-<img src="../../assets/logos/cloud/aws/aws-cdnlogo.png" alt="AWS logo" width="140" />
+<p align="center">
+  <img src="../../assets/logos/cloud/aws/aws-cdnlogo.png" alt="AWS logo" width="140" />
+</p>
 
 
 This folder contains AWS-focused skills curated for this marketplace.

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

@@ -1,9 +1,12 @@
 ---
 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.
+allowed-tools: Read Edit Write MultiEdit Grep Glob Bash
 metadata:
   author: "github: Raishin"
   version: "0.1.6"
+  updated: "2026-05-05"
+  category: ai
 ---
 
 # AWS AgentCore

package/skills/aws/aws-api-edge-delivery-review/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: aws-api-edge-delivery-review
 description: Review AWS API and edge delivery posture across API Gateway, CloudFront, AWS WAF, Shield, ALB, custom domains, TLS policies, authentication, authorization, throttling, quotas, caching, origin protection, logging, and abuse controls. Use when public APIs, web entry points, or edge delivery can affect security and availability.
+allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.2"
+  updated: "2026-05-05"
+  category: networking
 ---
 
 # AWS API Edge Delivery Review

package/skills/aws/aws-bedrock-agent-security-governor/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: aws-bedrock-agent-security-governor
 description: Review Amazon Bedrock agents, AgentCore, Guardrails, knowledge bases, action groups, memory, MCP/tool integrations, prompt-injection and prompt-leakage defenses, PII handling, encryption, logging, observability, and least-privilege IAM. Use for AWS-native GenAI and agent security posture.
+allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.2"
+  updated: "2026-05-05"
+  category: security
 ---
 
 # AWS Bedrock Agent Security Governor

package/skills/aws/aws-change-impact-advisor/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: aws-change-impact-advisor
 description: Assess AWS change impact using change sets, deployment blast radius, rollback readiness, dependency mapping, risk, go/no-go context, approval context, and stakeholder communication. Prefer this for non-destructive pre-change advisory work; prefer IaC or platform-specific skills for deep implementation review.
+allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
   version: "0.1.0"
+  updated: "2026-05-05"
+  category: delivery
 ---
 
 # AWS Change Impact Advisor

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

@@ -1,9 +1,12 @@
 ---
 name: aws-ci-cd-release-engineer
 description: Review AWS CI/CD and release safety across CodePipeline, CodeBuild, CodeDeploy, GitHub Actions, GitLab, artifact provenance, deployment gates, approvals, tests, progressive delivery, rollback, change correlation, and incident-prevention recommendations. Use when AWS releases or pipelines can affect production reliability or security.
+allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.2"
+  updated: "2026-05-05"
+  category: delivery
 ---
 
 # AWS CI/CD Release Engineer

package/skills/aws/aws-compliance-evidence-mapper/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: aws-compliance-evidence-mapper
 description: Map AWS compliance evidence for audits across Security Hub controls, AWS Config rules/conformance packs, Audit Manager assessments, evidence folders, manual evidence, AWS Artifact reports, CloudTrail, and control narratives. Use for evidence packaging and audit readiness, not general security hardening.
+allowed-tools: Read Grep Glob
 metadata:
   author: "github: Raishin"
   version: "0.1.2"
+  updated: "2026-05-05"
+  category: compliance
 ---
 
 # AWS Compliance Evidence Mapper

package/skills/aws/aws-cost-anomaly-watch-coordinator/SKILL.md

@@ -1,9 +1,12 @@
 ---
 name: aws-cost-anomaly-watch-coordinator
 description: Review AWS cost anomalies using Cost Explorer, Cost Anomaly Detection, Budgets, usage spikes, commitments, and tagging gaps. Prefer this for proactive FinOps watch and non-destructive escalation; prefer aws-cost-optimization-governor for broader optimization strategy.
+allowed-tools: Read Grep Glob WebFetch
 metadata:
   author: "github: Raishin"
   version: "0.1.0"
+  updated: "2026-05-05"
+  category: finops
 ---
 
 # AWS Cost Anomaly Watch Coordinator