Autoprompt Skill: a review-and-recheck workflow layer for coding agents
Autoprompt is a coding-agent skill that cuts failures by 45% on agentic coding tasks.
At a glance
- What is it?
- Autoprompt installs a skill into eleven coding agents and wraps each request in a review, fix and recheck loop. Its own README reports 73 of 89 Terminal-Bench 2.1 tasks solved with it versus 60 without, at roughly three times the wall time.
- Who is it for?
- Adopt Autoprompt if you already drive Claude Code, Codex or OpenCode on multi-file work where a wrong edit costs more than a slow run, and you accept the README's own estimate of about three times the time and twice the tokens. Do not adopt it for one-line fixes or latency-sensitive loops, where the same README warns results may differ significantly.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The failure mode Autoprompt targets: agents that stop at the first plausible edit
A coding agent typically writes a patch, declares the task done, and moves on. The patch may compile and still be wrong at the edges: an unhandled branch, a test that was never run, a retry path that was never exercised. Autoprompt is a skill that inserts a second pass between the first patch and the final answer. The README's one-line summary is that it "cuts failures by 45% by reviewing, fixing, and rechecking its work."
The audience is narrow and specific. You need a coding agent that supports skills or subagents, you need a project directory the agent can write to, and you need tasks large enough that a second review pass has something to find. The support table lists eleven working agents, including Claude Code 2.1.263, Codex 0.148.0, OpenCode 1.18.29, VS Code 1.136.1 and Grok Build 1.0.13. Anything else goes through the custom-agent compatibility guide, which means the workflow is only as good as the hook that agent exposes.
If your tasks are single-function edits, the review pass has little to review. The README concedes this directly: "for very small tasks, this may differ significantly."
How the workflow runs: launcher, provider key, and a goal string that carries its own success check
The mechanism is a launcher, not a library. You install a CLI globally, run an interactive installer that writes the skill into a chosen agent, and from then on invoke the workflow through that CLI. The invocation form documented in the README is:
autoprompt activate PROVIDER --target /absolute/project -- "<goal>"
Each part has a defined role. PROVIDER is a key from the support table, such as claude, codex or grok. --target names the project and defaults to the current directory when omitted. The double dash separates launcher options from the request. The quoted goal is where the workflow gets its leverage: the README defines it as "the result you want, constraints, and how to check success." That phrasing matters. The recheck step needs something to check against, so a goal written as a bare instruction gives the reviewer less to work with than one that states the acceptance condition.
An optional path= token sits before the quoted goal and takes auto, direct, light or roadmap, documented in docs/faq/work-paths.md. The README's example is:
autoprompt activate codex -- path=light "add retries and test the edge cases"
Beyond the launcher, the README names subagents as the unit of parallel work, with concurrency controls described below. The repository topics include subagents, multi-agent-systems and test-driven-development, and the README links a docs/faq/which-coding-agents-are-supported.md page for audit notes. What the README does not publish is the internal prompt text or the exact ordering of the review and recheck steps. If you need to inspect the loop before trusting it, you have to read the installed skill files in the repository, not the README.
Installation, the doctor command, and the runtime dependencies you must already have
Installation is three documented steps. First, install the CLI from the release tarball:
npm install -g https://github.com/Spielewoy/autoprompt-skill/releases/download/v2.0.0/autoprompt-skill-2.0.0.tgz
Second, run the installer by typing autoprompt with no arguments. Third, choose your coding agent, confirm the detected path, and install. The README notes that pressing N at the path prompt lets you enter another path, and that unsupported agents should pick "Custom coding agent" and follow docs/guides/custom-agent-compatibility.md. A from-source path also exists: git clone the repository, cd into it, npm install -g ., then autoprompt.
The requirement list is not trivial and is worth reading before you start. Node.js 20 or newer, Python 3.11 or newer available as python3 or python with PyYAML installed, Bash 4.3 or newer on macOS or Linux, and Git only for the GitHub checkout method. The PyYAML dependency is easy to miss on a machine that already has Node. The Bash version floor rules out the default /bin/bash 3.2 that ships with macOS, so you need a Homebrew or otherwise updated shell.
Maintenance commands are explicit. autoprompt doctor --strict checks every detected installation; autoprompt doctor PROVIDER --strict checks one. Updating or repairing means re-running autoprompt and choosing an installed provider. Removal is autoprompt uninstall for the interactive flow or autoprompt uninstall PROVIDER for a single agent. autoprompt help lists everything. The doctor subcommand is the one to run after any agent upgrade, since the support table pins tested versions and a provider that moved past its tested version is outside what the README claims.
The benchmark claim, and the parts of it the README refuses to overstate
The headline number comes from a measured OpenCode comparison on Terminal-Bench 2.1. Per the README, OpenCode 1.18.7 solved 60 of 89 tasks, scoring 67.42 percent with 29 failures. OpenCode with Autoprompt solved 73 of 89, scoring 82.02 percent with 16 failures. That is 13 additional solves, plus 14.61 points, and 45 percent fewer failures.
The README is careful about what that does and does not establish. It labels these as version 1 benchmarks and says version 2 benchmarks will follow, which means the published evidence predates the current v2.0.0 release. It also separates DeepSeek's 82.7 percent result, noting that it used its own test setup and is therefore "a reference point, not a comparable third run." A link to docs/benchmarks/terminal-bench-2.1.md is offered for setup and evidence boundaries, and the README invites requests for another benchmark through a GitHub issue.
The cost side is where the honesty is most visible. The expected trade-off is stated as about three times the time and twice the tokens. In the same collapsed section, the README says timing and token logs were not retained, so those figures are "planning estimates based on user experience reports, not measured benchmark results." Treat the 45 percent failure reduction as measured in one run and the 3x/2x cost as an estimate. Both are the project's own framing, and the distinction is not buried.
Concurrency controls and why tokensaver is the default posture worth understanding
Run controls apply uniformly across all eleven providers, which is a deliberate design choice: the launcher normalizes the interface rather than exposing per-agent flags. Three concurrency settings are documented.
--concurrency tokensaver runs at most six subagents at once. --concurrency wide starts ready, independent work up to the host limit. --concurrency custom --max-subs N sets your own ceiling.
The gap between tokensaver and wide is the gap between predictable spend and maximum throughput, and given the README's own 2x token estimate, that choice is the main cost dial you have. A six-subagent cap bounds how much parallel context is live at once. wide defers to the host, which means your agent's own limits decide the spend. The README does not publish token counts per mode, so the practical way to choose is to run one representative task at each setting and read your provider's usage report.
A separate control appears in the truncated material as configure PROVIDER --agents off, described as using the provider's configuration. The sentence is cut off in the supplied README, so the full effect of --agents off cannot be confirmed here. Verify it with autoprompt help before relying on it in a script.
Where Autoprompt is the wrong tool, and what the README leaves unstated
The clearest limitation is stated by the project itself: small tasks may behave differently, and the 3x time figure is an estimate rather than a log. If your loop is interactive and you judge the agent's first answer yourself, the second pass duplicates work you were about to do anyway.
The second limitation is environmental. The install path requires Node 20+, Python 3.11+ with PyYAML, and Bash 4.3+. A container built for a minimal Node runtime will fail at the Python check, and a stock macOS shell will fail the Bash check. Neither failure is exotic.
The third is version drift. The support table pins tested versions, and the benchmarks are labelled version 1 while the current release is v2.0.0. The README does not present v2 benchmark results. If you are evaluating v2.0.0 on the strength of the 73/89 figure, you are reading evidence from an earlier line, and the project says so.
The fourth is the gap between the launcher and the agent. Autoprompt writes a skill into a third-party agent whose internals it does not control. A provider update that changes how skills or subagents are loaded can break the workflow in ways autoprompt doctor may or may not catch, since doctor checks installation state rather than task behaviour. The README's audit notes page is the place to look for what was actually verified, but the README does not summarize those notes.
Finally, the internal prompt design is not documented in the README. You can see the invocation surface and the concurrency dials, but not the review criteria the skill applies. For a tool whose entire value proposition is review quality, that is a real gap, and it is the first thing to inspect in the repository before adopting.
The alternative: a plain agent loop with your own test command
The obvious alternative is not another skill. It is the unmodified agent plus a test command you run yourself. That is exactly the OpenCode baseline in the README's comparison: 60 of 89 tasks, 67.42 percent, no extra install, no Python or Bash version floors, no token multiplier.
The difference in approach is where the verification lives. Autoprompt moves the success check into the goal string and has the agent perform the review and recheck internally, which is why the README insists the goal state "how to check success." The plain loop keeps verification outside the agent: you write the goal, the agent patches, you run the tests, and you decide whether to send it back. The plain loop costs you attention per task. Autoprompt costs you roughly 3x time and 2x tokens per the project's estimate, and returns a patch that has already been through one review cycle.
Which is better depends on your bottleneck. If your attention is the scarce resource and the tasks are long, the internal review pass is buying back your time. If your tests are fast and your tasks are short, running them yourself is cheaper than paying for a second model pass. The README's own numbers support this reading: the gain appears on an 89-task benchmark of agentic coding work, not on small edits.
Licence, upgrade cost, and what to check before you commit
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive baseline and it is the same licence across the CLI and the installed skill files. This is not legal advice; if you redistribute Autoprompt inside a product, have your own counsel confirm the notice requirements and check whether the bundled assets under assets/ carry separate terms, since the README does not address them.
Upgrade cost is low by design. The release history shows v1.0.3, v1.0.4 and v2.0.0 within about three weeks, and updating is the same interactive command as installing: run autoprompt and choose an installed provider. There is no separate migration step documented, and the skill is written into the agent rather than into your project tree, so a reinstall does not touch your source. The recurring cost is the per-task token multiplier, not the install.
The version cadence is worth weighing. Three releases in under a month means the tested-version table can lag your installed agents quickly, and the benchmark evidence is explicitly version 1. Pin the tarball URL for v2.0.0 if you need reproducibility, and re-run autoprompt doctor --strict after every agent upgrade. If your provider has moved past its tested version in the support table, you are outside the configuration the project claims to have validated.
Editorial conclusion
Adopt Autoprompt if you already drive Claude Code, Codex or OpenCode on multi-file work where a wrong edit costs more than a slow run, and you accept the README's own estimate of about three times the time and twice the tokens. Do not adopt it for one-line fixes or latency-sensitive loops, where the same README warns results may differ significantly. Before committing, run autoprompt doctor --strict against your installed provider, then reproduce the OpenCode comparison on your own task set, because the published numbers are labelled version 1 benchmarks and the timing and token figures were never retained as logs.
Community notes