100xprompt writes code, edits it, and verifies it. You describe the change in plain language; 100xprompt creates the new files, edits the existing ones, and coordinates the change across your codebase. Every change lands as a diff you review first. Approve what you want, reject what you don’t, and roll back anything with one command. This page covers:

​
How editing works

Editing follows one safe loop. 100xprompt proposes a change, you see exactly what it will do, sensitive actions pause for your approval, and the result is verified before the loop continues. If anything looks off, one command puts it all back.
You never have to memorize this flow. 100xprompt drives it for you - the point is that every edit passes through a review-and-verify gate, so surprises are rare and reversible.

​
What you can do

Create new files

Scaffold new modules, components, tests, or config files - complete and ready to run, placed where they belong in your project.

Make precise edits

Change exactly the lines that need changing. Surrounding code, formatting, and style are preserved.

Refactor across files

Rename symbols, move logic, and update every call site in one coordinated pass - not one file at a time.

Review before it lands

See a clean, color-coded diff of every change before you accept it.

Verify automatically

After editing, 100xprompt surfaces new errors and warnings so problems are caught immediately.

Roll back instantly

Undo the last change - including the files it touched - with a single command, then redo if you change your mind.

​
Create new files

Suppose you need a new piece of your service to exist. Ask for it and 100xprompt writes the whole thing, not a stub. Tell it the goal and it decides the right location, fills in the boilerplate your project already uses, and wires it into the surrounding code. 
Add a rate limiter middleware for the API, with a test.
100xprompt creates the middleware file and its test, matching your existing folder conventions and import style - then shows you both as new-file diffs before anything is written to disk.
The more context 100xprompt has, the better the fit. Point it at an existing file (“follow the pattern in the auth middleware”) and new files will match your conventions closely.

​
Make precise edits

For changes to existing files, 100xprompt performs targeted edits rather than rewriting whole files. It locates the exact region to change and modifies only that, leaving everything else - comments, unrelated code, and formatting - untouched. This keeps diffs small, readable, and easy to trust.
Edit styleWhat it’s for
Single targeted editFix a bug, tweak a value, adjust one function
Multiple edits in a fileSeveral related changes to the same file at once
Whole-file rewriteReserved for when the change is genuinely file-wide
New fileScaffolding something that doesn’t exist yet
Precise edits mean the diff you review shows only what actually changed - no noise from reformatting, no accidental churn in code you didn’t ask to touch.

​
Review diffs

Every proposed change appears as an inline diff in your session: additions and removals are color-coded, grouped by file, and shown in context. You read exactly what 100xprompt is about to do before it happens - or, for changes already applied, exactly what it did.
  • Grouped by file - multi-file changes are laid out file by file so nothing hides.
  • In context - surrounding lines are shown so each edit is easy to judge.
  • Readable long lines - toggle diff word-wrapping so wide changes stay legible.

​
Approve and reject changes

100xprompt asks before it does anything sensitive - including writing to files that fall outside what you’ve already allowed. When it pauses, you choose:

Allow once

Let this specific change through, just this time.

Allow always

Trust this kind of change going forward so you’re not asked again.

Reject

Decline the change and tell 100xprompt what to do instead.
You decide how much to be asked. Tighten or relax these prompts per project or globally so routine edits flow while risky ones always stop for a check. See Permissions for the full model.
“Allow always” is powerful and persistent. Grant it for edit types you genuinely trust in a given project - and keep prompts on for anything that touches files outside your work area.

​
Verify edits

An edit isn’t done just because it was written. After a change, 100xprompt checks the result and surfaces new problems - type errors, broken references, and warnings - right in the session. If a change introduces an error, you’ll see it immediately, and 100xprompt will typically fix it in the same loop rather than leaving you to discover it later.
This closes the loop: edit → review → verify. Instead of finding out at build time that a change broke something, you find out the moment it lands - while context is fresh.

​
Revert and roll back

Because 100xprompt tracks the state of your files around each change, you’re never stuck with an edit you don’t want.
CommandWhat it does
/undoReverts the last message and any file changes 100xprompt made with it
/redoRestores changes you previously undid
Run /undo and both the conversation step and the files it modified are rolled back together - no manual cleanup, no half-applied changes. Changed your mind? /redo brings it right back.
Undo operates on the change 100xprompt made, so your own edits and version-control history stay intact. It’s a fast safety net for iterating, not a replacement for committing work you want to keep.

​
Run a multi-file refactor

Suppose you need to rename a widely used function and update every call site. Here’s what that looks like end to end.
1

Describe the refactor

Tell 100xprompt the goal in plain language:
Rename getUser to fetchUser everywhere and update all call sites.
2

Let it map the impact

100xprompt finds every place the symbol is used - the definition, the imports, and each call site - so the change is complete, not partial.
3

Watch it edit across files

Each affected file gets a precise, targeted edit. Unrelated code stays exactly as it was.
4

Review the diffs

A per-file diff shows every change together. Scan it, and reject or refine anything you don’t like before it lands.
5

Confirm it verifies the result

After applying, 100xprompt surfaces any new errors - a missed reference, a broken import - and corrects them in the same pass.
6

Accept or roll back

Happy with it? You’re done. Want to reconsider? /undo reverts the entire refactor - every file - in one step.

​
Best practices

“Extract the validation logic into its own function and add a test for the empty-input case” produces a tighter, more reviewable change than “clean this up.” Clear intent yields clear diffs.
Referencing an existing file (“follow the pattern in the orders module”) makes new and edited code fit your conventions, so there’s less to correct in review.
The diff is your control point. For wide changes, read it file by file; toggle diff wrapping if long lines are hard to scan.
Let routine edits flow, but keep the approval gate for changes that reach configuration, secrets, or files outside your working area.
Don’t over-plan the perfect prompt. Try a direction, review the result, and /undo if it’s not right. Fast, reversible iteration beats one big careful attempt.

Running Commands

Verify edits: how 100xprompt runs builds, tests, and scripts to prove its own work.

Codebase Understanding

Land edits in the right place: how it reads and maps your project first.

Permissions

Stay in control: set exactly when 100xprompt asks before writing.