> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openv2.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Prompting

> Write prompts that produce cleaner code, fewer follow-up turns, and better previews.

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.

<Tabs>
  <Tab title="Too vague">
    ```
    Make it better.
    ```

    The AI has no target to aim for. It may change things you didn't want changed.
  </Tab>

  <Tab title="Specific and actionable">
    ```
    On the Home screen, replace the FlatList with a SectionList grouped by date.
    Show an illustration and a "Create your first entry" button when the list is empty.
    ```

    The AI knows exactly which screen, which component, and what the empty state should look like.
  </Tab>
</Tabs>

## 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](/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:

<Steps>
  <Step title="Scaffold the core screen">
    Get one screen working end-to-end before moving on.
  </Step>

  <Step title="Add navigation">
    Wire up the routes and passing parameters once the screens exist.
  </Step>

  <Step title="Connect data">
    Add state management or a backend call after navigation is stable.
  </Step>

  <Step title="Polish">
    Apply spacing, colors, and accessibility tweaks last when the structure is settled.
  </Step>
</Steps>

## Point to specific files

If you know where the issue is, say so. It saves the AI a search pass and focuses the edit.

<Tabs>
  <Tab title="Unfocused">
    ```
    The list isn't scrolling properly.
    ```
  </Tab>

  <Tab title="Targeted">
    ```
    The FlatList in app/(tabs)/index.tsx isn't scrolling when the keyboard is open.
    Wrap it in a KeyboardAvoidingView.
    ```
  </Tab>
</Tabs>

## 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.

<Tip>
  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."
</Tip>

## 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.

<Warning>
  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.
</Warning>

**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](/billing-plans) to understand your daily and monthly limits before starting a long build session.

<CardGroup cols={2}>
  <Card title="Chat & AI assistant" icon="message-circle" href="/chat-ai-assistant">
    Understand how a message turn works and how to pick the right model.
  </Card>

  <Card title="Workbench & editor" icon="code" href="/workbench-editor">
    Browse files, make manual edits, and watch the terminal alongside chat.
  </Card>
</CardGroup>