@raishin/vanguard-frontier-agentic 1.1.0 → 1.3.0

package/scripts/update-catalog-new-agents.py

@@ -0,0 +1,88 @@
+#!/usr/bin/env python3
+"""Add all new agent and skill metadata.json entries to catalog JSON files."""
+
+from __future__ import annotations
+
+import json
+from pathlib import Path
+
+ROOT = Path(__file__).resolve().parents[1]
+
+CATALOG_AGENTS = ROOT / "catalog" / "agents.json"
+CATALOG_SKILLS = ROOT / "catalog" / "skills.json"
+
+CATALOG_FIELDS_AGENT = {
+    "id", "name", "type", "provider", "summary", "path",
+    "harnesses", "last_verified", "official_docs", "security_notes",
+    "source_type", "version",
+}
+CATALOG_FIELDS_SKILL = CATALOG_FIELDS_AGENT | {"author"}
+
+
+def metadata_to_catalog_entry(m: dict, kind: str) -> dict:
+    entry: dict = {}
+    for key in ("id", "name", "type", "provider", "harnesses", "summary",
+                "source_type", "official_docs", "security_notes",
+                "last_verified", "path", "version"):
+        if key in m:
+            entry[key] = m[key]
+    # Normalise path — strip trailing slash
+    if "path" in entry and isinstance(entry["path"], str):
+        entry["path"] = entry["path"].rstrip("/")
+    if kind == "skill" and "author" in m:
+        entry["author"] = m["author"]
+    return entry
+
+
+def main() -> None:
+    agents_catalog: list[dict] = json.loads(CATALOG_AGENTS.read_text(encoding="utf-8"))
+    skills_catalog: list[dict] = json.loads(CATALOG_SKILLS.read_text(encoding="utf-8"))
+
+    existing_agent_ids = {e["id"] for e in agents_catalog}
+    existing_skill_ids = {e["id"] for e in skills_catalog}
+
+    new_agents: list[dict] = []
+    for meta_path in sorted(ROOT.glob("agents/**/metadata.json")):
+        m = json.loads(meta_path.read_text(encoding="utf-8"))
+        if m.get("type") != "agent":
+            continue
+        if m["id"] not in existing_agent_ids:
+            entry = metadata_to_catalog_entry(m, "agent")
+            new_agents.append(entry)
+            print(f"  + agent: {entry['id']}")
+
+    new_skills: list[dict] = []
+    for meta_path in sorted(ROOT.glob("skills/**/metadata.json")):
+        m = json.loads(meta_path.read_text(encoding="utf-8"))
+        if m.get("type") != "skill":
+            continue
+        if m["id"] not in existing_skill_ids:
+            entry = metadata_to_catalog_entry(m, "skill")
+            new_skills.append(entry)
+            print(f"  + skill: {entry['id']}")
+
+    if new_agents:
+        agents_catalog.extend(new_agents)
+        agents_catalog.sort(key=lambda x: x["id"])
+        CATALOG_AGENTS.write_text(
+            json.dumps(agents_catalog, indent=2, ensure_ascii=False) + "\n",
+            encoding="utf-8",
+        )
+        print(f"\nWrote {len(agents_catalog)} agents to {CATALOG_AGENTS.relative_to(ROOT)}")
+    else:
+        print("No new agents to add.")
+
+    if new_skills:
+        skills_catalog.extend(new_skills)
+        skills_catalog.sort(key=lambda x: x["id"])
+        CATALOG_SKILLS.write_text(
+            json.dumps(skills_catalog, indent=2, ensure_ascii=False) + "\n",
+            encoding="utf-8",
+        )
+        print(f"Wrote {len(skills_catalog)} skills to {CATALOG_SKILLS.relative_to(ROOT)}")
+    else:
+        print("No new skills to add.")
+
+
+if __name__ == "__main__":
+    main()

package/skills/argocd/README.md

@@ -0,0 +1,30 @@
+# 🚢 Argo CD Skills
+
+<p align="center">
+  <!-- 🖼️ Add an Argo CD logo to assets/logos/cnative/argocd/ and update this path -->
+  <span style="font-size:3.5em">🚢</span>
+</p>
+
+This folder contains Argo CD-focused skills curated for this marketplace.
+
+## Local marketplace portfolio
+
+This folder contains **1** local Argo CD skill:
+
+- `argocd-gitops-review`
+
+## Portfolio posture
+
+Argo CD skills for evidence-backed GitOps delivery review across `Application`, `AppProject`, `ApplicationSet`, sync windows, RBAC, sync impersonation, and multi-cluster (Argo CD Agent) topologies.
+
+These skills are intentionally conservative:
+
+- prefer `kubectl get applications,appprojects,applicationsets -n argocd -o yaml` and `argocd-cm` configmap state for live grounding before any review
+- treat `application.sync.impersonation.enabled: false` in production as a critical finding — the controller's cluster-admin ServiceAccount is the sync identity
+- treat `AppProject` with `sourceRepos: ['*']` and `destinations: ['*']` as a wide-blast-radius finding requiring explicit justification
+- challenge `automated.prune: true` + `automated.selfHeal: true` on production Applications — Git divergence becomes irreversible deletion
+- challenge `ApplicationSet` generators that include unbounded clusters or label selectors — one mis-labeled cluster joins the rollout
+- prefer `destinationServiceAccounts` (per-Application impersonation) over the controller's default cluster-admin
+- use official Argo CD documentation (argo-cd.readthedocs.io) for sync semantics, RBAC syntax, ApplicationSet strategies, and Argo CD Agent hub-and-spoke topology
+
+Run `npm run validate` after changing cataloged Argo CD skills.

package/skills/argocd/argo-rollouts-progressive-delivery-review/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: argo-rollouts-progressive-delivery-review
+description: Use this skill when reviewing Argo Rollouts progressive delivery configuration. Trigger when the user asks about canary or blue-green Rollout strategy correctness, AnalysisTemplate success/failure conditions, traffic weighting provider alignment, canaryService isolation, PDB deadlock risk with Rollout maxSurge settings, automated rollback posture, or manual vs automated promotion configuration.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# Argo Rollouts Progressive Delivery Review
+
+## Purpose
+
+Review Argo Rollouts canary and blue-green strategy configuration, AnalysisTemplate success and failure condition correctness, traffic management provider alignment, canaryService vs stableService isolation, PDB compatibility with Rollout surge settings, and automated rollback posture. Argo Rollouts' safety depends entirely on AnalysisTemplate conditions that actually fail — an always-true successCondition means automated rollback never fires, regardless of actual error rates.
+
+## Lean operating rules
+
+- Prefer live evidence (`kubectl get rollout -A -o yaml`, `kubectl get analysistemplate -A -o yaml`, `kubectl argo rollouts status <name>`) when the active client exposes it; otherwise fall back to official Argo Rollouts documentation and sanitized YAML from the user.
+- Separate confirmed facts from inference. If AnalysisTemplate metric query results, traffic provider actual behavior, or PDB state was not directly queried, say so.
+- Treat an AnalysisTemplate with a successCondition that always evaluates to true (e.g., `result >= 0`, `true`) as a critical finding — automated rollback can never fire.
+- Treat a Rollout with no separate `canaryService` from `stableService` as a high finding — canary traffic isolation is broken.
+- Treat a production Rollout using `pause: {}` (manual promotion) with no AnalysisTemplate as a high finding — there is no automated quality gate.
+- Treat a traffic provider in `spec.strategy.canary.trafficRouting` that does not match the actual ingress controller installed in the cluster as a high finding — weight changes are silently ignored.
+- Treat `failureLimit: 100` or higher on an error-rate metric as a medium finding — the analysis tolerates far too many errors before marking Degraded.
+- Keep the answer scoped, evidence-labeled, and explicit about what was not queried.
+
+## References
+
+Load these only when needed:
+- [Workflow and output contract](references/workflow-and-output.md)
+
+## Response minimum
+
+Return, at minimum:
+- the scoped target (Rollout name, AnalysisTemplate name, or traffic provider config) and evidence level,
+- the deployment strategy (canary with steps vs canary without steps, blue-green) and whether steps include AnalysisRun gates,
+- AnalysisTemplate successCondition and failureCondition correctness,
+- canaryService vs stableService isolation posture,
+- traffic provider alignment with the actual cluster ingress,
+- PDB compatibility with Rollout maxSurge/maxUnavailable,
+- the safest next actions and any assumptions or blockers.

package/skills/argocd/argo-rollouts-progressive-delivery-review/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "argo-rollouts-progressive-delivery-review",
+  "name": "Argo Rollouts Progressive Delivery Review",
+  "type": "skill",
+  "provider": "argocd",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Review Argo Rollouts canary and blue-green strategy configuration, AnalysisTemplate success/failure conditions, traffic management provider alignment, canaryService isolation, PDB deadlock risk, and automated rollback posture for progressive delivery safety.",
+  "source_type": "original",
+  "official_docs": [
+    "https://argoproj.github.io/argo-rollouts/",
+    "https://argoproj.github.io/argo-rollouts/features/canary/",
+    "https://argoproj.github.io/argo-rollouts/features/analysis/",
+    "https://argoproj.github.io/argo-rollouts/features/traffic-management/",
+    "https://argoproj.github.io/argo-rollouts/features/bluegreen/",
+    "https://argoproj.github.io/argo-rollouts/generated/kubectl-argo-rollouts/kubectl-argo-rollouts_promote/"
+  ],
+  "security_notes": "AnalysisTemplates with always-true success conditions defeat automated rollback entirely. A canary that never fails analysis will silently promote a broken release to 100% production traffic.",
+  "last_verified": "2026-05-02",
+  "path": "skills/argocd/argo-rollouts-progressive-delivery-review",
+  "author": "github: Raishin",
+  "version": "0.1.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,43 @@
+---
+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.
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+---
+
+# 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.