Skip to content

SKILL

Purpose

This skill guides agents writing or reviewing code that uses wingpy. It is a routing and decision layer, not a replacement for the wingpy documentation. Use it to pick the right docs, stay close to documented examples, and avoid avoidable design mistakes.

When to use

Activate this skill when any of the following are true:

  • the codebase imports wingpy or any of its clients
  • the task mentions a wingpy client or supported platform
  • the task involves REST API automation with wingpy
  • the task asks for examples, tests, wrappers, integrations, or docs related to wingpy
  • the task requires choosing the correct wingpy client for a specific platform

Procedure

  1. Identify the target platform and match it to a documented wingpy client.
  2. Read the platform-specific User Guide first for task patterns and examples.
  3. Read the matching API Reference page to verify constructor parameters, supported methods, and return behavior.
  4. Use the client reference below to check for authentication mode, supported environment variables, and the best official API documentation source.
  5. Use the FAQ only for shared behavior such as context managers, exceptions, environment variables, and concurrency patterns.
  6. Read the general User Guide for configuration details such as logging, error handling, or concurrency.
  7. Verify toolchain dependencies, like package manager, virtual environment, and environment variables, before running tests and run required commands in the detected project environment.
  8. Write Pythonic solutions using documented wingpy patterns. Use the guardrails and coding patterns below to avoid common mistakes and anti-patterns.

Client Reference

Cisco APIC

Cisco Catalyst Center

Cisco Catalyst SD-WAN vManage

Cisco FMC

Cisco Hyperfabric

Cisco ISE

Cisco Meraki Dashboard

Cisco Modeling Labs

Nautobot

  • Client: wingpy.Nautobot
  • Auth: external token
  • Environment variables: WINGPY_NAUTOBOT_TOKEN, WINGPY_NAUTOBOT_BASE_URL
  • User Guide: Nautobot User Guide
  • API Reference: Nautobot API Reference
  • Official REST docs: Nautobot REST API Overview
  • Note: ask for the target instance's API specification when behavior may vary by version, plugin, or local extensions.

NetBox

  • Client: wingpy.NetBox
  • Auth: external token
  • Environment variables: WINGPY_NETBOX_TOKEN, WINGPY_NETBOX_BASE_URL
  • User Guide: NetBox User Guide
  • API Reference: NetBox API Reference
  • Official REST docs: NetBox REST API Overview
  • Note: ask for the target instance's API specification when behavior may vary by version, plugin, or local extensions.

Cisco Nexus Dashboard

Splunk Enterprise

Core Rules

  • Use the documented wingpy client directly unless an added layer owns clear domain behavior.
  • Prefer documented endpoint paths, request shapes, and workflow patterns.
  • Prefer environment variables over hardcoded credentials when the client supports them.
  • Import wingpy at module scope in normal application code.
  • Build write payloads from documented writable fields. Do not round-trip GET responses into POST or PUT bodies unless the docs explicitly require the same shape.
  • Reuse one client context per platform per phase for batch workflows unless the docs show a different requirement.
  • If the task is a sync or reconciliation tool, default to the least destructive action when source data is missing or ambiguous.
  • Use only the client section that matches the target platform.
  • For vendor-specific path or payload semantics, use the platform's official REST documentation in addition to the wingpy docs.

Abstraction Test

Before adding a helper, wrapper, adapter, or service layer around wingpy, name the behavior it owns.

Good reasons:

  • request or response normalization required by the domain
  • orchestration across multiple API calls
  • conflict detection, safety policy, or plan/apply separation
  • batching, polling, or workflow coordination not already provided by wingpy

Bad reasons:

  • hiding import wingpy
  • forwarding one or two client methods unchanged
  • storing constructor arguments like verify
  • renaming a wingpy client without adding behavior

If you cannot name the behavior the abstraction owns, do not create it.

Tool Shapes

  • One-off script: stay very close to the documented example.
  • CLI or admin tool: keep platform-specific code thin and explicit.
  • Batch mutation tool: prefer one client context per phase and explicit reporting of actions.
  • Sync or reconciliation tool: separate planning from applying, use stable identity keys, and prefer skip or noop over destructive inference.
  • Reusable library code: extract only logic that normalizes domain data or enforces policy.

Escalate When

  • the writable payload shape is unclear from the docs
  • the unique identifier or matching key is ambiguous
  • version-specific behavior could change correctness
  • the task implies destructive reconciliation but the source of truth is incomplete
  • the vendor docs and wingpy docs appear to disagree

Documentation Routing

Guardrails

  • Do not invent unsupported wingpy clients.
  • Do not invent methods that are not present in the docs or reference.
  • Do not bypass wingpy with raw HTTP code unless the task explicitly requires it.
  • Do not add custom token refresh logic without evidence that it is needed for that client.
  • Do not present guessed behavior as documented fact.
  • Never hardcode passwords, secrets or tokens. Use the client environment variables or getpass() when possible.
  • Do not expose internal defaults such as timeout, retry counts or page sizes unless the task explicitly requires them.

Practical Defaults

  • Prefer the documented authentication approach for the chosen client.
  • Prefer path_params when the endpoint contains documented placeholders.
  • Use get_all() only when the docs show it as the right collection pattern.
  • For exception handling, prefer wingpy's documented exception model over broad exception swallowing.
  • For parallel API calls, prefer documented .tasks.schedule() and .tasks.run() patterns when they fit the use case.
  • Avoid embedding secrets in reusable examples; use placeholders instead.