About gateway-setup
gateway-setup is a skill for planning, configuring, and verifying a gateway in the requested environment. It emphasizes working with the existing service owner and its contracts rather than installing duplicate transport or monitoring processes.
Key features
- 01Inspect existing gateway ownership
- 02Infer scope and clarify key decisions
- 03Use current installer and live help
- 04Preserve gateway and queue contracts
- 05Verify readiness and event correlation
Use cases
- 01Planning a gateway deployment
- 02Repairing an existing gateway setup
- 03Verifying gateway readiness after changes
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ joelhooks/ joelclaw --skill gateway-setupAfter installing, type/gateway-setupin Claude Code to confirm it loaded.
Bundled filesagents/openai.yamlassets/small-logo.svg
Details
From the project READMEGateway setup
Start with the requested environment and current source. Read gateway and the existing service ownership configuration before installing anything. A fleet with an existing gateway needs repair or configuration of that owner, not another gateway.
Infer supplied scope choices from the request. Ask only for missing decisions that change the intended transport, host, or authority. A plan request produces a plan; an explicit setup request authorizes its scoped implementation.
Use the current repository installer and live help. Keep the gateway policy, durable inbound queue, and channel adapters behind their established contracts. Never create a second poller, socket listener, gateway session, standalone adapter process, or monitoring daemon to work around an unhealthy owner.
Discover current endpoint and model configuration. Do not install historical hostnames, tmux recipes, embedded agents, or model pins from an old example. Verify credentials through the owning secret mechanism without reading them into logs or source files.
Verify readiness, event correlation, and supported health checks. Use synthetic or task-owned fixtures for fault tests. Do not interrupt shared transport or heartbeat processes as routine setup verification. A real outbound canary needs authorization for its destination and content.
Report what was installed or changed, the actual owner and readiness evidence, and unresolved failures. Preserve existing configuration and unrelated work.