How to Start Working With Cursor AI

To start working with Cursor AI, install Cursor, sign in, open your project folder, and ask the assistant to explain the code before requesting one small change. Review the changed files and run the project’s checks before accepting the result.

You also need a place for decisions that outlast the conversation. Tools like fenbs keep the project goal, approved rules, tasks, and progress available when you return or switch coding assistants. Start with the code workflow, then add shared context where it saves repeated explanation.

What are the first setup steps?

1. Download Cursor from the official site, run the installer for your operating system, and sign in. Follow the current setup prompts rather than copying an old screenshot.
2. Choose a repository you are allowed to work on. Make sure you have a way to restore the starting files, such as a clean Git branch or a separate working copy.
3. Open the project folder in Cursor. Confirm that its top-level instructions, source files, and package or build files are visible.
4. Ask for a read-only explanation of the project before allowing edits. Check the answer against the actual files.

Cursor’s official quickstart↗ (opens in a new tab) follows the same sequence: installation, codebase explanation, a small change, and review. You do not need a complex feature as your first experiment. A short copy improvement with a visible result makes the process easier to understand.

If you are still deciding what the application does, read what Cursor AI is. This guide assumes you are ready to work in a local code repository; the broader AI at work library covers other workflows.

How do you open the right code and give context?

Use File > Open Folder and select the project folder. Cursor’s first-project guide↗ (opens in a new tab) documents that command and explains that Agent can search code, edit files, and run terminal commands. Opening the right folder matters because it establishes what the assistant can inspect.

Tell it which application or package contains the behavior you care about. Give a file path when you know it, an example of the current behavior, and the outcome you want. Cursor supports using an @ mention to point Agent at a file or folder, as described in the same guide.

Read the repository instructions and explain this project.
Do not edit files or run commands yet.
Find the main application entry point, the settings screen,
and the existing checks used for changes in that area.
Cite the file paths behind your explanation.
Flag anything you could not verify.

Read a few cited files yourself. If the answer describes a different application or guesses the package manager, correct that before proceeding. You are checking whether the assistant has enough context to make a useful first change, not whether it can produce a convincing overview.

What makes a good first request?

Choose a task you can describe with an observable result. For example: “Change the empty-state message on the saved-search screen to this approved sentence.” That is easier to review than “improve the user experience,” which leaves the assistant to invent both the problem and its scope.

• State the current behavior and the exact desired behavior.
• Name the area that can change and anything outside the task.
• Point to an existing component or function whose pattern should be followed.
• Specify how you will check the result, including any existing automated checks.

Ask it to explain the intended edit first if the change touches unfamiliar code. For larger work, Cursor’s quickstart describes Plan Mode, which researches the project and prepares a plan before implementation. Your first exercise should remain small enough that you can understand every changed line.

Record the approved goal and any choices that affected it. fenbs can keep those decisions with the task, so the next session starts from the same agreement rather than from a new interpretation of an old chat.

How do you review the first change?

A diff is a comparison showing which lines changed. Open it and compare every changed file with your request. Cursor’s first-project guide notes that Agent applies edits while it works, so review the working files rather than assuming all changes are waiting for a final approval button.

Check for unrelated cleanup, removed behavior, new dependencies, and accidental changes to configuration. Ask why any unfamiliar line is needed. Reject or revise changes you cannot explain, even if the assistant reports success.

Run the checks documented by the repository. For a visible interface change, inspect the relevant screen as well; a passing type check cannot tell you whether the sentence fits on a phone. Ask the assistant to distinguish checks it actually ran from checks it merely recommends.

If something fails, capture the exact command and error before changing more files. The guide to Cursor Agent problems covers troubleshooting separately. Keep the first task’s result small enough that you can restore the starting version without losing unrelated work.

Which instructions should you keep for future sessions?

Save instructions that remain true: the package manager, the required checks, the architectural pattern, and actions that require a person’s approval. Avoid turning every temporary preference into a standing rule. A rule should explain a repeatable constraint, while a task describes the change needed now.

Cursor documents project rules in .cursor/rules/ and supports an AGENTS.md instruction file at the project root in its rules guide↗ (opens in a new tab). Start with the repository’s existing instructions. The separate Cursor project rules guide covers organizing them in more detail.

Keep changing project state outside those stable instructions: what passed review, what remains untested, and which decision is waiting on someone. That is the work record described in what an AI brain is. A short current handoff is easier to trust than a permanent rule containing yesterday’s progress.

How to do this with fenbs

1. Create a free account and add a project for the repository.
2. Add the first small task with the intended result and its review steps. Record decisions a person has approved in Decisions and rules.
3. Follow the Cursor setup guide in Integrations. The connection uses MCP, a standard way for an assistant to use an outside tool, with browser sign-in.
4. Ask Cursor to read the project context before working and save progress when it finishes, including the checks run and the next step.

fenbs does not replace your editor, repository, or code review. It fits work that continues across sessions and assistants; a one-off local experiment may need only the project files and a clear request. The fenbs workflow explains how rules and saved progress reach a connected assistant.

What should your second session start with?

Start by checking the working files and reading the saved handoff. Ask the assistant to state what is complete, what is still uncertain, and what it will do next. Correct any disagreement before another edit compounds it.

Repeat the same small loop: explain, scope, edit, inspect, verify, and save progress. If you are learning a different coding assistant too, the Claude starting guide owns that setup. The useful habit across tools is knowing why a change was made and what evidence supports calling it finished.