TypingMindTypingMindThe best frontend for AI
Landing Zone Config logo

Landing Zone Config

Organization
oci-landing-zones
landing-zone-config

Use when authoring, reviewing, or debugging Blueprint Factory input used by `gen/generate.sh --config`, especially when adding environments, shared platforms, environment platforms, hub changes, or extension-backed network layouts.

Overview

Publisheroci-landing-zones
Repositoryoci-landing-zone-operating-entities
Skill namelanding-zone-config
Stars
67
Forks
35
Bundled files
4
LicenseUPL-1.0
Links
Skill sourceRepositoryHomepage
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 4 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by oci-landing-zones on GitHub. Read the source before you install it.

Installation

Install the Landing Zone Config AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/oci-landing-zones/oci-landing-zone-operating-entities/tree/master/.agents/skills/landing-zone-config
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/oci-landing-zones/oci-landing-zone-operating-entities.git /tmp/oci-landing-zone-operating-entities
mkdir -p .claude/skills
cp -r /tmp/oci-landing-zone-operating-entities/.agents/skills/landing-zone-config .claude/skills/landing-zone-config
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Landing Zone Config in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Landing Zone Config on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Landing Zone Config is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Landing Zone Config

Overview

Use this skill when work should go through the Blueprint Factory instead of editing generated JSON files directly.

Core principle: treat the landing zone config as the source of truth, then verify behavior against the Blueprint Factory normalization and orchestration code before changing schema assumptions.

AGENTS.md remains canonical for customer safety, discovery, artifact placement, unsupported resources, and deployment defaults. If the request starts as customer design or deployment guidance and the customer path is not yet chosen, use landing-zone-customer-guidance first. This skill starts after the conversation has reached the Blueprint Factory path or the user explicitly asks for Blueprint Factory config-mode details.

When to Use

  • Creating a new config file for bash gen/generate.sh --config ...
  • Reviewing or fixing an Blueprint Factory topology change
  • Adding or changing environments, project_network, platforms, or shared_platforms
  • Wiring a platform extension such as oke_simple
  • Debugging why Blueprint Factory config mode generated an unexpected JSON output or omitted a file

Do not use this skill for legacy checked-in JSON output edits unless the task is explicitly about the Blueprint Factory path. Do not use this skill as the first response to an open-ended customer request such as "I want landing zone to run OKE" when the required customer discovery decisions are still unknown.

Workflow

  1. Start with the source-of-truth files:
    • gen/AGENTS.md for architecture, schema intent, and generator guardrails
    • gen/config.libsonnet for required fields and normalization rules
    • gen/landing_zone.libsonnet for orchestration and topology behavior
    • gen/landing_zone_multi.jsonnet for config-mode outputs
  2. Before creating files, ask where the config source file should live and where the generated landing zone outputs should go. Use separate paths.
  3. Build the config as a Jsonnet object, not raw JSON, so imports and composition stay available.
  4. Ask for the target OCI region before authoring customer config. Default realm to oc1 when it is not provided, and set realm explicitly for non-oc1 deployments such as oc19.
  5. Keep only the smallest top-level shape first: hub, plus region values when the customer has provided them and realm only when needed. Add environments only when the Landing Zone has named environments.
  6. Add environments and platforms incrementally, then run Blueprint Factory config mode and inspect the generated outputs.
  7. When behavior is unclear, prefer reading the normalization and extension code over guessing from checked-in JSON.
  8. If the question is about Orchestrator runtime behavior, dependency files, output files, Resource Manager source settings, or duplicate top-level configuration collisions, use oci-lz-orchestrator-contract-advisor as a supporting verifier rather than expanding this skill into runtime troubleshooting.
  9. For customer deployment handoff, read ../landing-zone-customer-guidance/references/orm-bucket-deployment.md and provide the exact phase file sets emitted by the current run. Prefer an in-place update of the same ORM stack for staged outputs. This is advisory guidance only: do not upload the files or invoke ORM Plan, Apply, Destroy, stack updates, or monitoring from this skill.

Quick Rules

TopicRule
Required fieldshub.kind and hub.network.vcn are mandatory. environments is optional and defaults to {} for a hub-only Landing Zone.
Region defaultsregion and region_short_name must be provided together or omitted together; when omitted (or both explicitly set to null) they default to eu-frankfurt-1 and fra.
Stack scopestack_scope defaults to complete; regional supports platforms and registered extensions, including regional CIS2 Vaults/keys, while omitting home-owned IAM, governance, Cloud Guard, and Security Zones.
DR regionSet dr_region on the complete home config to include the selected DR Object Storage service in its key-use policy. The regional source has its own region and region_short_name.
Security targetsOmit security_targets to target all environments; set it explicitly to narrow which environments get security-zone targeting.
Hub kindsOnly hub_a, hub_b, hub_c, and hub_e are valid.
Hub subnetsOmit hub.network.subnets to auto-generate canonical hub subnets from the hub VCN.
Shared project subnetsOmitted generates default web, app, db, infra; {} emits none; a non-empty map is exact and suppresses all implicit defaults.
Dedicated project subnetsUse projects.<project>.subnets; they require project_network, must not overlap any shared/dedicated subnet, and remain in the environment NETWORK compartment.
Shared vs dedicatedRecommend shared subnets by default for address efficiency. Dedicated subnets provide separate project CIDR allocation, not IAM isolation; access is governed at the environment network compartment. Same-subnet traffic is controlled by NSGs/security lists, not the hub firewall.
Project subnet routingOmit project_network.subnet_routing for vcn; use hub with firewalled Hub A, B, or C. Hub C requires real firewall backend targets; Hub E is rejected.
Platform subnetsPlatforms need explicit subnets unless they also declare an extension that provides subnet metadata.
Realmrealm is optional and defaults to oc1, including when explicitly set to null; supported config realms are oc1 and oc19.
CIS levelcis_level is optional and technically defaults to 2, but customer-use discovery must obtain an explicit CIS1/CIS2 choice. CIS2 is recommended and adds CMEK dependencies for applicable resources; set 1 for the less complex CIS1 output set.
ExtensionsExtension type must be registered in gen/landing_zone.libsonnet.
Config-mode network outputsnetwork.json is the canonical network output for every hub.
RPC configModel each Landing Zone in a separate source config and each requested connection under top-level remote_peering_connections; read gen/addons/oci-x-rpc/AGENTS.md, derive local VCNs dynamically, and collect per-connection role, peer region, reviewed remote CIDRs, requestor peer reference, cross-tenancy peer tenancy OCID, and the foreign requestor group OCID only for acceptors.
Artifact placementAsk for both the config file location and the output directory before creating customer artifacts; do not default them into tests/.
Unsupported resourcesDo not add unsupported config keys or fake extension types. Generate only supported prerequisites, then document the unsupported resource as manual post-deployment configuration.
Networked extension CIDRsInclude CIDRs only for network scopes the selected config will emit; do not allocate for unchosen optional placement branches or networkless/infrastructure-only scopes.
Preferred deploymentORM with a customer-controlled private Object Storage bucket through a pinned Orchestrator rms-facade; Terraform CLI and customer CI/CD remain alternatives.
ExaCS networkNetwork is required for ExaCS AVMC/VMC placement and forbidden for ExaCS infrastructure-only placement.
ExaCS project DB tiersUse project_db_compartments only for Autonomous Database Dedicated project tiers; project_network is only needed when the environment also needs project network resources.

Authoring Guidance

  • Prefer one small config file per scenario and compose from imports if reuse is needed.
  • For regional DR, collect both regions explicitly, set dr_region on the complete home config, and author the acceptor there. Author the requester in a regional-scope DR config with its own region metadata, then generate each independently with --config. The complete home stack must provision matching compartment, governance, and extension IAM prerequisites. CIS2 regional output creates its own Vaults and keys; existing workload key and secret replication remains separate.
  • For customer-use work, keep config sources and generated outputs in customer-chosen or explicitly approved working directories. Reserve tests/gen/testdata/... for repo-development fixtures and automated tests, not customer artifact placement.
  • Use project_network only for environments that should produce spoke VCN outputs.
  • Put environment-scoped platforms under environments.<env>.platforms.
  • Put shared platforms under top-level shared_platforms.
  • Treat the three shared-subnet states deliberately: omit the map for the four defaults, use {} for none, or provide the complete exact map. The factory never adds standard shared subnets around a supplied map.
  • Before authoring project subnet maps, confirm shared versus dedicated placement. Explain that per-project subnet allocation can strand addresses in mostly empty ranges and is not an IAM boundary. Also explain that dedicated placement does not send same-subnet traffic through the hub firewall; NSGs and security lists remain mandatory for that traffic.
  • Resolve network-producing extension scope and sizing before CIDR allocation; make any deliberate reserved space explicit in the customer-facing rationale.
  • When selecting CIDRs, check whether the landing zone will connect to on-premises or other clouds; any routed OCI or Kubernetes ranges must avoid overlap with those external networks.
  • When adding a new extension-backed platform, verify both the config schema and the extension contract.
  • For OKE, read gen/workload-extensions/oke/AGENTS.md before giving exact CIDR splits or networking contract guidance.
  • For RPC, read gen/addons/oci-x-rpc/AGENTS.md; create one config per Landing Zone, allow multiple named connections when the graph requires them, omit peer_id on each acceptor edge, require it on each requestor edge, and never hardcode environment names or counts.
  • Keep RPC remote_cidrs separate from local topology. Include every reviewed peer VCN range that must be reachable, and reject overlaps with local hub, environment, and platform VCNs.
  • For ExaCS, complete the placement decisions in AGENTS.md, then use gen/workload-extensions/exacs/AGENTS.md for the config mapping.
  • For ExaDB-C@C, complete the placement decisions in AGENTS.md, then use the generator guide under gen/workload-extensions/exacc/ for config and publication semantics.
  • If a requested resource is unsupported by Blueprint Factory config mode, keep unsupported resources out of generated files and mark the separate work as "Manual post-deployment configuration required."

Verification

  • Run bash gen/generate.sh --config <config_file> [output_dir] for normal Blueprint Factory generation.
  • When validating a customer config, point generation at a separate output directory such as a temp directory or customer-approved working directory rather than a repo test fixture path.
  • If you need raw multi-output behavior without formatting, run jsonnet --multi <output_dir>/ --tla-code-file config=<config_file> gen/landing_zone_multi.jsonnet.
  • Compare generated files with the expected output set from gen/landing_zone_multi.jsonnet: network.json, iam.json, governance.json, and the selected security_cis* / observability_cis* files are emitted; network_backends.json plus extension outputs remain conditional.
  • For RPC graphs, verify every acceptor edge omits peer_id/peer_key, every requestor edge contains the reviewed peer reference, all network outputs contain the expected per-edge RPC routes and DRG surfaces, and only cross-tenancy configs add RPC IAM policies.

References

  • For the customer-facing supported configuration shape, read addons/oci-lz-blueprint-factory/blueprint-factory-configuration-reference.md.
  • For the schema and behavior map, read references/schema-and-behavior.md.
  • For starter patterns and repo-native examples, read references/examples.md.
  • For ORM + private Object Storage deployment and staged in-place updates, read ../landing-zone-customer-guidance/references/orm-bucket-deployment.md.
  • For Blueprint Factory OKE semantics and CIDR guardrails, read gen/workload-extensions/oke/AGENTS.md.
  • For Blueprint Factory RPC roles, routing, IAM, CIDR guardrails, publication, and deployment order, read gen/addons/oci-x-rpc/AGENTS.md.
  • For Blueprint Factory ExaCS placement and component semantics, read gen/workload-extensions/exacs/AGENTS.md.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Landing Zone Config AI skill do?

Use when authoring, reviewing, or debugging Blueprint Factory input used by `gen/generate.sh --config`, especially when adding environments, shared platforms, environment platforms, hub changes, or extension-backed network layouts.

Why use Landing Zone Config on TypingMind?

Because you install it once and use it with any model. Landing Zone Config is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Landing Zone Config in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/oci-landing-zones/oci-landing-zone-operating-entities/tree/master/.agents/skills/landing-zone-config. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Landing Zone Config?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Landing Zone Config?

As many as you like. As long as a model supports skills, you can use Landing Zone Config with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Landing Zone Config AI skill free?

Yes. It is published on GitHub by oci-landing-zones under the UPL-1.0 license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

Related AI Skills

View all
openclaw logo

Openclaw Testing

openclaw
OrganizationPopular

Choose proportional OpenClaw tests and checks, diagnose failures, and route environment-sensitive or release proof to its owner.

82.2K
391K
2 files
View
mattpocock logo

Wizard

mattpocock
CommunityPopular

Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar…

22.3K
264.4K
2 files
View
affaan-m logo

Deployment Patterns

affaan-m
CommunityPopular

Flujos de trabajo de despliegue, patrones de pipeline CI/CD, contenedorización Docker, health checks, estrategias de rollback y listas de verificación de preparación para producción de aplicaciones…

39.1K
261.1K
Instructions
View
affaan-m logo

Docker Patterns

affaan-m
CommunityPopular

Patrones de Docker y Docker Compose para desarrollo local, seguridad de contenedores, networking, estrategias de volúmenes y orquestación de múltiples servicios.

39.1K
261.1K
Instructions
View

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇