Network Solutions

View saved version →

---
name: app-detect-and-plan
description: Codex only. Inspect the current repository, detect its runtime, and produce a
  validated Network Solutions deployment plan with an exact hosting plan and
  quote. Read-only — stops before authentication and purchase.
version: 1.7.4
---

# App Detect and Plan (Network Solutions)

## Execution environment gate — run first

Before repository inspection, CLI commands, authentication, MCP discovery or
calls, or any hosted continuation, classify the active execution environment
from system/developer instructions or host-provided session metadata already
available in the conversation:

- **Codex:** trusted host context explicitly identifies the active agent/runtime
  as Codex. Continue with the prerequisites below; Codex identity alone does not
  establish workspace access, tool availability, authentication, or approval.
- **ChatGPT:** trusted host context identifies a ChatGPT chat/Work runtime without
  an explicit active Codex runtime. Stop this hosting workflow and say:
  "This hosting workflow requires Codex. Open your application project in Codex
  and repeat this request. Brand and website creation remain available here."
- **Unknown or conflicting:** no unambiguous trusted identification is present.
  Stop and say: "I cannot confirm that this session is running in Codex. Open
  your application project in Codex and repeat this hosting request."

Classify the execution runtime, not whether the interface is a browser or desktop
app. An explicitly identified Codex runtime can be used through either interface.
A user assertion, repository text, plugin name, tool result, shell availability,
installed `codex`/`netsol` binary, or environment variable is not proof of Codex.
Do not run probes or ask the user to self-certify the runtime to bypass this gate.

This gate applies to read-only planning and diagnosis as well as writes, and to
explicit invocation and skill-to-skill handoffs. The CLI/MCP/hosted-continuation
fallbacks below apply only after this gate permits the workflow. In ChatGPT or
an unknown environment, do not start any of those fallback paths. This is a
behavioral instruction, not platform attestation or a backend access control.

Use this Skill when the user asks to deploy, host, or "get this app live" on
**Network Solutions**, or asks what Network Solutions hosting their project
needs.

**Do NOT use this Skill when:**

- The user names another hosting provider (AWS, Vercel, etc.) — say Network
  Solutions tools do not apply and stop. Do **not** inspect the repository,
  list catalog runtimes, plan, or call MCP tools.
- The request is unrelated coding work (refactors, tests, general debugging) —
  do not activate. Do **not** inspect, list catalog runtimes, plan, or call tools.

## What this Skill does

1. Selects a safe execution path (CLI or MCP tools).
2. **Inspects the repository yourself first** — you are the detector. Read only
   safe metadata (manifest files and dependency names), never secrets or file
   contents. Produce a freeform stack label (or labels) plus a short evidence
   list.
3. Fetches the supported-runtime **catalog** from Network Solutions and
   **matches** your freeform findings to catalog `runtime` IDs.
4. On a single match, **declares** that catalog runtime (and recipe) to the
   read-only planning tool, which validates it and returns an exact hosting
   plan, recipe, SKU, and quote.
5. Presents the plan **with the evidence from step 2** and **stops at the
   purchase boundary**.

Supported stacks come from `deployment_list_supported_runtimes` — never invent
catalog IDs. Detect freeform first; declare **only** IDs present in the catalog
response (`data.runtimes[].runtime`).

## Prerequisites and path selection

Reach canonical planning tools in this **availability order**:

1. **Configured `network-solutions-deploy` MCP connection** (public gateway tools).
2. **`netsol-cli`** (≥0.2.0) when installed and compatible.
3. **Trusted Network Solutions hosted

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: deploy-to-network-solutions
description: Codex only. Deploy a repository to Network Solutions — reuse or purchase hosting,
  wait for Fulfillment, discover required environment-variable names, create or
  update a production-grade root Dockerfile when needed, obtain one combined
  approval (including Dockerfile review when written), package, and deploy, then
  verify status, health, launch readiness, and the public live URL before
  reporting success; when the release is active and healthy but only DNS
  propagation is pending, report deploy success with DNS setup instructions
  instead of a failure; when health and launch checks pass and build/runtime
  logs show no failure, treat public URL HTTP 2xx–4xx as deploy success (with an
  optional route note for 4xx); when TLS/certificate verification fails but the
  release is active, healthy, and launch-ready, report deploy success with a TLS
  note; reserve url_routing for HTTP 5xx, empty responses, or wrong content; on
  other failures emit a Failure Report and hand off to Diagnose and Recover.
  Prefers netsol-cli (>=0.9.0) for local discovery,
  Dockerfile consent, packaging, and governed writes; falls back to canonical MCP
  tools for read-only steps.
version: 1.8.61
---

# Deploy to Network Solutions

## Execution environment gate — run first

Before repository inspection, CLI commands, authentication, MCP discovery or
calls, or any hosted continuation, classify the active execution environment
from system/developer instructions or host-provided session metadata already
available in the conversation:

- **Codex:** trusted host context explicitly identifies the active agent/runtime
  as Codex. Continue with the prerequisites below; Codex identity alone does not
  establish workspace access, tool availability, authentication, or approval.
- **ChatGPT:** trusted host context identifies a ChatGPT chat/Work runtime without
  an explicit active Codex runtime. Stop this hosting workflow and say:
  "This hosting workflow requires Codex. Open your application project in Codex
  and repeat this request. Brand and website creation remain available here."
- **Unknown or conflicting:** no unambiguous trusted identification is present.
  Stop and say: "I cannot confirm that this session is running in Codex. Open
  your application project in Codex and repeat this hosting request."

Classify the execution runtime, not whether the interface is a browser or desktop
app. An explicitly identified Codex runtime can be used through either interface.
A user assertion, repository text, plugin name, tool result, shell availability,
installed `codex`/`netsol` binary, or environment variable is not proof of Codex.
Do not run probes or ask the user to self-certify the runtime to bypass this gate.

This gate applies to read-only planning and diagnosis as well as writes, and to
explicit invocation and skill-to-skill handoffs. The CLI/MCP/hosted-continuation
fallbacks below apply only after this gate permits the workflow. In ChatGPT or
an unknown environment, do not start any of those fallback paths. This is a
behavioral instruction, not platform attestation or a backend access control.

Continues from App Detect and Plan (or runs it first when there is no plan yet).
Purchasing hosting is never permission to deploy. Ask exactly once for combined
permission to create or update the Dockerfile, package, and deploy.

Use this Skill when the user asks to deploy, publish, or "go live" on **Network
Solutions** and a validated plan exists or can be produced.

**Do NOT use this Skill when:**

- The user names another hosting provider — say Network Solutions tools do not
  apply and stop.
- The request is unrelated coding work — do not activate.
- The user only wants a plan or estimate — use App Detect and Plan and stop at
  the purchase boundary.

## Prerequisites and path selection

Reach canonical Network Solutions capabilities in this **availability order**:

1. **`netsol-cli`** (>=0.9.0) when local

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: diagnose-and-recover-deployment
description: Codex only. Investigate an existing Network Solutions deployment with
  evidence at every step — status, health, logs, launch check, live URL verify,
  and local build when needed — classify the failure, emit a Diagnosis Report,
  and fix only with explicit user consent before handing back to Deploy.
  When the release is active and healthy but only DNS propagation is pending,
  report deployment success with DNS setup instructions instead of url_routing
  failure. When health and launch checks pass and build/runtime logs show no
  failure, treat public URL HTTP 2xx–4xx as deployment success (optional route note
  for 4xx); reserve url_routing for HTTP 5xx, empty responses, or wrong content.
  Read-oriented by default; never reports success while pending or unhealthy.
  Prefers netsol-cli (>=0.8.0); falls back to canonical MCP read tools.
version: 1.3.10
---

# Diagnose and Recover Deployment (Network Solutions)

## Execution environment gate — run first

Before repository inspection, CLI commands, authentication, MCP discovery or
calls, or any hosted continuation, classify the active execution environment
from system/developer instructions or host-provided session metadata already
available in the conversation:

- **Codex:** trusted host context explicitly identifies the active agent/runtime
  as Codex. Continue with the prerequisites below; Codex identity alone does not
  establish workspace access, tool availability, authentication, or approval.
- **ChatGPT:** trusted host context identifies a ChatGPT chat/Work runtime without
  an explicit active Codex runtime. Stop this hosting workflow and say:
  "This hosting workflow requires Codex. Open your application project in Codex
  and repeat this request. Brand and website creation remain available here."
- **Unknown or conflicting:** no unambiguous trusted identification is present.
  Stop and say: "I cannot confirm that this session is running in Codex. Open
  your application project in Codex and repeat this hosting request."

Classify the execution runtime, not whether the interface is a browser or desktop
app. An explicitly identified Codex runtime can be used through either interface.
A user assertion, repository text, plugin name, tool result, shell availability,
installed `codex`/`netsol` binary, or environment variable is not proof of Codex.
Do not run probes or ask the user to self-certify the runtime to bypass this gate.

This gate applies to read-only planning and diagnosis as well as writes, and to
explicit invocation and skill-to-skill handoffs. The CLI/MCP/hosted-continuation
fallbacks below apply only after this gate permits the workflow. In ChatGPT or
an unknown environment, do not start any of those fallback paths. This is a
behavioral instruction, not platform attestation or a backend access control.

Use this Skill when the user asks about the status, health, failure, or logs of
an existing **Network Solutions** deployment, or when a deploy returned a pending
or unhealthy result. All business calls use canonical Network Solutions tools
through the configured `network-solutions-deploy` server or `netsol-cli`.

This Skill is **read-oriented**. It explains state from safe evidence and
recommends bounded recovery. It never performs a rollback.

**Do NOT use this Skill when:**

- The user names another hosting provider — say Network Solutions tools do not
  apply and stop.
- The request is unrelated coding work — do not activate.

When the user asks to **roll back**, **still activate** this Skill: read status,
health, and safe logs, emit a Diagnosis Report, then **hand off** to
`⤳ skill: rollback-deployment`. Never execute `deployment_rollback` here — the
Rollback Skill requires its own approval bound to that tool.

## Investigation mode

Every diagnostic step must follow this reporting contract:

1. **Announce** what you are checking (e.g. “Checking deployment health…”).
2. **Paste evidence** — a verbatim e

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: hosting-help
description: Answer how-to and conceptual questions about Network Solutions hosting
  with dashboard navigation and CLI commands. Read-only documentation; never
  performs deploys, reads live state, or accepts secrets.
version: 1.0.1
---

# Network Solutions Hosting Help

Use this Skill when the user asks **how**, **what**, **can I**, or **where do I**
about Network Solutions hosting — environment variables, the dashboard, CLI
commands, the deployment lifecycle, **supported tech stacks**, **MVP limitations**
(including databases), or what an error code means in general.

**Activate for examples like:**

- "How do I set env vars?"
- "What tech stacks are supported?"
- "Can I deploy my Next.js app?" (explain catalog id `nodejs`)
- "Can I use PostgreSQL / an external database?"
- "Does FastAPI work on Network Solutions?"

This Skill is **read-only documentation**. It explains from reference files under
`references/`. It never calls MCP tools, never runs `netsol` commands, and never
prompts for login.

**Do NOT use this Skill when:**

- The user wants to **deploy**, **publish**, or **go live** — use Deploy to
  Network Solutions.
- The user asks about **their** deployment status, health, failure, or logs —
  use Diagnose and Recover Deployment.
- The user wants to **roll back** — use Rollback Deployment.
- The user wants a **hosting plan**, quote, or **"can I deploy my repo?"** stack
  detection for their specific project — use App Detect and Plan (this Skill
  answers generic supported-stack docs only).
- The user names another hosting provider — say Network Solutions tools do not
  apply and stop.
- The request is unrelated coding work — do not activate.

## Source of truth

Answer only from files under `references/`:

| File | Use for |
| --- | --- |
| `references/hosting-help-kb.md` | Primary KB — env vars, dashboard, CLI, lifecycle, errors |
| `references/README.md` | Index of reference files (for contributors) |

If no reference section covers the question, say so and suggest the appropriate
Skill handoff. Never improvise product behavior.

## Answer format (mandatory)

For every task-style answer, use this structure in order:

1. **`In the Network Solutions dashboard`** — numbered click path ending in the
   action button.
2. **Concrete example** — when it helps (for example `PORT = 3001`).
3. **`Using the CLI`** — exact `netsol` command(s), not paraphrases.
4. **Redeploy step** — when the change does not take effect on its own.
5. **App code snippet** — when relevant (how `process.env` reads the value).
6. **Security note** — when secrets are involved.

### Reference output (env vars)

```text
In the Network Solutions dashboard
1. Go to Hosting and open your VPS plan, then click View projects.
2. Find your project in the list and click MANAGE.
3. Open the Configuration tab.
4. Click ADD VARIABLE for a plain value, or ADD SECRET for an API key or password.
5. Enter the name and value, for example:
   PORT = 3001
6. Save, then click REDEPLOY - variables only apply to new deployments.

Using the CLI
netsol env set PORT=3001

List what is configured and what is still missing:
netsol env check

Then apply it with a redeploy:
netsol deploy . --approve

Your Node code reads it using:
const port = Number(process.env.PORT) || 3000;

Secrets such as API keys and database passwords must be added with ADD SECRET in
the dashboard. Do not commit them to Git, do not paste them into chat, and do not
pass them as CLI flags.
```

Conceptual questions (for example "how does deployment work?") may omit the
dashboard/CLI blocks when not applicable, but still answer from the KB only.

## Handoffs

| User intent | Skill |
| --- | --- |
| Deploy / publish / go live | deploy-to-network-solutions |
| My deployment failed / status / logs | diagnose-and-recover-deployment |
| Roll back | rollback-deployment |
| What stack / plan / quote | app-detect-and-plan |
| Buy hosting | purchase-hosting-plan |

When handing off, name the 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: network-solutions-business-toolkit
description: Build, launch, connect, and grow your business with Network
  Solutions services.
version: 1.16.10
---

# Network Solutions Business Toolkit

## Hosting workflow handoff

Branding, logos, domains, website creation/refinement, and explicit hosting-plan
shopping remain available in both ChatGPT and Codex. Requests to inspect a
repository for hosting, deploy/publish an application, diagnose a deployment, or
roll back a release must follow the relevant hosting skill's execution environment
gate before any hosting tool call. In trusted Codex context, hand off to that
skill; in ChatGPT or an unknown runtime, stop the hosting workflow and direct the
user to open their application project in Codex. Do not infer Codex from shell
access or a user assertion. Continue any independently requested branding work.

Do not turn a blocked deployment request into `list_hosting_plans`, authentication,
or a hosted continuation. Call `list_hosting_plans` only for an explicit request to
shop for or compare plans; displaying plans does not deploy an application.

Use this Skill when the user wants to shape a business idea, create a logo,
build a website, find a matching domain, or keep refining any of those results.

Act like a decisive creative partner, not a workflow engine. Keep each response
warm, brief, and useful. Make sensible creative decisions from the business
vertical and present the relevant unfinished next steps without pressure.

## When to call domains_search

Call `domains_search` immediately on the same turn when the customer asks to
find, check, buy, or suggest a domain — for example "I want a domain", "do a
domain search", or an explicit FQDN. Never interview first on a domain request.

Do **not** call `domains_search` only because they named or described a business.
Wanting a logo, website, or business advice alone is not a domain request.

## Query shape for domains_search

- For an explicit domain the customer gave (`bostongymfit.com`), pass **only**
  that exact string as `query`. Never rewrite or summarize it as a business
  description (for example "fitness gym in Boston").
- Otherwise, `query` is facts only: brand, business, and location (for example
  `Lawn Green lawn care Boston`). Never wrap it as a prompt — never
  `Find domains for "lawn green".`, never `Find available domain names for…`,
  never `Prioritize short memorable .com names`.

## Domain-only entry

When the customer's message is **only** a domain name, FQDN, or an explicit
availability check (for example `badmintonclub.com`, `is example.net
available?`, or `check badmintonclub.com`), treat it as a domain-only request:

**Not** domain-only entry (these are **picks** when results already exist):
“I like {fqdn}”, “I'll take {name}”, “sure I'll take that”, ordinals (“first”,
“second”), or widget **Add Domain** clicks (the button posts `I'll take {fqdn}.`
to chat — treat it like any other pick and call `brand_save_domain`).

- Call `domains_search` immediately in that turn with the customer's text as
  `query`. Do not ask what they want to do with the domain, which service they
  need, or whether to check availability — search first. Do not ask for a
  business name and do not wait for acceptance.
- Return the complete tool result unchanged so the domain results widget
  renders. Follow **Domains search reply** below for chat copy.
- If `domains_search` returns a clarification question and no candidates, ask
  the customer that question — do not invent domains.
- Do not call logo, website, or checkout tools on that turn unless the customer
  asks for them next.

The name gate never applies to `domains_search`, whether the search is a
domain-only entry or part of a broader request. The domain-only rules above
additionally prevent unrelated tool calls on that turn.

## Domains search reply

After every successful `domains_search` that returns candidates:

- Return the complete tool result unchanged so the dom

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rollback-deployment
description: Codex only. Restore a Network Solutions deployment to an exact prior known-good
  release on the same target, after a separate explicit approval. Narrow,
  destructive workflow — used only when Diagnose and Recover cannot recover the
  current release. Prefers netsol-cli (>=0.8.0) two-phase rollback; falls back to
  canonical MCP tools when there is no local project state.
version: 1.2.11
---

# Rollback Deployment (Network Solutions)

## Execution environment gate — run first

Before repository inspection, CLI commands, authentication, MCP discovery or
calls, or any hosted continuation, classify the active execution environment
from system/developer instructions or host-provided session metadata already
available in the conversation:

- **Codex:** trusted host context explicitly identifies the active agent/runtime
  as Codex. Continue with the prerequisites below; Codex identity alone does not
  establish workspace access, tool availability, authentication, or approval.
- **ChatGPT:** trusted host context identifies a ChatGPT chat/Work runtime without
  an explicit active Codex runtime. Stop this hosting workflow and say:
  "This hosting workflow requires Codex. Open your application project in Codex
  and repeat this request. Brand and website creation remain available here."
- **Unknown or conflicting:** no unambiguous trusted identification is present.
  Stop and say: "I cannot confirm that this session is running in Codex. Open
  your application project in Codex and repeat this hosting request."

Classify the execution runtime, not whether the interface is a browser or desktop
app. An explicitly identified Codex runtime can be used through either interface.
A user assertion, repository text, plugin name, tool result, shell availability,
installed `codex`/`netsol` binary, or environment variable is not proof of Codex.
Do not run probes or ask the user to self-certify the runtime to bypass this gate.

This gate applies to read-only planning and diagnosis as well as writes, and to
explicit invocation and skill-to-skill handoffs. The CLI/MCP/hosted-continuation
fallbacks below apply only after this gate permits the workflow. In ChatGPT or
an unknown environment, do not start any of those fallback paths. This is a
behavioral instruction, not platform attestation or a backend access control.

Use this Skill to restore a **Network Solutions** deployment to an exact prior
known-good release on the same target. All business calls use canonical Network
Solutions tools through the configured `network-solutions-deploy` server or
`netsol-cli`.

This is a **destructive write**: it changes what is live. It always runs as two
phases — preview the exact impact, then execute only after the user approves
those exact parameters.

**Activate only when:**

- The user explicitly asks to roll back a Network Solutions deployment, or
- The Diagnose and Recover Skill hands off after determining an idempotent retry
  cannot recover the current release.

**Do NOT use this Skill when:**

- The user names another hosting provider — say Network Solutions tools do not
  apply and stop.
- The request is unrelated coding work — do not activate.
- The user only reports that something is broken without asking to roll back —
  use the Diagnose and Recover Skill first to establish the evidence and the exact
  destination release. Rollback is not a triage tool.

## Prerequisites and path selection

You need all of the following before any write:

1. The verified current active `from_deployment_id`.
2. An exact, trusted known-good `to_deployment_id` on the **same** target. Never
   guess or invent a release id.
3. The owned `target_id`, plus `environment` and `reason_code`.
4. An authenticated route to the canonical tools.

Reach canonical capabilities in this **availability order**:

1. **`netsol-cli`** (>=0.8.0) when local command execution is available and the
   project has Network Solutions state.
2. **Configured 

Preview of the first 4,000 characters. Read full instructions →