avav25/gitops-detection
plugin/skills/gitops-detection/SKILL.md
Use this skill when the agent is starting any Terraform or Helm change and needs to determine whether the apply flow is owned by a controller (in which case the change is a git PR, not a local imperative command) — for GitOps and orchestrator detection covering marker patterns and routing rules for Argo CD, Flux, Atlantis, HCP Terraform / Terraform Cloud, Spacelift, and env0. Loaded by `/infra-change` and related infrastructure workflows; not a workflow itself.
$ install --global
skillsauthnpx skillsauth add avav25/ai-assets gitops-detectionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 4:32 AM26.1s1 file scanned
SKILL.md
- name:
- gitops-detection
- description:
- Use this skill when the agent is starting any Terraform or Helm change and needs to determine whether the apply flow is owned by a controller (in which case the change is a git PR, not a local imperative command) — for GitOps and orchestrator detection covering marker patterns and routing rules for Argo CD, Flux, Atlantis, HCP Terraform / Terraform Cloud, Spacelift, and env0. Loaded by `/infra-change` and related infrastructure workflows; not a workflow itself.
- disable-model-invocation:
- true
GitOps Detection — Route the apply before running it
Knowledge reference for detecting GitOps controllers and managed-apply layers in an infrastructure repository. Before running terraform apply or helm upgrade directly, check whether the repo's infra changes flow through a controller. If so, the change is a git PR, not an imperative command.
Detection matrix
| Marker | System | Implication |
|---|---|---|
| argocd/ directory or Application / ApplicationSet CRDs in Git | Argo CD (GitOps) | Push manifest changes to git; Argo CD reconciles. Do NOT helm upgrade directly — it will be reverted on next sync. Use argocd app sync or kubectl argo rollouts promote only when intentionally bypassing the loop. |
| kustomization.yaml + Flux HelmRelease / Kustomization CRDs | Flux (GitOps) | Push to git; Flux reconciles. Manual override: flux reconcile kustomization <name>. |
| atlantis.yaml (root) | Atlantis | Plans run in PR comments via atlantis plan / atlantis apply. Do NOT run terraform apply locally — Atlantis is the apply gate. |
| terraform { cloud { ... } } block in .tf files | Terraform Cloud / HCP Terraform | Plans/applies run in HCP Terraform UI/API. Local terraform apply is disabled by the cloud backend. |
| .spacelift/ directory | Spacelift | Stacks orchestrate plans/applies. Local apply forbidden. |
| .env0/ or env0 stack tags | env0 | Same as Spacelift — managed apply layer. |
What to check, in order
- Look at the repo root for top-level files:
atlantis.yaml,.spacelift/,.env0/,argocd/. - Grep
.tffiles for thecloud { ... }block inside aterraform {}configuration block. - Check Kubernetes manifests for Argo CD
Application/ApplicationSetCRDs (apiVersionargoproj.io/v1alpha1) or Flux CRDs (apiVersionhelm.toolkit.fluxcd.io/kustomize.toolkit.fluxcd.io). - Look for
kustomization.yamlfiles paired with Flux CRDs — Kustomize alone is not GitOps; the Flux CRDs are the signal.
If multiple markers match (e.g., Argo CD for app manifests + Atlantis for Terraform), each domain routes independently to its controller.
Routing rules
If a GitOps controller or managed-apply layer is detected:
- Plan the change as a git PR against the manifest repo. Do not run local imperative commands.
- After PR approval and merge, the controller reconciles automatically (GitOps) or runs the apply (Atlantis / HCP Terraform / Spacelift / env0).
- Skip the local
terraform apply/helm upgradesteps in the parent workflow. - Verify reconciliation via the controller's status:
- Argo CD:
argocd app get <name>(look forSYNCED+HEALTHY) - Flux:
flux get kustomizations/flux get helmreleases - Atlantis: the PR comment thread (
atlantis applyoutput) - HCP Terraform: the run page in the HCP UI / API
- Spacelift / env0: the stack page in the vendor UI
- Argo CD:
When local override is acceptable
Manual overrides exist for incident response but should be used sparingly and documented in the change record:
- Argo CD:
argocd app sync <name>(force immediate reconcile) - Flux:
flux reconcile kustomization <name>/flux reconcile helmrelease <name> - HCP Terraform / Spacelift / env0: trigger a run from the vendor UI
For long-term changes, always merge to the git source of truth — controllers will revert out-of-band changes on the next reconcile.
When this applies
| Phase | Apply this knowledge | |---|---| | Step 0a — Detect orchestration / GitOps controllers | Run the detection matrix above before any plan or apply | | Step 5 — Plan review | If controller detected, "plan" = the PR diff in the manifest repo | | Step 6 — Apply | If controller detected, "apply" = PR merge + controller reconcile | | Step 7 — Verify | Use the controller's status command to confirm reconciliation |
Integration
- Used by:
/infra-change(Step 0a — pre-flight routing decision) - Companion knowledge:
@terraform-procedures(commands deferred when HCP/Atlantis/Spacelift/env0 owns the apply),@helm-procedures(commands deferred when Argo CD/Flux owns the apply) - External references: Argo CD docs, Flux docs, Atlantis docs, HCP Terraform docs, Spacelift docs, env0 docs
Related Skills
avav25/knowledge-sync
development
VerifiedTrustedCommunity
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
1SKILL.mdUpdated May 24, 2026
avav25/knowledge-sync-init
development
VerifiedTrustedCommunity
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
1SKILL.mdUpdated May 24, 2026
avav25/ai-skills-init
tools
VerifiedTrustedCommunity
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
1SKILL.mdUpdated May 18, 2026
avav25/plugin-author
tools
VerifiedTrustedCommunity
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.
1SKILL.mdUpdated May 14, 2026