100xprompt runs commands in your project, in your shell - then reads the output and uses what it learns to decide what to do next. That’s what turns it from a code generator into an engineer that can prove its work: it doesn’t suggest a command and hope, it runs it and reads the result. Ask it to fix a failing test and it will run the suite, see the red, patch the code, and run the suite again to confirm the green - all without leaving the conversation. This page covers:

​
What you can run

100xprompt drives real terminal commands the same way you would: tests, builds, linters, formatters, type-checkers, package managers, git, gh, Docker, and your own project scripts.

Tests & builds

Run your test suite, build the project, and read pass/fail output to know exactly what broke.

Lint & format

Run linters, formatters, and type-checkers, then fix what they flag.

Version control

Inspect status and diffs, stage files, commit, and open pull requests with git and gh.

Tooling & scripts

Install dependencies, run your own scripts, invoke Docker, and drive project-specific CLIs.

​
The run → observe → act loop

The reason command execution matters is that it closes the loop. 100xprompt doesn’t hand you a change and walk away - it runs the change, observes the result, and keeps going until reality matches the goal.
Because it reads command output, 100xprompt can tell the difference between “I think this works” and “I ran it and it works.” When a command fails, the error message becomes the next input - it diagnoses the actual failure instead of guessing.

​
Verify its own work

Suppose you ask 100xprompt to fix a failing test. Running commands is how it checks itself - after editing code, it will typically:
1

Reproduce the problem

Run the failing test or build so it can see the exact error, not just a description of it.
npm test -- auth.spec.ts
2

Make the fix

Edit the relevant code based on what the output revealed.
3

Re-run to confirm

Run the same command again. Green output is proof the fix landed; red output means it iterates.
npm test -- auth.spec.ts
4

Run the broader check

Widen the net - full suite, linter, type-check - to confirm the fix didn’t break anything else.
npm test && npm run lint
This is the difference that matters: 100xprompt reports “done” only after a command it ran actually confirms it, so you spend less time re-verifying its work by hand.
Tips:
  • Name your verification commands up front. “Run npm test and npm run lint before you tell me you’re done” holds 100xprompt to that bar for the whole session.
  • Point it at the narrow test first. Reproducing one failing test is faster to iterate on than the full suite; widen only to confirm nothing else broke.
  • Flag slow suites. If a check takes longer than two minutes, say so - 100xprompt can allow enough time instead of cutting the run short.

​
Long-running and background commands

Some commands are quick; others - a full build, a watch process, a dev server, a long test matrix - are not. 100xprompt handles both.
SituationBehavior
Short commandRuns, waits for it to finish, reads the full output.
Slow commandWaits up to the timeout, streaming output as it arrives.
Never-ending process (dev server, watcher)Can be sent to the background so the conversation keeps moving while it runs.
Background taskKeeps running; 100xprompt can check its status and read its captured output later.
When a command is running longer than expected, you can send it to the background rather than cancel it. The process keeps going, its output is still captured, and 100xprompt can come back to check whether it succeeded and read what it produced - useful for kicking off a build or server and continuing to work in parallel.
Background execution is a first-class part of how 100xprompt parallelizes work. For the full model - starting, monitoring, and collecting results from background work - see Background Tasks.

​
Timeouts

Every command runs under a timeout so nothing hangs your session indefinitely.
  • Default: commands time out after 2 minutes if they haven’t finished.
  • Per-command: 100xprompt can set a longer timeout for a command it knows will take a while (like a large build or a slow integration suite).
  • Interactive commands are avoided: anything that would sit and wait for keyboard input (editors, pagers, interactive prompts) isn’t run this way - it would only hang. When input is genuinely needed, 100xprompt asks you directly.
If a command legitimately needs more than the default two minutes, tell 100xprompt up front (for example, “the e2e suite takes about five minutes”). It can then allow enough time instead of cutting the run short.

​
Stay in control of what runs

Running commands in your environment is powerful, so 100xprompt is deliberately conservative about it. You stay in control of what executes.
It asks before running. By default, 100xprompt requests your approval before executing a command. You can approve a single command, or set rules that pre-approve trusted commands so routine work (like your test command) doesn’t prompt every time. It respects your permissions. You decide what 100xprompt is allowed to do. In a read-only posture it can inspect and run safe checks but won’t modify your workspace; in a fuller posture it can build, write, and push. These rules are yours to set - see Permissions. It runs in a sandbox. Command execution can be confined to a defined access level - from read-only, to write-access-within-your-workspace, to full access - with network access as a separate toggle. This keeps commands scoped to what you intended. It follows a git safety protocol. 100xprompt won’t change your git config, won’t run destructive commands like force-pushes or hard resets unless you explicitly ask, and only commits when you tell it to.
Approve commands the way you’d review a teammate’s PR - read what it’s about to run. Pre-approving broad patterns is convenient, but reserve it for commands you fully trust, and keep destructive operations behind an explicit ask.
Working in a repo you don’t fully trust? Keep 100xprompt in a read-only or workspace-write posture. It can still run tests and read results to help you understand the code, without the ability to reach outside your project.

Permissions

Set the guardrails: which commands run automatically and which need approval.

Background Tasks

Keep working in parallel: run builds, servers, and long jobs in the background.

Code Editing

From failure to fix: how the errors commands reveal get written to your files.