Posting from the terminal, and why exit codes matter
A CLI for social posting sounds like a novelty until you want a deploy script to announce itself and fail loudly when it does not.
Optional — the post reads fine without one.
Most social tools assume a person with a browser. That assumption breaks the moment you want posting to be a step in something else — a release script, a nightly job, an agent that can run commands but does not speak any particular protocol.
A command-line interface is the lowest common denominator that everything can reach.
Exit codes are the whole point
A CLI that always exits 0 is decoration. Ours exits 1 when any network failed, which means this works and means something:
attentionpilot post “Nightly build is green.” --to bluesky --now || alert
That is the difference between a tool you can put in a pipeline and one you have to watch.
Never prompt where nobody can answer
Publishing immediately asks for confirmation, because publishing is public and irreversible. But a confirmation prompt in a cron job is a hang, not a safeguard — the job waits forever for a keystroke that will never come.
So the prompt appears only when there is a terminal attached. In a script it is skipped, and the confirmation you actually want there is the exit code afterwards.
No dependencies, on purpose
Every dependency is time on first run and a thing that can break later. Ours has none — it is Node built-ins only, so it starts in about a second and there is no install step to fail in someone’s CI.
It is also the reason an agent can shell out to it without waiting on a package manager.
Make the errors legible
A CLI error is read by a person in a hurry, or a model deciding what to do next. Both want the same thing: what went wrong, and what to do about it.
An over-length caption prints the network, the handle, the length and the limit, and says plainly that nothing was scheduled. “HTTP 422” would be technically accurate and useless to both audiences.