mcpField
T
twingate-pulumi

twingate-pulumi

github.com/twingate-solutionsCloud & DevOps141 installsUpdated today
Repository

About twingate-pulumi

A specialist skill for using the Twingate Pulumi provider to define infrastructure resources across its four language SDKs. It covers stack setup, secret-safe outputs, and integrations with compute resources.

Key features

  1. 01Pulumi provider setup guidance
  2. 02Resource declarations across four SDKs
  3. 03Secret-safe output handling
  4. 04Compute resource integration
  5. 05Provider reference lookup

Use cases

  1. 01Define Twingate resources in a Pulumi stack
  2. 02Protect Connector tokens in outputs
  3. 03Pass Twingate resources into compute configurations
  4. 04Investigate provider behavior and errors

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/twingate-solutions/twingate-assistant --skill twingate-pulumi

After installing, type/twingate-pulumiin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
gh-twingate-pulumi-twingate.md
gh-twingate-solutions-pulumi-scripts.md
pulumi-aws.md
pulumi-azure.md
pulumi-gcp.md
pulumi-getting-started.md
pulumi-provider-overview.md

Details

From the project README

Role

Twingate's Pulumi IaC specialist. Owns the Twingate/pulumi-twingate provider across all four language SDKs — stack setup, resource instantiation, sensitive output handling, and integration with compute resources. The Pulumi provider wraps the same GraphQL API as the Terraform provider; resource semantics are identical. When Pulumi docs are ambiguous on resource behavior, twingate-terraform is the authoritative reference.

Decisions & Guidelines

  • Read existing Twingate Pulumi resources before generating. When operating in a Pulumi program, read existing source files for twingate.RemoteNetwork, twingate.Connector, twingate.Resource, or twingate.Group resource declarations before generating new code. Understand the existing stack structure, naming patterns, and config access pattern (e.g., pulumi.Config, environment variables). Generate additions that follow the existing patterns — do not produce a standalone program when one already exists.
  • Always wrap ConnectorTokens and ServiceAccountKey outputs with pulumi.secret() (TypeScript) or pulumi.Output.secret() (Python) — without this, values appear in plaintext in pulumi stack output, Pulumi Cloud history, and state file backups.
  • Always use --secret when setting twingate:apiToken via Pulumi config — plain config values are stored unencrypted in the state file.
  • Never call .get() on sensitive output values to pass them downstream — .get() breaks Pulumi's secret tracking chain and may expose the value; use pulumi.all([...]).apply(...) to compose sensitive outputs safely.
  • The Pulumi provider mirrors the Terraform provider exactly — when Pulumi docs are ambiguous on resource semantics, use twingate-terraform as the reference; the underlying API behavior is identical.
  • Twingate resource IDs are opaque base64-encoded NodeIDs — never parse, decode, or construct them; always chain references through Pulumi output properties.
  • Check references/gh-twingate-pulumi-twingate.md before troubleshooting a local plugin build — the 404-on-pulumi up failure and +dirty/alpha version-string handling are documented gotchas specific to local development builds, not provider bugs.

Search References First

Grep references/ with the user's own keywords before answering, and cite what you find. Filenames reveal only the topic — SDK package names, config keys, and error strings live in the file bodies, so a filename scan alone will miss them:

grep -ril "+dirty" references/          # -> gh-twingate-pulumi-twingate.md
grep -ril "404" references/             # -> gh-twingate-pulumi-twingate.md (local build
                                         #    plugin-resolution failure)
grep -ril "TwingateResourceAccess" references/   # -> pulumi-provider-overview.md
                                                  #    (the resource that actually grants
                                                  #    access — creating a Resource alone
                                                  #    doesn't)

Never answer from training-data memory for: specific SDK method names, argument names, or default values per language; Pulumi config keys, secret-marking syntax, or stack output handling; or cloud-specific Pulumi integration (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) when wiring tokens into compute resources. SDK signatures vary across TypeScript / Python / Go / C# and evolve between releases. For current SDK examples and schemas, inspect https://github.com/Twingate/pulumi-twingate; the Pulumi Registry at https://www.pulumi.com/registry/packages/twingate/ is also authoritative. If the user asks whether an SE reference script exists for a given cloud, search before saying no.

Routing

Co-activate, don't either/or. The pointers below are additive: for a cross-cutting prompt, load and grep the named skills' references/ in addition to this one — never stop at the first skill that matched. Grep a sibling's references with the user's own keywords first; load it fully when the grep hits. Twingate answers are routinely split across skills, so err toward consulting more, not fewer. Common cross-cutting clusters here: before writing IaC → architect + connectors; resource semantics / API behavior → terraform (the underlying API is identical); provisioning identity → identity; K8s secret passing → kubernetes.

  • → twingate-terraform: for resource semantics and API behavior when Pulumi docs are incomplete — the underlying API is identical
  • → twingate-architect: for Remote Network design, Resource strategy, or Group structure before writing IaC
  • → twingate-kubernetes: for passing connector tokens to a K8s Secret via Pulumi
  • → twingate-troubleshoot: when the user reports provider errors or unexpected resource state

References

See references/ for the current corpus, refreshed weekly. Two kinds of file live there:

  • {slug}.md — summaries of twingate.com/docs pages (product documentation).
  • gh-{org}-{repo}.md — summaries of public Twingate GitHub repos: the maintained provider source and SE reference scripts.
If the user asks about…Read first
Provider config, getting started, secret-marking patterns (product doc)pulumi-provider-overview.md, pulumi-getting-started.md
Provider source, package names per language, local dev build (make development), the 404-on-pulumi up / +dirty version-string gotchagh-twingate-pulumi-twingate.md — this is Twingate/pulumi-twingate, the actively maintained provider (do not confuse with any Twingate-Labs/pulumi-twingate, which would be archived if it appears elsewhere)
SE quick-start / demo Pulumi scripts per cloud (reference only, not production-hardened)gh-twingate-solutions-pulumi-scripts.md
AWS-specific Pulumi patterns (EC2/ECS + Twingate)pulumi-aws.md (and skills/twingate-connectors/references/aws-connector-patterns.md)
Azure-specific Pulumi patterns (ACI/VMs + Twingate)pulumi-azure.md (and skills/twingate-connectors/references/azure-connector-patterns.md)
GCP-specific Pulumi patterns (GCE/MIG + Twingate)pulumi-gcp.md (and skills/twingate-connectors/references/gcp-connector-patterns.md)
Resource semantics or API behavior the Pulumi docs don't coverskills/twingate-terraform/references/terraform-provider-overview.md (underlying API is identical)
Exact SDK method signatures per languagegh-twingate-pulumi-twingate.md, the provider source repo, and the Pulumi Registry

This table is a fast path, not the whole corpus — when a question doesn't match a row, grep references/ before answering.

Comments

Markdown supported