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

# Prompting Best Practices

> How to get stronger results from Rushed without turning every request into a spec doc.

## Start with the outcome

Tell Rushed what you want the app or change to accomplish before you describe implementation details.

Instead of:

```text theme={null}
make a settings page
```

Try:

```text theme={null}
Create a settings page for a SaaS dashboard with profile, billing, and notification sections.
Make it clean, responsive, and ready for real data later.
```

## Give product context early

Rushed performs better when it understands the product you are building.

Useful context:

* Who the user is
* What the page or feature should help them do
* What matters most: speed, trust, conversion, clarity, polish
* Any visual direction you already know

## Ask for one meaningful step at a time

Big prompts work, but the best workflow is usually:

1. Get a solid first version.
2. Review the result in code and preview.
3. Ask for a focused follow-up.

This usually beats one giant prompt with twenty competing requirements.

## Reference files with `@`

Inside a project chat, type `@` to tag files directly in your prompt.

Good examples:

* `Use @src/app/page.tsx as the starting point and redesign the hero section.`
* `Fix the layout bug in @src/components/sidebar.tsx and keep the current styling.`
* `Read @package.json and set the right preview commands for this project.`

## Use selection-based workflows

In the editor, highlight code and use:

* `Add to Chat` when you want Rushed to reason about a specific block
* `Quick Edit` when you already know the exact local change you want

This is usually faster than describing a code fragment manually.

## Be explicit about what should not change

If you want Rushed to preserve structure, say so.

Examples:

* Keep the current layout, only improve spacing and copy.
* Do not rename files.
* Preserve the existing color palette.
* Update only the selected function.

## Ask for product-quality output

Rushed responds better when the quality bar is clear.

Examples:

* Make this feel production-ready, not like a template.
* Keep the UI simple but polished.
* Write the copy for end users, not developers.
* Optimize for mobile first.

## Prompt patterns that work well

### New app or page

```text theme={null}
Build a landing page for an AI meeting assistant.
Target founders and sales teams.
Make it modern, light, and conversion-focused with pricing and FAQ sections.
```

### Refine an existing screen

```text theme={null}
Use @src/app/dashboard/page.tsx.
Keep the layout, but make the hierarchy clearer, improve empty states, and tighten the spacing.
```

### Fix something broken

```text theme={null}
The preview crashes on startup.
Read @package.json and the app entry files, then set the correct install and dev commands so Preview works.
```

### Tight local edit

```text theme={null}
Change this selected code so the button shows a loading state and prevents double submits.
```

## When results are weak

Usually one of these is missing:

* The goal
* The target user
* The file or area to change
* The constraints
* The definition of "better"

If Rushed goes too broad, narrow the scope. If it goes too literal, add more product context.