Editing your app in chat and code

There are three ways to change a Vorx app: ask in chat, point at it in the preview, or open the code. Most of the time chat is all you need. The other two exist for the moments when a sentence is the wrong tool.

Editing in chat

Chat is the primary way to build. You describe the change in plain English, Vorx applies it, and the preview updates so you can confirm.

It handles a wide range of edits:

• Content and copy — "Rename the Dashboard tab to Overview."
• Layout — "Put the summary cards in a single row across the top."
• Data model — "Add a due date field to tasks."
• Behaviour — "When an order is marked shipped, hide it from the open list."
• Style — "Use a warmer palette and larger headings."

The skill is describing the outcome. Say what should be true after the change, and keep each request to one thing so it's easy to verify.

Being specific gets better results

Vague asks get vague results. When a change matters, name the screen, the field and the exact wording.

Compare a loose request:

Make the form better.

with a precise one:

On the new-customer form, mark email as required, add a phone field, and put the Save button at the bottom right.

The second gives Vorx everything it needs to land the change on the first pass, which keeps your loop moving.

Pointing instead of describing

Some changes are easier to point at than to describe — this heading, that one button of four on the page. Switch the preview to visual mode, click the element, and say what you want: make this bigger, change this text to Get started, add more space below this.

Because the target is exact, the edit is exact. You never have to explain which button you meant. Visual edits are best for copy on a label, spacing and size, or emphasis on a single element. For anything touching data, routing or several screens, plain chat is faster — pointing at one button is a poor way to ask for a new page.

Editing the code directly

Underneath, a Vorx app is a real, conventional codebase, and you can open and edit it. Reach for code when:

• You want one precise value rather than a whole section.
• The change is a rule that's fiddly to phrase but trivial to write.
• You're reading exactly what Vorx built before you publish.

You don't have to pick a mode and stay there. Many people describe the bulk of the app in chat and drop into code for the last few details. When you want the code out of Vorx entirely, connect a repository under Settings → GitHub and take it.

They all land in the same place

Chat edits, visual edits and your own code changes operate on the same app and all become checkpoints in the same history. So you can move between them freely, and roll any of them back the same way.

A common rhythm looks like this:

• Chat to create screens, data and the overall shape.
• Click through the preview to find what's off.
• Point at the small stuff; drop into code for a precise fix.
• Back to chat for the next feature.

When an edit doesn't land

If a change didn't do what you expected, don't pile another request on top of it. Roll back to the checkpoint before it and describe the outcome differently — rollback is free, and re-running from solid ground beats stacking corrections.

If something is actually broken rather than just wrong, open Settings → Dev Logs, copy the error, and paste it into chat with what you expected to happen. Vorx reads the error and fixes the cause instead of guessing from a description of the symptom.

Tips for smooth editing

• One change at a time. Small requests are easy to confirm and easy to undo.
• Lead with the goal. Describe what should be true, not the steps to get there.
• Check the preview after each edit. Confirming as you go beats a long list of unverified changes.
• Chat for pace, pointing for precision, code for control.

To see how editing fits the wider workflow, read the build loop.

In the docs: Editing your app and Visual edits.