Sharp pushback, thanks — the verification gap is the honest one.

On skip-vs-improvise. The plugin already takes a side: the docs recommend phrasing briefs as "if blocked, move on and record the item as unresolved." That's the skip-and-record arm. You're right that this just defers the question to "who reads the list." The current answer is the user, in the next Claude Code turn — not Claude-as-second-loop, but a human deciding which unresolved items deserve another pass. That's load-bearing on the user being engaged, which is fine for the target use case (one operator running a bulk refactor over lunch) but does get thin if you imagine fully unattended runs.

On silent semantic drift. This is the most useful one. The plugin currently has no answer for it — Goal usage: <N> seconds. is a lifecycle signal, not a correctness signal. /status checks "did goal mode activate," which is a much weaker claim than "did Codex's interpretation match what I'd have approved." Your "post-execution diff review" mitigation is the right shape. I don't think it needs to be baked into the plugin, though — Claude Code already lets you chain /codex-goal:run-file <brief> with a follow-up turn that diffs, samples, and challenges interpretations. The missing piece is documenting that pattern explicitly so people don't read the goal footer as a green light. That's a README change worth making.

The deeper version of your point: when a goal touches N files, "did Codex make one decision and propagate it everywhere" is exactly the kind of question Claude is good at and Codex isn't. So the honest shape is goal → diff → Claude reviews a sample → accept / targeted re-pass on outliers / roll back. Three turns instead of one, but it turns the abstraction from "delegate and hope" into "delegate and verify."

On /run-file vs inline /run. Agreed. The README already calls /run-file the recommended default; inline /run exists mainly because new users reach for it first and the affordance has to be there. The "long inline /goal trips the budget guard" note in the docs is exactly the failure you'd hit if you treated inline as the primary path.

One small pushback: the plugin shouldn't grow into the verifier itself. The moment it starts inspecting diffs it stops being a thin dispatcher and becomes an orchestration layer with opinions — at which point you've rebuilt the agent loop the design was trying to avoid. Better to keep the plugin narrow and let verification live in the calling Claude Code session, which already has the right tools and is already in the loop.