Overview
CLI-Anything frames agent access to human-oriented software as a semantic boundary, not a command list or imitation. The series traces how source analysis becomes a discoverable CLI with structured help, inspectable state, persistent sessions, native or intermediate representations, real-backend execution, layered tests, and preview feedback. Its central test is whether an agent's intent reaches the actual software and returns evidence that can be checked and used for the next decision. The approach fits targets with a workable data model, dependable execution path, and observable outputs; where those conditions or coverage are limited, the capability should be narrowed rather than presented as complete.
Learning outcomes
- Agent-native access requires discovery, inspectable state, faithful backend execution, and verification in one loop.
- JSON and a successful exit code make results parseable, but do not prove that the target software produced the intended artifact.
- Native or carefully tested intermediate representations can preserve meaning; silent fallbacks weaken the evidence boundary.
- CLI-Anything is strongest when the target has a workable semantic seam and claims stay within tested workflow scope.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
What makes a CLI agent-native?
A CLI is agent-native when an agent can discover it, inspect and change meaningful target state, reach the real backend, and verify the result.
Why isn't valid JSON proof that CLI-Anything worked?
Valid JSON proves that a response is parseable, not that the target backend interpreted the state correctly or produced the requested artifact. Output checks are still needed.
When is CLI-Anything a good fit?
CLI-Anything is a good fit when the target exposes a workable data model or semantic interface, its backend can run in the intended environment, and outputs are observable enough to test. Otherwise the harness should support a narrower claim.
How do Shotcut and Blender preserve the same boundary?
Shotcut and Blender preserve the same boundary through different representations: Shotcut uses native MLT XML with `melt`, while Blender uses JSON to generate `bpy` scripts executed by Blender. Both expose agent-friendly state but leave target-specific semantics to the real engine.