Cursor time savers for everyday chores

Cursor time savers are small, repeatable ways to hand recurring chores to the editor or the agent: formatting on save, one-sentence inline edits, doc comments, commit messages, bulk pattern changes, missing tests and pre-push fixes. Each one saves time only when it comes with an automatic check that confirms the result without anyone reading every changed line.

It is 2 p.m. and the feature that should have taken the morning is still open. You wrote JSDoc for eight functions by hand, fixed the same lint error in 12 files, pasted one error-handling pattern into four endpoints and then typed a commit message from memory. None of it was hard, and none of it needed you.

This page is for developers who work in Cursor every day and want the repetitive part of the day to run on its own. Each time saver below comes with a prompt or a setting, and with the command that tells you it worked.

What this page covers

The Cursor 3.x line. Cursor’s help lists Cmd+K for inline edit, and its rules documentation says project rules are .mdc files in .cursor/rules (both checked 2026-10-12). Other shortcuts can differ between builds and systems, so check the keyboard shortcuts reference and project rules in Cursor for yours.

What this page gives you

• A table of eight recurring chores, the Cursor surface that handles each one, and the gate that checks it.
• Seven copy-paste prompts: doc comments, commit messages, bulk pattern changes, missing tests, a test that proves those tests can fail, a pre-push fix loop and a daily handoff note.
• Three shell checks that replace reading the diff: comment-only changes, leftover old patterns, and suppressions added to get a green run.
• A way to keep the savers from decaying: Agent Skills, scoped rules, hooks and scheduled Automations.

Which chores should you hand to Cursor first?

Start with the chores you repeat most that already have a mechanical check. A chore without a check only moves the work from typing to reviewing.

Chore	Where it runs in Cursor	The gate that checks it	Where it lives
Formatting and import order	Editor setting, on save	Formatter and linter in CI	.vscode/settings.json in the repository
One-sentence change to a selection	Inline edit	Type check and the tests of that file	Nothing to store
Doc comments for a module	Agent	Comment-only diff check, type check	Agent Skill (or command file)
Commit message	Agent	commitlint in a commit-msg hook or in CI	Agent Skill (or command file)
One pattern change across many files	Agent, in its own branch or worktree	Zero matches for the old pattern, type check, tests	Prompt plus a scoped rule
Missing test files	Agent	Each new test fails against a deliberately broken function	Agent Skill (or command file)
Pre-push fix loop	Agent	CI reruns the same commands; no new suppressions	Agent Skill (or command file)
Daily handoff note	Agent, read-only	You read the note; nothing is committed	Local file excluded from git

Measure before you believe the savings. In METR’s randomized trial of experienced open-source developers on early-2025 tools, tasks took 19% longer with AI (METR, 2025-07-10). METR’s 2026 follow-up has point estimates that favour AI, but they are not statistically significant, and METR says selection makes them hard to interpret. Feeling faster is not evidence; the time from starting a task to a green pull request is.

Let the editor fix formatting and imports on save

This saver needs no model at all. Put the settings in the repository so every teammate gets them, and let the linter in CI catch anyone whose editor ignores them. Add this to .vscode/settings.json:

{
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit",
    "source.organizeImports": "explicit"
  }
}

"explicit" runs the action on a manual save, not on auto-save after a delay, so a slow formatter does not fire while you type. The gate is the same formatter and linter running in CI: if npm run lint passes there, nobody has to comment on formatting in review.

Use inline edit for one-sentence changes

If you can say the change in one sentence and it stays inside the selection, use inline edit (Cmd+K, per Cursor’s help, checked 2026-10-12) instead of opening an agent chat; the keyboard shortcuts reference covers other systems and builds. Select the code and type the instruction:

• “Handle the case where user is null and return 404.”
• “Add input validation with the OrderSchema from src/schemas/order.ts.”
• “Log the error with logger.error and rethrow it.”

If the change needs a paragraph, touches other files or needs a command run, use the agent instead. Inline edit shows the change as a diff on the selection, so the check is local: the type checker flags the file on save, and you run that file’s tests before you move on. Inline edit in Cursor covers the rest, and Cursor Tab covers the edits you would otherwise type.

Document a module without touching its code

Doc comments are the chore people skip most, because they cost time now and pay off later. The agent can write them in one pass, but the risk is that it also “tidies” the code. The prompt forbids that, and a shell check proves it.

Copy-paste prompt: JSDoc for one module

Add JSDoc to every exported function in @src/services/order-service.ts.

For each function:
- One sentence on what it does, written from the caller's point of view.
- @param for every parameter: what it means, not its type (the type is in the signature).
- @returns: what the value contains, including when it can be empty.
- @throws for each error class the function can throw, read from the code.
- @example only when the call is not obvious from the signature.

Do NOT change any code, imports, whitespace or formatting outside the comments.
When you finish, run `npx tsc --noEmit` and report its last line.

Then confirm that only comment lines changed. Run this in the terminal:

git diff -U0 -- src/services/order-service.ts \
  | grep -E '^[+-]' | grep -vE '^(\+\+\+|---)' \
  | grep -vE '^[+-][[:space:]]*(/\*\*|\*|//|$)'

Empty output means every changed line is a comment or a blank line. Any line printed is a code change the prompt did not allow; revert it with git restore -p src/services/order-service.ts. For module-level and architecture documentation, see documentation with Cursor.

Write the commit message from the staged diff

A precise commit message pays off in git log and git bisect, but it breaks your flow at the moment you want to move on. Let the agent read the staged diff and draft it, and let a linter enforce the format.

Copy-paste prompt: commit message from staged changes

Run `git diff --staged` and write a commit message for those changes only.

Format:
- First line: type(scope): summary, under 72 characters. Types: feat, fix, refactor, test, docs, chore.
- Blank line.
- Body: up to three bullets on what changed and why. Name the behaviour, not the files.

If the staged changes do two unrelated things, say so and propose how to split them instead of writing one message.
Do not run `git commit`. Print the message only.

The agent can say what changed, but only you know why. When the “why” is a bug report, add it to the prompt: “This fixes the NaN total when quantity is a decimal.” Then read the message next to git diff --staged --stat: a message that names a behaviour the file list cannot support is wrong.

Make the format a gate rather than a habit. Install commitlint (@commitlint/cli 21.x, checked on 2026-09-26):

npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.mjs
npx commitlint --last --verbose

Wire it into a commit-msg hook and into CI, so a bad message fails whoever wrote it:

printf '#!/bin/sh\nnpx --no -- commitlint --edit "$1"\n' > .git/hooks/commit-msg
chmod +x .git/hooks/commit-msg
# in CI, check every commit on the branch:
npx commitlint --from origin/main --to HEAD --verbose

.git/hooks is not versioned, so each clone runs the first two lines once; a hook manager such as husky stores the hook in the repository instead. To start the prompt by name instead of pasting it, package it as an Agent Skill: a commit-message/SKILL.md file with a name and a description in its frontmatter and the prompt as its body. Prompt templates for Cursor’s agent shows where to install it.

Apply one pattern change across many files

Replacing an error-handling pattern in 15 route files is the chore where the agent saves the most time and can do the most damage. Isolate it, make the old pattern countable, and let the count and the tests decide.

1. Start from a clean tree on its own branch, or in a worktree (“Worktrees let Agent work in isolated Git checkouts”, per Cursor’s docs, checked on 2026-08-28). Note the starting commit with git rev-parse HEAD. A clean start makes the rollback one command.

2. Count the old pattern so you have a baseline. Run rg -c 'res\.status\(500\)\.json' src/routes in the terminal and note the files and numbers.

3. Paste the prompt below into the agent.

4. Run the same rg command again. It must print nothing. Then run npx tsc --noEmit and npm test yourself, outside the agent’s session.

5. If anything is red and the fix is not obvious, discard the whole batch with git reset --hard <start-sha> && git clean -fd and rerun the prompt on a smaller directory.

Copy-paste prompt: one pattern change across route files

In @src/routes/, replace every occurrence of this pattern:

  res.status(500).json({ error: error.message })

with our standard error:

  throw new AppError(500, error.message, { cause: error })

Import AppError from src/lib/errors.ts in each file that does not already import it.
Change nothing else in these files. Do NOT edit any file under tests/ or __tests__/. Do not commit.

Work in batches of five files. After each batch, run `npx tsc --noEmit` and the tests for those routes, and fix failures before the next batch.
At the end, run `rg -c 'res\.status\(500\)\.json' src/routes` and report its output, the list of files changed, and the last lines of the test run.

Batches of five keep a failure close to its cause. For bigger structural changes, such as moving modules or splitting services, see refactoring strategies in Cursor.

Fill in missing test files, then prove they can fail

Generating a first test file for each untested service is fast. The risk is tests that pass whatever the code does, which buys a green check and no safety. So every generated suite gets a second prompt that tries to break it.

Copy-paste prompt: missing test files

List every .ts file in @src/services/ that has no matching test file in src/services/__tests__/.

For each one, write a test file that covers:
- the main success path of each exported function,
- one failure path per function (invalid input or a failing dependency),
- external dependencies mocked the way @src/services/__tests__/user-service.test.ts does it.

Assert on returned values and thrown errors, not on the fact that a mock was called.
Do NOT change any file outside src/services/__tests__/.
Run the new tests and report the results per file.

Copy-paste prompt: prove the new tests can fail

For each test file you just created in src/services/__tests__/:

1. Pick one exported function it covers and introduce one realistic bug in the source (flip a condition, drop an await, return early).
2. Run only that test file and record whether it fails.
3. Revert only the injected bug by undoing your own edit (check with `git diff <file>` that nothing else changed) and confirm the tests pass again. Before step 1, stop if `git status --porcelain src/` shows uncommitted changes in source files.

Report a table: test file, bug introduced, failed yes/no.
Any test file that stayed green against its bug is not done: strengthen its assertions and repeat.

The table is the agent’s report on its own tests, so do not accept it on trust. Rerun one row yourself: make the same bug by hand, run that test file, and check that it fails. That is mutation testing by hand, one mutant at a time.

A mutation tool does the same thing for every condition and operator in a file. StrykerJS (@stryker-mutator/core 10.x, checked on 2026-10-02) changes the source files you name, reruns your tests against each change and lists the changes no test caught. With Vitest:

npm install --save-dev @stryker-mutator/core @stryker-mutator/vitest-runner
npx stryker run --testRunner vitest --reporters clear-text \
  --mutate 'src/services/order-service.ts'

Point --mutate at the source files the new tests cover, never at the test files. Each [Survived] entry in the output is a bug the suite let through. Install the scoped package first: a bare npx stryker with nothing installed fetches the unscoped stryker package, a 0.x release npm marks as deprecated. For Jest or Mocha, npm init stryker@latest asks for the runner and writes a config file. How strong is your oracle? explains what score to require in CI, and testing patterns in Cursor covers broader test workflows.

Run the pre-push gate and fix what it finds

A red CI run after a push costs a full pipeline cycle. Run the same commands locally first and let the agent fix what they find. The agent does the fixing; the commands decide whether it worked.

Copy-paste prompt: pre-push fix loop

Run these in order and fix every failure:

1. npx tsc --noEmit
2. npm run lint
3. npm test

Rules:
- Fix the code, not the check. Do NOT edit or delete tests, add eslint-disable, @ts-ignore, @ts-expect-error, .skip or .only, or change lint or tsconfig settings.
- If a test looks wrong rather than the code, stop and tell me which one and why.
- Repeat until all three pass.

Report what you changed and the last line of each command's final run.

Then check that the agent kept the rules. Run this before you push:

git fetch origin
base=$(git merge-base origin/main HEAD)
git diff -U0 "$base" \
  | grep -nE '^\+.*(eslint-disable|@ts-ignore|@ts-expect-error|\.skip\(|\.only\()'
git diff --stat "$base" -- '*.test.ts' '*.spec.ts'

Diffing against a commit rather than a range (origin/main...HEAD) includes staged and unstaged work, which matters because the loop above never commits: a three-dot range would see only committed history and print nothing. The fetch keeps origin/main current. The grep must print nothing. The last command lists every test file the branch touched, committed or not; a test change you did not ask for is the first thing to question. CI reruns the same commands on the pull request, which is the independent confirmation.

Start and end the day with a handoff note

The first minutes of the morning often go to “where was I?”. A short note written by the agent at the end of the day, kept out of git, answers that question.

Copy-paste prompt: end-of-day handoff note

Read `git status`, `git diff`, `git diff --staged` and `git log -5 --oneline`.
Write HANDOFF.md in the repository root with four short sections:
1. What I was working on (one sentence).
2. What is done, with the files.
3. What is left, as a checklist in the order I should do it.
4. Open questions and anything that is failing, with the failing command.

Do not modify any other file.

Add HANDOFF.md to .git/info/exclude once, so it never reaches a commit. In the morning, open a new agent chat and ask: “Read @HANDOFF.md and git status, tell me whether anything changed on main since then (git fetch && git log HEAD..origin/main --oneline), and propose the first step. Do not modify files.” Start a new chat for each distinct task; a long thread carries old instructions that the current task does not need.

Make the time savers stick: skills, rules, hooks and Automations

A prompt pasted from a notes app drifts. Store each saver where Cursor can run it without you remembering it.

• Agent Skills (or commands) for chores you start by hand. An Agent Skill is a folder with a SKILL.md whose frontmatter carries a name and a description; you name the skill in your prompt to run it (cursor.com/docs/skills, checked on 2026-08-28). Write new reusable prompts as skills; if your build still has older slash-command files, check its docs before converting them. Prompt templates for Cursor’s agent compares skills and rules and shows where to install them.
• Scoped project rules for conventions the agent must follow every time it touches certain files, such as “route handlers throw AppError”. A rule scoped to src/routes/**/*.ts means the bulk change above never has to happen again. See project rules in Cursor for the format.
• Hooks for checks that must run whether or not anyone asks. Cursor hooks “run before or after defined stages of the agent loop and can observe, block, or modify behavior” (Cursor docs, checked on 2026-08-28), so a hook can run the formatter or the linter after the agent edits a file. See automation workflows.
• Automations for chores that need no one in the loop. Cursor Automations run cloud agents on a schedule or on events. Cursor’s docs list these triggers: Scheduled (cron), Source control (GitHub, GitLab and Bitbucket Cloud), Slack (public channels only), Webhook, Linear, Sentry and PagerDuty (checked on 2026-10-12), so a weekly “find exported functions without doc comments and open a pull request” job fits. See Cloud Agents and Automations.

How do you verify these time savers without reading every line?

Each saver above ends in a check that a machine runs, and you read code only where the check is weak.

1. Formatting and lint: CI runs the same formatter and linter; a green run is the sign-off.
2. Doc comments: the comment-only diff check prints nothing, and the type check passes.
3. Commit messages: commitlint passes, and the summary matches git diff --staged --stat.
4. Bulk changes: the old pattern count is zero, and the type check and tests pass outside the agent’s session.
5. New tests: every new test file failed at least once against a deliberate bug, and you reproduced at least one row of that table yourself.
6. Pre-push fixes: no new suppressions, no unrequested test edits, and CI agrees.

You sign off on the pull request by reading this evidence. Changes to authentication, payments, schemas and migrations still get a human read of the code, whoever wrote it. The evidence bundle defines what a pull request should carry so a reviewer can do the same.

When Cursor time savers cost more time than they save

The doc-comment pass also “improves” the code. The comment-only check prints code lines. Revert them with git restore -p, and move the “Do NOT change any code” line to the top of the prompt.

A bulk change breaks something and you cannot tell which file. The batch was too large. Discard it with git reset --hard <start-sha> && git clean -fd, rerun on one directory, and keep the batches-of-five instruction.

The pre-push loop goes green by weakening the checks. The suppression grep prints a line, or a test file you did not mention changed. Restore the tests with git checkout origin/main -- <test paths>, delete the suppressions and rerun. To make this mechanical, lock test paths as described in protecting the oracle.

Generated tests pass against broken code. The “prove they can fail” table shows a green row. Those tests assert on mocks instead of results; ask the agent to rewrite the assertions for that file only, then repeat the break test.

Commit messages are accurate and useless. The message says “update order service”. The diff cannot tell the agent why you made the change, so give it the reason in one sentence.

Format on save is slow or fights the agent. A heavy formatter runs on every save while the agent writes many files. Keep the code actions on "explicit"; format-on-save does not run on delayed auto-save. Let a hook or the pre-push loop format the agent’s files in one pass.

Inline edit keeps missing the point. The change was not a one-sentence change. Undo it and give the same instruction to the agent, with the file and the test that should pass.

Where to go next

• Prompt templates for Cursor’s agent: full templates for features, bugs, refactors and reviews.
• Snippet management in Cursor: scaffolding new files from snippets, rules and the agent.
• Checkpoints and branching: the rollback layer under every bulk change.
• Keyboard shortcuts: the input layer that makes these savers faster.
• The same ideas for other tools: Claude Code efficiency hacks and Codex efficiency hacks.