autoprompt-skill

Autoprompt is a coding-agent workflow that cuts failures by 45% by reviewing, fixing, and rechecking its work.

English | 中文 | 한국어 | Español | العربية

Contents

Install · Benchmarks · Invocation · Run controls · Workflow · Agents · Examples · FAQ · License

Install

Use the CLI below, or download an installer from GitHub Releases.

1. Install the CLI

npm install -g https://github.com/Spielewoy/autoprompt-skill/releases/download/v2.1.0/autoprompt-skill-2.1.0.tgz

2. Launch the installer

autoprompt

3. Install

Choose your coding agent, confirm its path, and install. N means enter another path.

For another CLI or IDE, choose Custom coding agent and use the compatibility guide.

Install from source

git clone https://github.com/Spielewoy/autoprompt-skill
cd autoprompt-skill
npm install -g .
autoprompt

Requirements

• Node.js 20+
• Python 3.11+ available as python3 or python, with PyYAML
• Bash 4.3+ on macOS or Linux
• Windows native provider commands use the installed provider runtime plus the platform sandbox and owned-process controls; WSL and a hypervisor are not required for native paths
• Native Windows Codex additionally requires an administrator-run Autoprompt controller and an initialized official Codex Windows sandbox. Setting Codex windows.sandbox="elevated" selects that sandbox mode; it does not elevate the Autoprompt controller.
• Git only for the GitHub checkout method

Support

Status	Coding agent	Tested version	Key
Working	Claude Code	2.1.263	claude
Working	Codex	0.148.0	codex
Working	OpenCode	1.18.29	opencode
Working	Kilo Code	7.5.15	kilo
Working	VS Code	1.136.1	vscode
Working	Prime Agent	0.7.2	prime
Working	Oh My Pi	18.1.14	omp
Working	DeepSeek Harness	0.1.2-rc.1	deepseek
Working	Reasonix	1.30.0	reasonix
Working	Hermes Agent	0.21.1	hermes
Working	Grok Build	1.0.13	grok

These versions passed Linux runs. Model and platform availability varies by provider.

Native Windows execution uses AppContainer isolation and Windows Job process ownership, with Node 20 or 24 on x64 or ARM64. Native macOS execution uses the system sandbox and owned-process controls. Windows command tools include the bundled Bash/MSYS/Node runtime; native paths do not require WSL or a VM.

The ten non-Codex providers can run their local capability checks on Linux, Windows, and macOS. All eleven checks must pass for the installed runtime before a mission starts; missing, failed, or skipped checks block activation. Codex uses its separate canonical validation route. On Windows, that route creates a fresh offline account and an own-SID Windows Filtering Platform policy for each activation. Their activation-bound lease is retained for resume. Permanent cleanup removes the account and policy only after owned Jobs drain; uncertain verification or cleanup fails closed and retains recovery records. The Linux version table above does not certify every provider/platform combination. Installer success and doctor --strict are prerequisite checks; local-canary-required means native validation is still pending. See configured Linux runtimes when a native path is unavailable.

See support and audit notes.

Check, update, or remove an installation

• Check every detected installation: autoprompt doctor --strict
• Check one provider: autoprompt doctor PROVIDER --strict
• Update or repair: autoprompt, then choose an installed provider
• Uninstall interactively: autoprompt uninstall
• Uninstall one provider: autoprompt uninstall PROVIDER
• Show every command: autoprompt help

Replace PROVIDER with a key from the support table, such as claude, codex, or prime.

Benchmarks

These are version 1 benchmarks. Version 2 benchmarks will follow.

Measured OpenCode comparison

Track	Solved	Score	Failed
OpenCode	60/89	67.42%	29
OpenCode + Autoprompt	73/89	82.02%	16
Change	+13 solves	+14.61 points	45% fewer

DeepSeek's 82.7% used its own test setup, so it is a reference point, not a comparable third run. Read the setup and evidence boundaries, or request another benchmark.

Expected trade-off: about 3x the time and 2x the tokens.

Timing and token logs were not retained, so these are planning estimates based on user experience reports, not measured benchmark results. The measured result was 29 to 16 failures (45% fewer) in this run, which translates to about 2x fewer mistakes. Note: for very small tasks, this may differ significantly.

Anatomy of an invocation

autoprompt activate PROVIDER --target /absolute/project -- "<goal>"

Part	What it does