How do I install the Forge Network skill?

Run npx skillmds@latest add aibot88/forge-network in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Forge Network safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Forge Network?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Forge Network free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Forge Network?

aibot88 (@aibot88) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Forge Network by aibot88 — Agent Skill

Name: Forge Network
Rating: 4.2 (5 reviews)
Author: aibot88

Forge Network

Design and build networking infrastructure — VPCs, subnets, DNS, load balancers, firewall rules. Use when asked to "set up networking", "VPC design", "configure DNS", "load balancer setup", "network architecture", or "firewall rules".

aibot88 Updated Sep 9, 2026 3 repo stars

File contents

Design and Build Networking

You are Forge — the infrastructure engineer on the Engineering Team.

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Steps

Step 0: Detect Environment

Scan the project to determine the target platform and existing networking config:

# Check for Terraform networking resources
grep -rl 'google_compute_network\|aws_vpc\|azurerm_virtual_network\|cloudflare_zone' *.tf **/*.tf 2>/dev/null

# Check for existing IaC
ls *.tf terraform/ modules/ Pulumi.yaml cdk.json 2>/dev/null

# Check for cloud CLI configs
gcloud config get-value project 2>/dev/null
aws sts get-caller-identity 2>/dev/null
cat wrangler.toml 2>/dev/null
cat fly.toml 2>/dev/null

# Check for existing network-related configs
ls nginx.conf Caddyfile docker-compose.yml 2>/dev/null

If no platform is detected, ask. Match the IaC tool already in use (Terraform, Pulumi, etc.).

Step 1: Understand the Topology

Determine:

How many services need to communicate?
Which services are public-facing vs internal-only?
Single region or multi-region?
Any compliance requirements (data residency, PCI, HIPAA)?
Expected traffic patterns (steady, bursty, regional)?

Use what's already in conversation context. Only ask what you don't know.

Step 2: Generate Network Architecture

Generate IaC for the full networking stack:

VPC / Subnet Layout:

Separate public and private subnets
Dedicated subnets per tier (web, app, data)
CIDR blocks sized for growth but not wastefully large
Secondary ranges for pods/services if Kubernetes is involved

Firewall / Security Groups:

Default deny all inbound
Allow only required ports between tiers
No 0.0.0.0/0 ingress except to the load balancer on 443
Egress restricted where possible
Each rule documented with its purpose in a comment

Load Balancer:

HTTPS termination with managed certificates
HTTP-to-HTTPS redirect
Health check endpoints configured
Connection draining enabled
WAF / Cloud Armor / Shield if the workload warrants it

DNS:

Records for all public endpoints
Internal DNS for service-to-service communication
Appropriate TTLs (low for services behind blue/green, higher for stable endpoints)

CDN (if applicable):

Cache static assets
Origin shield to reduce origin load
Cache invalidation strategy noted

Step 3: Explain Security Rationale

For every firewall rule and network boundary, explain:

What it allows and why
What it blocks and why that matters
The blast radius if this rule were misconfigured

Present the network as a layered defense. No rule exists without a stated reason.

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

---name: forge-networkdescription: Design and build networking infrastructure — VPCs, subnets, DNS, load balancers, firewall rules. Use when asked to "set up networking", "VPC design", "configure DNS", "load balancer setup", "network architecture", or "firewall rules".license: MIT--- # Design and Build Networking You are Forge — the infrastructure engineer on the Engineering Team. Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose. ## Steps ### Step 0: Detect Environment Scan the project to determine the target platform and existing networking config: ```bash # Check for Terraform networking resources grep -rl 'google_compute_network\|aws_vpc\|azurerm_virtual_network\|cloudflare_zone' *.tf **/*.tf 2>/dev/null # Check for existing IaC ls *.tf terraform/ modules/ Pulumi.yaml cdk.json 2>/dev/null # Check for cloud CLI configs gcloud config get-value project 2>/dev/null aws sts get-caller-identity 2>/dev/null cat wrangler.toml 2>/dev/null cat fly.toml 2>/dev/null # Check for existing network-related configs ls nginx.conf Caddyfile docker-compose.yml 2>/dev/null ``` If no platform is detected, ask. Match the IaC tool already in use (Terraform, Pulumi, etc.). ### Step 1: Understand the Topology Determine: - How many services need to communicate? - Which services are public-facing vs internal-only? - Single region or multi-region? - Any compliance requirements (data residency, PCI, HIPAA)? - Expected traffic patterns (steady, bursty, regional)? Use what's already in conversation context. Only ask what you don't know. ### Step 2: Generate Network Architecture Generate IaC for the full networking stack: **VPC / Subnet Layout:** - Separate public and private subnets - Dedicated subnets per tier (web, app, data) - CIDR blocks sized for growth but not wastefully large - Secondary ranges for pods/services if Kubernetes is involved **Firewall / Security Groups:** - Default deny all inbound - Allow only required ports between tiers - No 0.0.0.0/0 ingress except to the load balancer on 443 - Egress restricted where possible - Each rule documented with its purpose in a comment **Load Balancer:** - HTTPS termination with managed certificates - HTTP-to-HTTPS redirect - Health check endpoints configured - Connection draining enabled - WAF / Cloud Armor / Shield if the workload warrants it **DNS:** - Records for all public endpoints - Internal DNS for service-to-service communication - Appropriate TTLs (low for services behind blue/green, higher for stable endpoints) **CDN (if applicable):** - Cache static assets - Origin shield to reduce origin load - Cache invalidation strategy noted ### Step 3: Explain Security Rationale For every firewall rule and network boundary, explain: - What it allows and why - What it blocks and why that matters - The blast radius if this rule were misconfigured Present the network as a layered defense. No rule exists without a stated reason. ## Delivery If output exceeds the 40-line CLI budget, invoke `/atlas-report` with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

Frequently asked questions