When a project's config inherits yours
Two configs for one tool, the user's and the project's, and no rule anywhere about which one wins. Twenty minutes to make one a layer of the other and keep a straight answer about where every value came from.

Two configs for one tool, the user's and the project's, and no rule anywhere about which one wins. Twenty minutes to make one a layer of the other and keep a straight answer about where every value came from.

go/mcp puts a Go CLI, HTTP service or gRPC service on the Model Context Protocol with three discovery tools instead of one per command, so a model carries a lantern rather than the whole catalogue.

Four places a config value can come from, and the only question that matters at the wrong end of an incident: which one won, and why. Twenty minutes, one module, no services.

Fifteen minutes, no API keys, nothing to pay for, and a real mp4 at the end of it. The cheapest way to find out whether keryx does what you think.

Twenty minutes from a folder of frames to an album-ready export, with nothing written over an original. Also: the install method that will cost you an evening if you pick the obvious one.

A change that ships without a version bump reaches nobody, and nothing tells you. Ten minutes in a throwaway directory to see it happen, and then catch it.

Launching sigillum, a standalone artefact signing and verification CLI, and the Rust signing problem that made it necessary.

A Rust scaffolder with an AI codegen path that drafts a real command, then refuses to hand it over until it compiles and passes lint.

Reviewing a scaffolder turned up a command name that quietly conflated two different things. A flag and a setting are not the same object.

An audit found that a Cobra option had never been enabled, so the root command hooks had silently not run on any subcommand for months.
