Cursor Prompts for UI Design and Frontend Builds
A useful Cursor brief tells the agent what already exists, what it may change and how you will judge the result. Start with one screen in a real repository, not a request to redesign the entire product.
UI Discovery editorial · Updated
How to use this guide
Read the project before writing UI
Give the agent the target route, relevant components and the task the user needs to finish. Ask it to inspect the package scripts, design tokens and repository instructions before making changes. Keep one-off screen requirements in the task; stable project conventions can live in project rules.
Define the smallest complete screen
For a dashboard, completeness means a loading state, a populated state, a genuine empty state and a recoverable failure. Name which data is a fixture and which endpoint already exists. An attractive table that silently fabricates account data is not a finished dashboard.
Review the diff and the browser
Check the agent's changed files, then use the screen at narrow and wide widths. Try a long label, a missing value and keyboard navigation. Ask for the commands actually run and their results; a statement that the UI is accessible is not a test report.
Original prompt to adapt
An editorial starting brief, not a benchmarked model output. Replace fictional content and review the result before publishing.
Inspect this repository's instructions, package scripts, design tokens and shared UI components. Build an account activity dashboard in the existing dashboard route. Reuse the current navigation and table components. Include a date-range control, a compact summary and an activity table with time, actor, action and status. Use clearly labelled fixture data only if no endpoint exists; do not add a backend or change authentication. Implement loading, no-activity and failed-request states with a retry action. At 390px keep the page within the viewport and allow only the table to scroll horizontally. Make controls keyboard-operable and announce updated results. Run the existing checks and report changed files, executed tests and remaining limitations.
A focused follow-up
Keep the layout and tokens unchanged. Test an empty result, a 120-character actor name and a failed request. Fix only the state handling and overflow you can reproduce, then summarize the diff.
Review checklist
- Existing routing, authentication and tokens are unchanged.
- Loading, empty and failed requests have distinct messages.
- The test report names commands and does not claim unrun browser checks.
Continue with real references
- Dashboard references →
Compare information hierarchy before choosing a layout.
- Metrics starter →
Inspect an existing code starting point; it is not an output of this prompt.
Official tool documentation
Tool interfaces and capabilities can change; check the provider’s current documentation.
Common questions
Can I use this prompt unchanged?
Use it as a starting brief. Replace fictional content, inspect the reference links and adapt constraints to your project. These are original editorial prompts, not benchmarked model outputs.
What should I check before publishing?
Existing routing, authentication and tokens are unchanged. Loading, empty and failed requests have distinct messages. The test report names commands and does not claim unrun browser checks.