binaries

Scaffold Forge long-running processes as independently deployed binaries with cobra subcommands.

4|1|Updated Apr 12, 2026
One-click install
npx skills add https://github.com/reliant-labs/forge --skill binaries
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: binaries
Source: https://github.com/reliant-labs/forge/tree/main/internal/templates/project/skills/forge/binaries
Command: npx skills add https://github.com/reliant-labs/forge --skill binaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Forge users need a clear, repeatable way to decide when a long-running process should be scaffolded as a binary (with its own Deployment) instead of a service, worker, or operator.

Core Features & Use Cases

  • Decision guidance: Choose service, worker, binary, or operator based on lifecycle ownership and whether the process needs its own Deployment and scaling.
  • Consistent scaffolding: Generate a binary’s cobra subcommand plus the canonical Deps/Runner lifecycle and starter tests (including ctx cancel start/stop and validateDeps coverage).
  • Deploy integration: Ensure each binary listed in forge.yaml is rendered into a Kubernetes Deployment that runs the cobra subcommand with the correct deploy story and shared defaults.

Quick Start

Ask the AI: scaffold a long-running Kubernetes-ready reverse-proxy process as a Forge binary named "workspace-proxy" and explain how its lifecycle and deployment should work.

Frequently Asked Questions about binaries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
When should I scaffold a long-running process as an independently deployed binary instead of a service?

Scaffold a binary when a long-running process needs its own blast radius, scaling, and deploy lifecycle. This applies to reverse proxies, sidecars, isolated webhook receivers, or tools daemons that should not register Connect RPC handlers with the canonical server.

How do I scaffold a Kubernetes-ready reverse proxy as a Forge binary?

To scaffold a Kubernetes-ready binary, define forge.yaml binaries entries to generate Deployments. Implement Deps with validateDeps plus a Runner.Run(ctx) loop that drains on SIGINT/SIGTERM via context cancellation, wiring the cobra subcommand as a thin adapter that loads config and calls New(deps).Run(ctx).

How does the cobra CLI handle process lifecycle and graceful shutdown for deployed binaries?

The cobra CLI handles process lifecycle by acting as a thin adapter that loads config and calls New(deps).Run(ctx). The Runner.Run(ctx) loop drains on SIGINT/SIGTERM via context cancellation, ensuring the independently deployed binary shuts down gracefully.

Can I use forge.yaml to generate Kubernetes Deployments for off-service consumers and sidecars?

Yes, forge.yaml binaries entries render into Kubernetes Deployments that run the cobra subcommand with the correct deploy story and shared defaults, specifically supporting off-service consumers, sidecars, and isolated webhook receivers that need independent scaling.

What is the difference between a Forge binary and a Forge worker or operator?

A Forge binary is chosen when a process needs its own Deployment and deploy lifecycle without registering Connect RPC handlers. Workers and operators are alternative shapes selected based on lifecycle ownership and specific scaling requirements within the Forge ecosystem.