Skip to main content
The quality of what Openv2 builds for you depends heavily on the quality of your prompts. Clear, specific requests give the AI the context it needs to get things right the first time — saving you credits and keeping your project history clean.

​
State your goal clearly

Lead with what the screen or feature should do, not how to implement it. 
Make it better.
The AI has no target to aim for. It may change things you didn’t want changed.

​
Name your constraints up front

If you have preferences about how the app should be built, state them before the AI writes any code. Retrofitting a different library later costs more turns.
  • Navigation — Specify Expo Router or React Navigation if you have a preference.
  • Styling — Tell the AI to use StyleSheet, NativeWind, or Tamagui so it doesn’t mix approaches.
  • Data — Say whether to use local state, a context store, or a backend (Backend) so it doesn’t add dependencies you don’t want.
Example: 
Add a settings screen using Expo Router (file-based routing).
Style it with NativeWind only — no StyleSheet objects.
Store the theme preference in AsyncStorage.

​
Work in slices

Build one flow at a time. Large “build the whole app” requests tend to produce more regressions and harder-to-review diffs. A good sequence looks like this:
1

Scaffold the core screen

Get one screen working end-to-end before moving on.
2

Add navigation

Wire up the routes and passing parameters once the screens exist.
3

Connect data

Add state management or a backend call after navigation is stable.
4

Polish

Apply spacing, colors, and accessibility tweaks last when the structure is settled.

​
Point to specific files

If you know where the issue is, say so. It saves the AI a search pass and focuses the edit. 
The list isn't scrolling properly.

​
Use the element inspector for UI changes

When you want to tweak spacing, color, or copy on a specific element, click it in the Preview panel first. The element inspector sends structured context about that component to the AI — so it knows exactly which button or text node you mean, rather than guessing.
The element inspector is especially useful for pixel-level adjustments. Click the element, then type your instruction: “increase the padding on this card to 16px.”

​
Ask for verification steps

After a significant change, ask the AI to tell you what it modified and how to confirm it worked. This keeps you in the loop and makes the version history more useful. 
Add pull-to-refresh to the feed screen.
When done, list the files you changed and describe how I can verify it works in Preview.

​
Handle errors by sharing the full output

When something breaks, paste the full terminal error or red-box message into chat. Don’t summarize it — the exact text gives the AI the best chance of finding the root cause.
Ask the AI to fix the root cause, not just suppress the error. Avoid prompts like “make the TypeScript error go away” — they often produce any casts or disabled lint rules that mask real problems.
Good error prompt: 
Getting this error after your last change — paste terminal output here.
Fix the root cause. Do not silence TypeScript with `any` unless there is no better option.

​
Watch your credit usage

Shorter, well-scoped prompts often resolve in fewer turns than broad requests that need several rounds of correction. Check Billing & plans to understand your daily and monthly limits before starting a long build session.

Chat & AI assistant

Understand how a message turn works and how to pick the right model.

Workbench & editor

Browse files, make manual edits, and watch the terminal alongside chat.