The worker commits before the documented scope check
shadcn/improve's execution reference tells the worker to commit its changes, then tells the advisor to check scope with a bare git diff --stat. Those instructions leave a concrete review gap: a clean working tree can contain committed changes that the bare diff does not show. Before treating an execution approval as evidence that scope was respected, compare the worker's final commit with its starting point.
That concern affects the execution handoff, while the planning idea remains useful. Improve asks an advisor agent to inspect a codebase, identify changes worth making and write portable Markdown plans. You choose the findings that become work. A developer who wants to understand and approve the proposed change before code moves has a clear reason to try that workflow.
What happened when we ran it
We did not run shadcn/improve: our November 11, 2026 lab record for commit cac56e1 found no supported ecosystem, recorded language as null and found no Dockerfile. There is no install duration, passing suite or completed agent task to report. This result describes a mismatch with our automated runner's supported paths, without establishing that the skill fails in an agent host.
The distinction matters because the product is a set of agent instructions. Its useful output would be a plan that survives another session and leads to a correct, bounded change. Repository language detection cannot evaluate that. Neither can reading an example establish that a different model will follow it. Our judgment here rests on public instructions and a specific reported review weakness, with execution quality still unmeasured.
A plan can carry the context another session lacks
The README's handoff format calls for exact file paths, current code excerpts and commands with expected results. It also calls for scope boundaries, stop conditions and a recorded Git commit for checking drift. Those requirements address a common handoff problem: the executor may have none of the conversation that made the advisor's recommendation sound reasonable.
For the maintainer, the useful question is whether the plan carries enough evidence to challenge it. A path points you to the code. A command makes a completion claim inspectable. A stop condition tells the executor when an assumption has failed. These are good properties to request, although our review contains no evaluation showing that generated plans consistently satisfy them.
The documented audit covers several categories and has a vetting stage before findings reach you. The advisor is supposed to reread cited locations and reject false positives. I would still start with one problem whose consequences you understand. If its evidence does not survive your own inspection, distributing that finding to an executor only adds another handoff to repair.
Issue #30 concerns committed executor changes
Issue #30 reports the same scope problem in the single-plan execution path. The reporter describes committing a file outside the permitted scope and then seeing empty working-tree diff and status output. We did not reproduce that example. Reading the pinned instructions does confirm the relevant sequence: the worker is told to commit, and the advisor's scope check uses an unqualified diff.
The proposed correction is understandable: record the executor's starting commit and inspect the changes through its final HEAD. Check remaining working-tree changes separately. This is a review recommendation based on the instructions and report, not a shipped fix or a tested patch. A plan can specify excellent boundaries while its review procedure fails to inspect the changes that crossed them.
Host capabilities decide how delegation works
The README supports agents using the Agent Skills format, while the execution reference names a general-purpose subagent, worktree isolation and a default executor model. Those are instructions for the host to interpret. They do not establish that every compatible host exposes identical delegation controls. Confirm that your chosen environment can isolate work and select the executor you intend to pay for.
The headline economics also remain unmeasured. Improve proposes using a more capable advisor and a cheaper executor, but no billing comparison accompanies our evidence. Planning, execution and revision all consume model work. Judge a trial by the quality of the accepted change and the actual usage record, rather than assuming the word "cheaper" in a dispatch instruction settles the total cost.
Specifications may be the better starting point
GitHub Spec Kit provides structured processes and reusable templates for coding agents, with separate entry points for feature work, bug fixing and idea assessment. Evaluate it when the process itself needs to be shared and adapted. Improve is more directly pitched at inspecting existing code and deciding which findings deserve plans. We have no comparative task result establishing a winner.
OpenSpec demonstrates a workflow with proposal, specification, design and task documents, followed by applying and archiving a change. Choose that direction when explicit requirements and a change record are the main need. Both alternatives still leave you responsible for checking whether the code satisfies the written intent.
The last repository push was September 12, 2026; issue #30 shows discussion activity on November 11. Neither an absent latest-release response nor that gap between dates proves abandonment. Our documentation rating is 4/5 on an editorial scale where 1 means a documented major obstacle, 3 a usable path with caveats and 5 independent validation across the assessed task. Setup, community and maturity remain unassessed. Try one plan, inspect its evidence, and review the committed diff before accepting the executor's work.