cli

apic turns any HTTP API into a command line tool: it reads the API definition (OpenAPI / Swagger, or a few lines of YAML) and builds one command per endpoint, with parameters as options and shell completion.

• Definitions become commands: a service with an OpenAPI document is one site add away; for an internal service without one, list its endpoints in a few lines of YAML. apic link also gives a site its own command, such as petctl.
• Environments and authentication: separate base URLs and credentials for dev and prod; bearer, basic, apikey, log-in-for-a-token and token-from-a-command auth; writes to production need --yes.
• Picking, paging, formatting: --pick takes fields from any level and renames them, --all-pages walks and merges the pages, -o table / yaml makes the result readable.
• For people and AI agents: stdout carries only the response body, exit codes have fixed meanings, and apic skill writes a SKILL.md for agents. Secrets are masked in -v, --dry-run and error messages.

…

Keep an agent in one session long enough and three things go wrong. The context fills up and gets compacted, and the part that gets dropped is the constraint you gave it in the first turn. Every request carries a few thousand tokens of fixed overhead, so long sessions get expensive. And when something breaks, there is no record of what the agent did.

suga is a personal coding agent I write in Go. The goal is a session that can stay with me for a full working day. This post covers the trade-offs it makes for long sessions, which of them are backed by data and which experiments failed, and how it works with gofer, my job platform. suga itself is built on gofer, one batch of agent jobs at a time.

The current version is v0.49. It is v0, so minor releases may break things. It is MIT licensed. What follows is an introduction to suga.

…

The last post about miglite covered v0.4.0 in June. In the three months since then, it reached v0.8.0 through four releases and 69 commits (v0.4.0..v0.8.0). The main problem I wanted to solve was carrying a migrations/ directory alongside the binary. A few flags that were accepted but did nothing also needed fixing.

…

Many CLI tools start with a parser, a few commands, and some fmt.Println calls. That works until the tool needs readable config output, clear errors, prompts, progress bars, and logs that do not break in CI.

github.com/gookit/cliui is for that middle ground: not a full-screen TUI, but more than loose terminal prints. It splits the common pieces into three packages: show for structured output, interact for prompts and selections, and progress for long-running work.

…

The pace of command-line tooling has changed. New tools show up on GitHub every day, and active projects may publish several releases in a week, sometimes in a day.

The slow part is often not the project itself. It is the central package index in the middle: a formula, bucket, manifest, or package definition that has not caught up yet. eget is for that gap. If the release asset already exists, or the download URL can be described by a simple rule, eget can fetch and install it directly.

…

GCli v3.8 is out. Since v3.5, the project has added friendlier argument parsing, richer struct binding, type-safe generic flag helpers, inherited command options, and built-in markdown/man-page generation.

If you maintain a nested CLI rather than a small command wrapper, this release is worth a closer look.

…

GCli is a command-line application and tool library for Go. This post covers the main changes from v3.3.1 to the recently released v3.5, including the v3.4 cycle.

These updates focus on developer experience and underlying stability. If you write CLI tools in Go, a few of these features are worth upgrading for.

…