{
  "markdown": "# Zscaler Terraform Skills\n\n[![Agent Skill](https://img.shields.io/badge/Agent-Skill-5865F2)](https://agentskills.io)\n[![Terraform](https://img.shields.io/badge/Terraform-1.6+-623CE4)](https://www.terraform.io/)\n[![OpenTofu](https://img.shields.io/badge/OpenTofu-1.6+-FFD814)](https://opentofu.org/)\n[![License](https://img.shields.io/github/license/zscaler/terraform-provider-zpa?color=blue)](https://github.com/zscaler/terraform-provider-zpa/v2/blob/master/LICENSE)\n[![Zscaler Community](https://img.shields.io/badge/zscaler-community-blue)](https://community.zscaler.com/)\n\nA bundle of agent skills that teach AI coding assistants (Claude Code, Cursor, Copilot, Gemini CLI, OpenCode, Codex, …) how to design and write correct Terraform HCL for the Zscaler providers. Five skills ship in this bundle:\n\n| Skill                    | Scope                                                                                                                            |\n| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |\n| `zpa-skill`              | Zscaler Private Access (`zscaler/zpa`) — resource catalog, OneAPI / legacy / GOV / microtenant auth, policy rules, troubleshooting. |\n| `zia-skill`              | Zscaler Internet Access (`zscaler/zia`) — resource catalog, rule ordering, activation lifecycle, troubleshooting.                |\n| `ztc-skill`              | Zscaler Zero Trust Cloud (`zscaler/ztc`, formerly Cloud Branch Connector) — resource catalog, cloud-orchestrated objects, activation. |\n| `zcc-skill`              | Zscaler Client Connector (`zscaler/zcc`) — resource catalog, singleton / existing-only patterns, env-var trap.                   |\n| `best-practices-skill`   | Cross-cutting engineering discipline for any Zscaler-Terraform repo — state, CI/CD with the activation step, secrets, testing, modules, naming, anti-patterns. |\n\nThe four provider skills cover **provider correctness** (what attributes does this resource take, how does auth work, how do you avoid known API quirks). The best-practices skill covers **engineering discipline** (how do you structure the repo, how do you split state, how do you wire CI/CD, how do you handle secrets and testing). Install the provider skills you use plus the best-practices skill — they're designed to compose.\n\n> **What this is not.** This repo does not help you *develop* the providers themselves (Go code, Plugin SDK, acceptance tests). It is for **end users writing HCL** that consumes the published `zscaler/*` providers. The canonical schema source for every `zpa_*`, `zia_*`, `ztc_*`, and `zcc_*` resource is the official Terraform Registry: <https://registry.terraform.io/providers/zscaler>.\n\n## What these skills provide\n\n### Provider correctness (zpa, zia, ztc, zcc)\n\n- Resource catalog per provider with minimum-viable HCL grounded in the live Registry\n- OneAPI vs legacy v3 vs GOV authentication patterns; multi-cloud vanity-domain handling\n- Microtenant scoping (`microtenant_id`) for the ZPA resources that actually accept it\n- Policy-rule operand structures (ZPA access policy, ZIA URL filtering, ZTC firewall) — the parts that aren't obvious from the schema\n- Activation lifecycle: which products require it (ZIA, ZTC) and which don't (ZPA, ZCC)\n- Known API quirks distilled from real customer support cases\n\n### Engineering discipline (best-practices)\n\n- State organization for multi-microtenant, multi-team Zscaler estates\n- The Zscaler activation step in CI pipelines (frequently forgotten by base LLMs)\n- Secret handling: OneAPI rotation, the `ZSCALER_*` vs `<product>_*` env-var trap, write-only / ephemeral variables (Terraform 1.11+)\n- Module patterns sized to Zscaler API granularity, not generic AWS-shaped boilerplate\n- Naming, variables, outputs, and 30+ documented anti-patterns specific to Zscaler resource graphs\n\n### Testing strategy\n\n- Three-layer test pyramid: `unit.tftest.hcl` (plan-only, no creds) → `mock.tftest.hcl` (`mock_provider`, Terraform 1.7+) → `integration.tftest.hcl` (sandbox tenant only)\n- When to use `terraform test` vs Terratest for Zscaler workloads\n- Sandbox-tenant guardrails — never run integration tests against production credentials\n\n### CI/CD workflows\n\n- GitHub Actions templates that include the activation step\n- OIDC against Zidentity (preferred) vs long-lived OneAPI client secrets\n- Drift detection, scheduled plans, PR-test/apply-on-merge gates with `terraform validate` + `terraform plan -out`\n\n### Security & secrets\n\n- OneAPI client rotation strategy and per-environment scoping (sandbox vs production tenants)\n- Write-only / ephemeral variables for `client_secret` handling (Terraform 1.11+)\n- The provider env-var trap that silently authenticates against the wrong namespace\n\n### Quick reference\n\n- Decision tables for the most common HCL questions (`count` vs `for_each`, module split, state split, OneAPI vs legacy)\n- ❌/✅ rules covering the most common Zscaler-Terraform mistakes\n\n## Why a skill?\n\nBase LLMs hallucinate against non-AWS/Azure/GCP providers — they invent ZPA attribute names, miss required fields, get policy-rule operand structures wrong, and skip the Zscaler-specific activation step in CI. These skills ground the model in:\n\n- The exact resources each provider exposes, with canonical minimum-viable HCL.\n- Provider-config + auth (OneAPI vs legacy, env vars, multi-cloud).\n- Policy-rule semantics that aren't obvious from the schema (operands, ordering, conditional fields).\n- Known API quirks distilled from real customer support cases.\n- Engineering discipline that's specifically different from generic Terraform: per-microtenant state organization, the activation step in CI, OIDC against Zidentity, the `ZSCALER_*` vs `<product>_*` env-var trap.\n\n## Install\n\nPick the path that matches how you already manage agent skills. All paths consume the same five `SKILL.md` files — the only difference is where they end up on disk and how updates are pulled.\n\n| Path | Best for | Version pinning |\n|------|----------|-----------------|\n| [`gh skill`](#github-cli-gh-skill) | Reproducible installs across teams; CI/agent provisioning | Yes — pin to a tag (`--pin v0.1.0`) or commit SHA |\n| [`gemini extensions install`](#gemini-cli) | Gemini CLI users who want one-command install + auto-update | Tag (auto-updates to latest by default) |\n| [Claude Code plugin](#claude-code) | Claude Code users on the marketplace | Marketplace-managed |\n| [Cursor plugin](#cursor) | Cursor users — marketplace install once listed, local plugin load before then | Marketplace-managed (post-listing) / `git pull` |\n| [Codex plugin](#codex-openai) | OpenAI Codex CLI / IDE / app users | Marketplace-managed (post-listing) / `git pull` |\n| [`npx skills add`](#any-host-npx-skills) | One-shot install across many agent hosts at once | Latest only |\n\n### GitHub CLI (`gh skill`)\n\nRequires **`gh` v2.90.0+** ([release notes](https://github.blog/changelog/2026-04-16-manage-agent-skills-with-github-cli/)). Check with `gh --version`; upgrade via `brew upgrade gh` or the [signed `.pkg`](https://github.com/cli/cli#installation).\n\n```bash\n# Pick skills + agent host interactively\ngh skill install zscaler/zscaler-terraform-skills\n\n# Install one skill into a specific host, pinned to a release\ngh skill install zscaler/zscaler-terraform-skills zpa-skill --agent claude-code --pin v0.1.0\n\n# Update everything later\ngh skill update --all\n```\n\nThe five installable skill names are `zpa-skill`, `zia-skill`, `ztc-skill`, `zcc-skill`, `best-practices-skill`. Pinning is recommended for production environments — every release is tagged automatically by semantic-release, so `--pin v<version>` gives you reproducible installs.\n\n### Claude Code\n\n```bash\n/plugin marketplace add zscaler/zscaler-terraform-skills\n/plugin install zscaler-terraform-skills@zscaler\n```\n\n### Cursor\n\nThis repo ships a [Cursor plugin manifest](.cursor-plugin/plugin.json), so it can be installed three ways depending on whether it has been listed in the [Cursor marketplace](https://cursor.com/marketplace).\n\n**Cursor marketplace (once listed):**\n\nOpen the marketplace panel inside Cursor (or [cursor.com/marketplace](https://cursor.com/marketplace)) and search for `zscaler-terraform-skills`, then click Install. Cursor handles updates automatically.\n\n**Local plugin install (works today, even before marketplace listing):**\n\n```bash\ngit clone https://github.com/zscaler/zscaler-terraform-skills.git ~/.cursor/plugins/local/zscaler-terraform-skills\n```\n\nReload the Cursor window (Cmd-Shift-P → \"Reload Window\"). Cursor reads the plugin manifest and registers all five skills. Update with `git pull` in the cloned directory.\n\n**Skill-only fallback (no manifest required):**\n\n```bash\ngit clone https://github.com/zscaler/zscaler-terraform-skills.git ~/.cursor/skills/zscaler-terraform-skills\n```\n\nCursor auto-discovers any `skills/<name>/SKILL.md` underneath. Same content, just without the plugin packaging.\n\n### Codex (OpenAI)\n\nThis repo ships a [Codex plugin manifest](.codex-plugin/plugin.json) for the OpenAI Codex CLI, IDE extension, and Codex app. Codex distinguishes between *skills* (the authoring format) and *plugins* (the installable distribution unit). The manifest unlocks the plugin install path; the skills themselves still work via auto-discovery without it.\n\n**Plugin install via Codex's skill installer:**\n\nInside Codex, run:\n\n```text\n$skill-installer\n```\n\nWhen prompted, point it at this repository (`https://github.com/zscaler/zscaler-terraform-skills`). Codex detects the manifest, registers all five skills under the plugin name `zscaler-terraform-skills`, and tracks updates.\n\n**Skill-only auto-discovery (works today, no manifest required):**\n\n```bash\ngit clone https://github.com/zscaler/zscaler-terraform-skills.git ~/.agents/skills/zscaler-terraform-skills\n```\n\nCodex auto-discovers skills under `~/.agents/skills/` (user scope) and `<repo>/.agents/skills/` (repo scope). Update with `cd ~/.agents/skills/zscaler-terraform-skills && git pull`. Disable any skill without deleting it by adding an entry to `~/.codex/config.toml`:\n\n```toml\n[[skills.config]]\npath = \"/Users/<you>/.agents/skills/zscaler-terraform-skills/skills/zia-skill/SKILL.md\"\nenabled = false\n```\n\n### Gemini CLI\n\nInstall as a Gemini CLI extension (auto-discovers all five skills via the `skills/` directory):\n\n```bash\ngemini extensions install https://github.com/zscaler/zscaler-terraform-skills --consent --auto-update\n```\n\n- `--consent` — acknowledge the standard third-party-extension warning non-interactively.\n- `--auto-update` — pull in the next semantic-release tag automatically.\n\nUpdate / uninstall:\n\n```bash\ngemini extensions update zscaler-terraform-skills      # only needed if --auto-update is off\ngemini extensions uninstall zscaler-terraform-skills\n```\n\nAlternative — clone into Gemini's skill-discovery tier instead of the extension subsystem:\n\n```bash\ngit clone https://github.com/zscaler/zscaler-terraform-skills ~/.gemini/skills/zscaler-terraform-skills\n```\n\n### Any host (`npx skills`)\n\nCross-agent installer that writes to the right per-host directory and prompts you for which agents to target:\n\n```bash\nnpx skills add https://github.com/zscaler/zscaler-terraform-skills\n```\n\nWhen prompted, press <kbd>a</kbd> on the skill picker to select all five at once, then pick which agent hosts to install into.\n\n## How it works\n\nThis is one **plugin** with five **skills**:\n\n```text\nzscaler-terraform-skills/\n├── .claude-plugin/marketplace.json\n├── skills/\n│   ├── zpa/                  # Router for ZPA HCL questions\n│   │   ├── SKILL.md\n│   │   └── references/       # On-demand depth\n│   ├── zia/SKILL.md          # Router for ZIA HCL questions\n│   ├── ztc/SKILL.md          # Router for ZTC HCL questions\n│   ├── zcc/SKILL.md          # Router for ZCC HCL questions\n│   └── best-practices/       # Router for cross-cutting engineering questions\n│       ├── SKILL.md\n│       └── references/       # state, ci-cd, security, testing, quick-ref, …\n└── tests/baseline-scenarios.md\n```\n\nEach `SKILL.md` has a YAML `description` that triggers it. The agent picks the right skill based on the question — *\"Create a ZPA application segment for finance.example.com\"* loads `zpa-skill`; *\"How should I split state for a multi-microtenant ZPA setup?\"* loads `best-practices-skill`. The two compose: the best-practices skill cross-references the provider skills for resource-level details, and the provider skills cross-reference the best-practices skill for engineering questions.\n\nEvery router follows the same shape:\n\n1. **Capture context** (provider version, auth mode, microtenant, OneAPI vs legacy, environment criticality).\n2. **Diagnose intent** via a routing table.\n3. **Load only the matching reference** under `references/`.\n4. **Emit answer** ending with the Response Contract (assumptions, risk, validation, rollback).\n\n## Verify install\n\nAfter install, try:\n\n```text\n\"Create a ZPA application segment that exposes crm.example.com on TCP 443 to a SCIM group called Engineering.\"\n```\n\nThe agent should: name the provider version floor (`~> 4.0`), pick `zpa_application_segment`, wire `segment_group_id` + `server_groups`, and finish with a `terraform validate` + `terraform plan -out` validation block.\n\n## Quick start examples\n\nProvider-specific (load `zpa-skill` / `zia-skill` / `ztc-skill` / `zcc-skill`):\n\n- `\"Create a ZPA access policy that allows Engineering SCIM group to a CRM application segment from posture-compliant devices.\"`\n- `\"Set up ZPA provider authentication using OneAPI client credentials with environment variables.\"`\n- `\"Why does my ZPA policy rule keep showing drift on the conditions block after every refresh?\"`\n- `\"Add a ZIA URL filtering rule that blocks gambling categories for the Sales department, ordered after the existing predefined rules.\"`\n- `\"Wire the ZIA activation step into my GitHub Actions apply job.\"`\n\nCross-cutting (load `best-practices-skill`):\n\n- `\"How should I split Terraform state for a ZPA + ZIA setup with three microtenants and two teams?\"`\n- `\"Write me a GitHub Actions pipeline for ZIA that PR-tests, applies on merge, and includes the activation step.\"`\n- `\"What's the right pattern for OIDC against Zidentity from a CI workflow instead of long-lived client secrets?\"`\n- ``\"Show me how to test a ZIA URL filtering module with `terraform test` against a sandbox tenant.\"``\n- ``\"Quick: do I use `count` or `for_each` for a list of ZPA application segments, and why?\"``\n\n## What it covers\n\n### Provider skills (zpa, zia, ztc, zcc)\n\nEach provider skill ships a `SKILL.md` router plus a focused set of references:\n\n| Skill | References |\n|-------|-----------|\n| `zpa-skill` | `auth-and-providers.md`, `resource-catalog.md`, `policy-rules.md`, `troubleshooting.md`, `recent-provider-changes.md` |\n| `zia-skill` | `auth-and-providers.md`, `resource-catalog.md`, `rules-and-ordering.md`, `activation.md`, `troubleshooting.md`, `recent-provider-changes.md` |\n| `ztc-skill` | `auth-and-providers.md`, `resource-catalog.md`, `rules-and-ordering.md`, `troubleshooting.md`, `recent-provider-changes.md` |\n| `zcc-skill` | `auth-and-providers.md`, `resource-catalog.md`, `troubleshooting.md`, `recent-provider-changes.md` |\n\n`recent-provider-changes.md` is regenerated by `scripts/changelog/mine.py` from each provider's upstream `CHANGELOG.md`, filtered to surface only HCL-visible changes (new resources, attribute additions, breaking renames). Internal SDK bumps and refactors are dropped.\n\n### Testing strategy\n\nA three-layer pyramid documented in `skills/best-practices-skill/references/testing-and-validation.md`:\n\n| Layer | File | Terraform | Credentials | What it verifies |\n|-------|------|-----------|-------------|------------------|\n| **Unit** | `tests/unit.tftest.hcl` | 1.6+ | none | Variable validation, `locals` math, plan-only sanity |\n| **Mock wiring** | `tests/mock.tftest.hcl` | 1.7+ | none | Module output wiring and resource-attribute propagation via `mock_provider` |\n| **Integration** | `tests/integration.tftest.hcl` | 1.6+ | sandbox tenant only | Real Zscaler API acceptance — never against production |\n\nThe skill also covers when `terraform test` is enough vs when Terratest (Go) makes sense for Zscaler workloads, and the activation-step gotchas in tests for ZIA / ZTC modules.\n\n### CI/CD workflows\n\n`skills/best-practices-skill/references/ci-cd-zscaler.md` covers Zscaler-specific CI patterns that generic Terraform CI templates miss:\n\n- **The activation step.** ZIA and ZTC require an explicit activation API call after every successful apply or the configuration sits inactive on the tenant. The reference shows how to wire it into both GitHub Actions and GitLab CI.\n- **OIDC against Zidentity** as a replacement for long-lived OneAPI client secrets in CI runners.\n- **Per-environment workflow split** (sandbox-on-PR, prod-on-merge-with-approval).\n- **Drift detection** scheduled plans against the Zscaler tenants.\n\n### State management\n\n`skills/best-practices-skill/references/state-management.md` covers state organization scaled to Zscaler estates:\n\n- Per-microtenant state files vs single state with `for_each` over microtenants\n- Splitting state across `zpa-platform / zpa-policies / zia-policies / ztc-rules` for blast-radius isolation\n- Backend choice + locking for Zscaler workflows\n- `terraform_remote_state` and `moved {}` block patterns for safe refactors\n\n### Security & secrets\n\n`skills/best-practices-skill/references/security-and-compliance.md` covers:\n\n- OneAPI client rotation strategy and per-environment scoping\n- The `ZSCALER_*` vs `<product>_*` env-var trap (most common ZCC / ZPA auth confusion)\n- Write-only (`*_wo`) and ephemeral variables for `client_secret` handling on Terraform 1.11+\n- Trivy / Checkov scanning hooked into the Zscaler workflow\n\n### Patterns and anti-patterns\n\n- `coding-practices.md` — `count` vs `for_each` vs `dynamic`, `locals`, dynamic blocks (with the ZPA policy-operand example), variable validation, dependency management\n- `module-patterns.md` — module shapes, required files, boundaries (purpose not product, including legitimate cross-product modules such as IP Source Anchoring), composition, examples directory structure\n- `naming-conventions.md` — Terraform resource addresses vs Zscaler portal names, naming patterns per resource type\n- `variables-and-outputs.md` — typed variables with `optional()`, validation blocks, sensitive handling, output design for `for_each` collections\n- `versioning.md` — provider/Terraform constraints, lockfile discipline, module SemVer, `moved {}` blocks for safe renames, OneAPI migration strategy\n- `anti-patterns.md` — quick-index of 30+ Zscaler-Terraform anti-patterns, cross-linked to the file that explains the right pattern\n- `import-and-brownfield.md` — adopting an existing ZIA/ZPA tenant with `zscaler-terraformer`, single-object `terraform import`, `removed {}` instead of `state rm`\n\n## Why these skills\n\n**Sources:**\n\n- The four published Zscaler provider repos: [`terraform-provider-zpa`](https://github.com/zscaler/terraform-provider-zpa), [`terraform-provider-zia`](https://github.com/zscaler/terraform-provider-zia), [`terraform-provider-ztc`](https://github.com/zscaler/terraform-provider-ztc), `terraform-provider-zcc`\n- De-identified customer support patterns from real Zscaler-Terraform engagements\n- Engineering discipline patterns from [terraform-best-practices.com](https://www.terraform-best-practices.com/) adapted to Zscaler API granularity\n\n**Version-specific guidance:**\n\n- Terraform 1.6+ (`terraform test` framework)\n- Terraform 1.7+ (`mock_provider` for offline testing)\n- Terraform 1.11+ (`write_only` / ephemeral variables for secret handling)\n- Provider versions explicitly tracked: ZPA `~> 4.0`, ZIA `~> 4.0`, ZTC `~> 1.0`, ZCC (forthcoming)\n\n**Decision frameworks** — the skills don't just teach \"what\" but \"when and why\" for: state split granularity, microtenant scoping, OneAPI vs legacy, activation step strategy, test-layer choice, module boundaries.\n\n## Requirements\n\n- A skill-aware AI host: Claude Code, Cursor, Copilot, Gemini CLI, OpenCode, Codex, or any [Agent Skills](https://agentskills.io)-compatible tool\n- Terraform 1.6+ or OpenTofu 1.8+ (1.7+ recommended for `mock_provider` tests; 1.11+ for `write_only` / ephemeral variables)\n- Zscaler tenant credentials (OneAPI client preferred, legacy v3 supported)\n- For OneAPI: Zidentity migration completed on the target tenant\n- Optional: a sandbox tenant for integration tests; an OIDC issuer (e.g. GitHub Actions) for CI-against-Zidentity\n\n## Local development\n\nA `Makefile` ships with the targets used by CI. Run them locally before opening a PR:\n\n```bash\nmake help              # Show all targets\nmake validate          # Run every check below in one go (mirrors CI)\nmake check-frontmatter # Validate YAML frontmatter in every SKILL.md\nmake check-links       # Verify every internal references/*.md link resolves\nmake check-line-counts # Warn if any SKILL.md exceeds the 300-line budget\nmake check-versions    # Verify marketplace.json + gemini-extension.json + every SKILL.md agree\nmake spec-check        # Validate every skill against the agentskills.io spec via 'gh skill publish --dry-run' (gh >= 2.90.0)\nmake line-counts       # Print line counts for every SKILL.md and reference\nmake lint              # Lint all markdown via markdownlint (uses .markdownlint.json)\nmake lint-fix          # Auto-fix every issue markdownlint can fix\nmake release-dry       # Preview what semantic-release would publish next (no writes)\n```\n\n`make spec-check` wraps `gh skill publish --dry-run` — it validates the same rules `gh skill publish` would enforce (skill name == directory name, required frontmatter present, no install metadata committed) **without ever creating a release**. Releases are owned exclusively by semantic-release; never run `gh skill publish` (without `--dry-run`) against this repo.\n\nMarkdown style is enforced by [`markdownlint-cli`](https://github.com/igorshubovych/markdownlint-cli) against the rules in `.markdownlint.json`. Install once with `npm install -g markdownlint-cli`. CI runs the same check on every PR via `DavidAnson/markdownlint-cli2-action`.\n\n## Releases\n\nReleases are fully automated by [semantic-release](https://github.com/semantic-release/semantic-release). The release workflow runs on every merge to `master`, parses the [conventional commit](https://www.conventionalcommits.org/) messages since the last tag, and decides the next version, the CHANGELOG entry, and the GitHub release notes from them.\n\n**You never bump versions by hand.** Just write conventional commits and merge.\n\n| Commit subject prefix | Effect |\n|-----------------------|--------|\n| `feat: …`             | Minor bump (e.g. `0.1.0` → `0.2.0`) — **use for new skill content / new reference files / new capability areas** |\n| `fix: …`              | Patch bump (e.g. `0.1.0` → `0.1.1`) — **use for factual corrections, wrong attribute names, broken links** |\n| `perf: …`             | Patch bump |\n| `docs: …` / `refactor: …` / `chore: …` / `style: …` / `test: …` / `ci: …` / `build: …` | No release |\n| `feat!: …` or any commit body containing `BREAKING CHANGE:` | Major bump (anchor renames, removed reference files) |\n\n> Skill content changes are the product, so use `feat:` / `fix:`. `docs:` is for repo-internal docs (README, CLAUDE.md) that don't ship to skill consumers.\n\nWhat semantic-release does on every release:\n\n1. Computes the next version from commits since the last tag.\n2. Runs `python3 scripts/release/sync_versions.py <next_version>` to write the new version into `.claude-plugin/marketplace.json` and every `skills/*/SKILL.md` frontmatter.\n3. Prepends a categorized entry to `CHANGELOG.md`.\n4. Commits the version files + changelog back to `master` as `chore(release): X.Y.Z [skip ci]`.\n5. Creates an annotated `vX.Y.Z` git tag.\n6. Publishes a GitHub Release with the generated notes.\n\nPreview the next release locally without publishing (semantic-release and its plugins are pulled on demand via `npx` — no `package.json` is checked in):\n\n```bash\nmake release-dry\n```\n\nConfiguration lives in [`.releaserc.json`](.releaserc.json) and the workflow in [`.github/workflows/release.yml`](.github/workflows/release.yml), which uses [`cycjimmy/semantic-release-action`](https://github.com/cycjimmy/semantic-release-action) to install plugins inline.\n\n## Contributing\n\nSee [CLAUDE.md](CLAUDE.md) for the LLM-consumption authoring rules and content structure. PRs that add or change skill content must include a before/after baseline scenario in `tests/baseline-scenarios.md`. Bug reports and feature requests via GitHub Issues.\n\n## Related resources\n\n### Zscaler official\n\n- [Zscaler Provider Registry](https://registry.terraform.io/providers/zscaler) — canonical schema for every `zpa_*`, `zia_*`, `ztc_*`, `zcc_*` resource\n- [`zscaler/terraform-provider-zpa`](https://github.com/zscaler/terraform-provider-zpa)\n- [`zscaler/terraform-provider-zia`](https://github.com/zscaler/terraform-provider-zia)\n- [`zscaler/terraform-provider-ztc`](https://github.com/zscaler/terraform-provider-ztc)\n- [Zscaler Help Center](https://help.zscaler.com/)\n- [Zscaler OneAPI / Zidentity overview](https://help.zscaler.com/oneapi/about-oneapi)\n\n### Terraform & OpenTofu\n\n- [Terraform Language documentation](https://developer.hashicorp.com/terraform/docs)\n- [Terraform Testing (`terraform test`)](https://developer.hashicorp.com/terraform/language/tests)\n- [Mock Providers](https://developer.hashicorp.com/terraform/language/tests/mocking)\n- [OpenTofu documentation](https://opentofu.org/docs/)\n- [HashiCorp Recommended Practices](https://developer.hashicorp.com/terraform/cloud-docs/recommended-practices)\n\n### Community\n\n- [terraform-best-practices.com](https://terraform-best-practices.com) — the engineering-discipline foundation we extend for Zscaler\n- [Awesome Terraform](https://github.com/shuaibiyy/awesome-tf)\n- [Terratest](https://terratest.gruntwork.io/docs/) — Go testing framework, reference for when `terraform test` isn't enough\n\n### Development tools\n\n- [pre-commit-terraform](https://github.com/antonbabenko/pre-commit-terraform) — pre-commit hooks for Terraform\n- [terraform-docs](https://terraform-docs.io/) — generate documentation from modules\n- [terraform-switcher](https://github.com/warrensbox/terraform-switcher) — Terraform version manager\n- [TFLint](https://github.com/terraform-linters/tflint) — Terraform linter\n- [Trivy](https://github.com/aquasecurity/trivy) — IaC security scanner\n- [Checkov](https://www.checkov.io/) — IaC policy-as-code scanner\n\n## License\n\nMIT — see [LICENSE](LICENSE).\n",
  "bytes": 26710,
  "sha": "a985118251c70738154a1b5e1d0eaadfe82caab856d62e8b9cd4df3cbdabf421",
  "repo_slug": "zscaler/zscaler-terraform-skills",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_zscaler_zscaler_terraform_skills_35f749db/readme"
}