D
Damira AI

Automation & Generators

Terraform, Python automation, CI/CD pipelines, tests, and lab topologies your AI writes and validates locally, with golden config templates for the deterministic parts. No external server required.

Your AI writes the automation. Damira validates it before it comes back to you. Ask for Terraform, a Python script, a CI pipeline, tests, or a lab topology in Cursor or Claude Code, and every one goes through a local check before you see the result — no NetBox, Ansible Automation Platform, pyATS, or Terraform server required to use these.

If you already run those tools and want Damira to read your source of truth and hand a change to them, see Damira + NetBox + pyATS + Ansible instead — that page is about wiring in servers you already run; this one needs none of them.

What each generator produces

You ask forSkillOutput
Infrastructure as codeTerraformHCL for NetBox, Palo Alto PAN-OS, FortiOS, Cisco Meraki, IOS-XE, and NX-OS providers (Arista EOS/CloudVision has no Terraform provider — Ansible instead)
A scriptPython automationNornir, Netmiko, or Scrapli, with a YAML inventory, for pushing config, collecting show output, backups, or fleet audits
CI/CDPipelineGitHub Actions or GitLab CI: lint, syntax check, plan or check-mode, a manual approval gate, then deploy
VerificationTestspyATS/Genie learn-change-learn-diff jobs that prove a change did what it should and nothing else, plus pytest for automation scripts
A throwaway environmentLabA runnable ContainerLab topology with startup configs, for practicing or reproducing a scenario
Proof before the windowLab-test-changeDeploys a lab, applies your playbook or script, runs the checks, reports pass/fail, and always tears the lab down

Every generator ends the same way

  1. Your AI writes the file. Grounded in vendor docs where syntax matters — a provider's resource arguments, a platform's CLI, a Genie feature name — never guessed.
  2. A local validate loop checks it. Formatting, linting, and a syntax or dry-run check (terraform fmt/init -backend=false/validate, ansible-lint, yamllint, ruff, or the equivalent for the file type). Findings get fixed and the check reruns, capped at three rounds. This step is delegated to a fast, low-cost local check that only fixes what the validator named — it doesn't redesign the change or look up new syntax.
  3. The hand-back is always a dry run. terraform plan, --check/--syntax-check, --dry-run, or the platform's equivalent. Nothing here runs apply, pushes a live config, or reaches a device — you review the plan and run it yourself, in your own pipeline or shell.

No generator skill refuses a mainstream framework. If a request needs something outside what's listed above, say so rather than silently substituting a different tool.

Lab before prod

generate-lab builds the topology; lab-test-change proves a specific change against it. Point lab-test-change at a playbook, script, or Terraform config, and it deploys a ContainerLab lab, applies the change, runs show-command or pyATS/Genie checks, and reports pass or fail — then always tears the lab down, including when the apply or a check fails. It needs Docker and ContainerLab on your machine; without them, it validates the change only and says so. It never targets production — the apply step only ever reaches the lab's own inventory.

Golden config templates

Some configuration has exactly one right answer: NTP, AAA/TACACS+, SNMPv3, syslog, a banner. damira render fills a reviewed Jinja2 template for Cisco IOS, NX-OS, Arista EOS, or Junos from a small vars file, so your AI doesn't hand-write lines that don't need judgment. It's the deterministic-baseline building block behind generate-playbook's config sections. Secrets never live in the vars file — a value written as env:NAME is read from the environment at render time, and only a small set of prefixes (NET_, TACACS_, RADIUS_, SNMP_, NTP_, SYSLOG_, GOLDEN_) can be read that way, so a vars file from an untrusted repo can't pull other secrets into the output.

On this page