Quality gates, secrets & limits

The skill is built to be trustworthy rather than impressive: it refuses to generate configurations from a model it cannot validate, redacts secrets by default, and labels everything it simulates. This page explains those guardrails and what the toolkit does not model.

#The quality gate

Configurations are only generated when the model passes the gate: no errors and every declared test passing. If a test cannot be decided, the result is inconclusive and generation is still refused. With --strict — the mode for production reviews — warnings fail the gate too.

When the gate fails, Claude fixes the model and validates again instead of handing you commands for a design it knows is broken. The command reference lists how each command behaves.

#Candidate configurations

Generated configurations are candidates for review, not commands to apply blindly:

• They target supported platform profiles. A generator producing a command does not prove that a specific device, image or license supports it; version-specific commands are flagged for verification.
• They never save the startup-config. You decide when to run copy running-config startup-config.
• Generating a configuration does not authorize applying it. On real networks, apply changes only with authorization, a backup, an impact review and a rollback plan.

#Secrets

For a Packet Tracer lab, ask Claude for "the configs with the lab passwords". Lab passwords such as cisco or class, Telnet, SNMPv2c and 1024-bit RSA keys are acceptable only in labs; the skill says so and gives the production alternative.

#Imported configurations

netlab import builds a partial model from show running-config and CDP output. Lines it does not understand lose their values, are quarantined and are never emitted in generated configs. The import report lists what was skipped, and audits report those gaps instead of assuming them away.

#What the tests prove

Model tests are simulated IPv4 ICMP pings. They do not prove:

• TCP or UDP application policies (for example, that only HTTPS reaches a server);
• IPv6 connectivity (IPv6 routing tables are analyzed, but IPv6 packets are not traced);
• wireless behavior.

Those need separate checks on the devices. A ping that is expected to fail only demonstrates isolation when positive controls pass and the denial reason has been checked.

#Simulation limits

#Supported platforms

• CLI generation: Cisco IOS / IOS XE routers and switches, and Cisco ASA firewalls.
• Packet Tracer: models, commands and GUI steps. Editable .pkt projects are not generated.
• Unsupported profiles, such as NX-OS, block configuration builds instead of producing guessed commands.

#Evidence labels

Reports separate what the model shows from what was observed:

• MODELED — follows from the rules implemented in the model.
• APPROXIMATE — simplified protocol behavior, such as metrics.
• OBSERVED — backed by output collected from the real devices.
• INCONCLUSIVE — information or support is missing.

A simulated success is never reported as observed connectivity.