Independent guide; no affiliation with or endorsement by Cursor.
Explain how the repository produces the site
A website repository can contain more than one version of the same visible page: a template, a preview, and the exported file visitors receive. Start by identifying the maintained source and the process that produces the output. Add the relevant commands and directories to a short project map.
For a low-code documentation site, the map might explain where article records live, which template renders them, and how shared navigation reaches every page. This gives an assistant enough context to trace a requested change without treating every similar file as equally authoritative.
Use project rules for stable conventions
The official Cursor rules documentation describes project rules that can be kept in the repository and scoped to the codebase. Use the documented rule format and applicability settings for your environment, then make the content describe the conventions your project actually follows.
- Identify the source location for shared components and generated output.
- Describe URL, asset-name, and content-field conventions that matter to edits.
- State the normal build command and the checks relevant to a finished change.
- Point to a maintained example instead of duplicating a large block of source.
Keep temporary requests in the task brief. A rule about clean directory URLs may apply across the project; a request to revise today's article title does not. Separating those lifetimes makes the guidance easier to understand and update.
Attach context around the behavior being changed
Consider a category page whose cards use the wrong image crop. Provide the card component, the category-page layout, one content record, and the intended image treatment. Explain whether the same card is reused elsewhere. This helps the request address the shared behavior rather than patch only the page where you first noticed it.
Ask for a brief explanation of the proposed edit when the relationship between those files is unclear. Confirm the component's role, then proceed with a recoverable change. Review both the source difference and the rendered category page, including a card with a different title length.
Keep repository context current
When the source structure changes, update the project map and rules in the same maintenance cycle. Remove references to obsolete build output or superseded commands. A precise instruction that points to an old file can be more misleading than a missing instruction because it appears authoritative.
Record unresolved decisions separately. If the team has not decided whether all cards should share a crop, say that in the task. Do not present a temporary visual preference as a permanent repository convention merely because it appeared in the latest conversation.
Common mistake: relying on a broad request to discover every constraint
An instruction to improve the whole site leaves source ownership, acceptable scope, and review criteria unclear. Name a visible problem, identify the relevant files, and explain what must be true when the change is complete. Expand the work when the evidence from that bounded task supports the next step.
Read the AI IDE workflow guide to connect repository context with planning, focused edits, visual checks, and a useful handoff.
