Oszczędności czasu w Cursorze przy codziennych obowiązkach

Sposoby na oszczędzanie czasu w Cursorze to małe, powtarzalne metody przekazania rutynowych zadań edytorowi albo agentowi: formatowanie przy zapisie, jednozdaniowe edycje inline, komentarze dokumentujące, wiadomości commitów, masowe zmiany wzorca, brakujące testy i poprawki przed pushem. Każdy z nich oszczędza czas tylko wtedy, gdy towarzyszy mu automatyczna kontrola, która potwierdza wynik bez czytania każdej zmienionej linii.

Jest 14:00, a funkcja, która miała zająć poranek, wciąż jest otwarta. Ręcznie napisałeś JSDoc dla ośmiu funkcji, poprawiłeś ten sam błąd lintera w 12 plikach, wkleiłeś jeden wzorzec obsługi błędów do czterech endpointów, a potem z pamięci wpisałeś wiadomość commita. Nic z tego nie było trudne i nic z tego nie wymagało ciebie.

Ta strona jest dla programistów, którzy codziennie pracują w Cursorze i chcą, żeby powtarzalna część dnia działała sama. Każdy z poniższych sposobów ma prompt albo ustawienie oraz komendę, która mówi, czy zadziałało.

Czego dotyczy ta strona

Linii Cursor 3.x. Skróty i format reguł mogą się różnić między wersjami, dlatego nie podajemy tu klawisza edycji inline: dla swojej wersji sprawdź skróty klawiszowe i reguły projektu w Cursorze.

Co daje ci ta strona

• Tabelę ośmiu powtarzalnych zadań: który tryb lub funkcja Cursora je obsługuje i jaka kontrola sprawdza wynik.
• Siedem gotowych promptów: komentarze dokumentujące, wiadomości commitów, masowa zmiana wzorca, brakujące testy, dowód, że te testy potrafią wykryć błąd, pętla poprawek przed pushem i codzienna notatka przekazania.
• Trzy kontrole w terminalu zamiast czytania diffu: zmiany wyłącznie w komentarzach, pozostałości starego wzorca i wyciszenia dodane po to, żeby przejść na zielono.
• Sposób, żeby oszczędności nie wygasły: Agent Skills, reguły z zakresem, hooki i zaplanowane Automations.

Które zadania warto oddać Cursorowi najpierw?

Zacznij od zadań, które powtarzasz najczęściej i które mają już mechaniczną kontrolę. Zadanie bez kontroli przenosi tylko pracę z pisania na przeglądanie.

Zadanie	Gdzie działa w Cursorze	Kontrola, która je sprawdza	Gdzie jest zapisane
Formatowanie i kolejność importów	Ustawienie edytora, przy zapisie	Formatter i linter w CI	.vscode/settings.json w repozytorium
Jednozdaniowa zmiana zaznaczenia	Edycja inline	Kontrola typów i testy tego pliku	Nic do zapisania
Komentarze dokumentujące moduł	Agent	Kontrola diffu tylko w komentarzach, kontrola typów	Agent Skill (albo plik komendy)
Wiadomość commita	Agent	commitlint w hooku commit-msg albo w CI	Agent Skill (albo plik komendy)
Jedna zmiana wzorca w wielu plikach	Agent, na osobnej gałęzi lub w worktree	Zero wystąpień starego wzorca, kontrola typów, testy	Prompt i reguła z zakresem
Brakujące pliki testów	Agent	Każdy nowy test nie przechodzi na celowo zepsutej funkcji	Agent Skill (albo plik komendy)
Pętla poprawek przed pushem	Agent	CI uruchamia te same komendy; brak nowych wyciszeń	Agent Skill (albo plik komendy)
Codzienna notatka przekazania	Agent, tylko odczyt	Czytasz notatkę; nic nie trafia do commita	Lokalny plik wykluczony z gita

Zanim uwierzysz w oszczędności, zmierz je. W randomizowanym badaniu METR z udziałem doświadczonych programistów open source, na narzędziach z początku 2025 roku, zadania z AI trwały o 19% dłużej (METR, 2025-07-10). W kontynuacji z 2026 roku szacunki punktowe wypadają na korzyść AI, ale nie są istotne statystycznie, a METR zaznacza, że efekt selekcji utrudnia ich interpretację. Poczucie, że pracujesz szybciej, nie jest dowodem; jest nim czas od rozpoczęcia zadania do zielonego pull requesta.

Formatowanie i importy poprawiane przy zapisie

Ten sposób w ogóle nie potrzebuje modelu. Umieść ustawienia w repozytorium, żeby dostał je każdy w zespole, a linter w CI niech wyłapie każdego, czyj edytor je ignoruje. Dodaj to do .vscode/settings.json:

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

"explicit" uruchamia akcję przy ręcznym zapisie, a nie przy autozapisie po opóźnieniu, więc wolny formatter nie odpala się w trakcie pisania. Kontrolą jest ten sam formatter i linter uruchamiany w CI: jeśli npm run lint przechodzi tam, nikt nie musi komentować formatowania w review.

Edycja inline dla zmian mieszczących się w jednym zdaniu

Jeśli zmianę da się opisać jednym zdaniem i nie wychodzi poza zaznaczenie, użyj edycji inline zamiast otwierać czat z agentem; klawisz dla twojej wersji podają skróty klawiszowe. Zaznacz kod i wpisz polecenie:

• „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.”

Jeśli zmiana wymaga akapitu, dotyka innych plików albo trzeba uruchomić komendę, użyj agenta. Edycja inline pokazuje zmianę jako diff na zaznaczeniu, więc kontrola jest lokalna: kontrola typów zgłasza błędy w pliku przy zapisie, a ty uruchamiasz testy tego pliku, zanim pójdziesz dalej. Resztę opisuje edycja inline w Cursorze, a zmiany, które inaczej wpisałbyś ręcznie, Cursor Tab.

Dokumentowanie modułu bez ruszania kodu

Komentarze dokumentujące to zadanie pomijane najczęściej, bo kosztuje czas teraz, a zwraca się później. Agent napisze je w jednym przebiegu, ale istnieje ryzyko, że przy okazji „uporządkuje” kod. Prompt tego zabrania, a kontrola w terminalu to udowadnia.

Prompt do skopiowania: JSDoc dla jednego modułu

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.

Następnie potwierdź, że zmieniły się tylko linie komentarzy. Uruchom w terminalu:

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

Pusty wynik oznacza, że każda zmieniona linia to komentarz albo pusta linia. Każda wypisana linia to zmiana kodu, na którą prompt nie pozwalał; cofnij ją przez git restore -p src/services/order-service.ts. Dokumentację na poziomie modułów i architektury opisuje dokumentacja z Cursorem.

Wiadomość commita na podstawie zmian w git diff --staged

Precyzyjna wiadomość commita zwraca się w git log i git bisect, ale wybija z rytmu dokładnie wtedy, gdy chcesz iść dalej. Niech agent przeczyta zmiany z git diff --staged i przygotuje wersję roboczą, a linter pilnuje formatu.

Prompt do skopiowania: wiadomość commita ze zmian w staging area

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.

Agent powie, co się zmieniło, ale tylko ty wiesz dlaczego. Gdy tym „dlaczego” jest zgłoszenie błędu, dopisz je do prompta: „This fixes the NaN total when quantity is a decimal.” Potem przeczytaj wiadomość obok git diff --staged --stat: wiadomość, która opisuje zachowanie niewynikające z listy plików, jest błędna.

Zrób z formatu kontrolę, a nie nawyk. Zainstaluj commitlint (@commitlint/cli 21.x, sprawdzone 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

Podepnij go pod hook commit-msg i pod CI, żeby zła wiadomość nie przeszła, bez względu na to, kto ją napisał:

printf '#!/bin/sh\nnpx --no -- commitlint --edit "$1"\n' > .git/hooks/commit-msg
chmod +x .git/hooks/commit-msg
# w CI sprawdź każdy commit na gałęzi:
npx commitlint --from origin/main --to HEAD --verbose

Katalog .git/hooks nie jest wersjonowany, więc w każdym klonie dwie pierwsze linie uruchamia się raz; menedżer hooków, na przykład husky, trzyma hook w repozytorium. Aby uruchamiać prompt po nazwie zamiast go wklejać, zapisz go jako Agent Skill: plik commit-message/SKILL.md z polami name i description we frontmatterze i promptem jako treścią. Gdzie go zainstalować, pokazują szablony promptów dla agenta Cursora.

Jedna zmiana wzorca w wielu plikach

Zamiana wzorca obsługi błędów w 15 plikach tras to zadanie, w którym agent oszczędza najwięcej czasu i może narobić najwięcej szkód. Odizoluj je, spraw, żeby stary wzorzec dało się policzyć, i niech o wyniku zdecydują licznik i testy.

1. Zacznij od czystego drzewa roboczego na osobnej gałęzi albo w worktree („Worktrees let Agent work in isolated Git checkouts”, według dokumentacji Cursora sprawdzonej 2026-08-28). Zanotuj commit startowy przez git rev-parse HEAD. Czysty start sprowadza wycofanie zmian do jednej komendy.

2. Policz wystąpienia starego wzorca, żeby mieć punkt odniesienia. Uruchom w terminalu rg -c 'res\.status\(500\)\.json' src/routes i zanotuj pliki oraz liczby.

3. Wklej poniższy prompt do agenta.

4. Uruchom tę samą komendę rg jeszcze raz. Nie może nic wypisać. Następnie sam uruchom npx tsc --noEmit i npm test, poza sesją agenta.

5. Jeśli coś jest czerwone, a poprawka nie jest oczywista, odrzuć całą partię przez git reset --hard <start-sha> && git clean -fd i uruchom prompt ponownie na mniejszym katalogu.

Prompt do skopiowania: jedna zmiana wzorca w plikach tras

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.

Partie po pięć plików trzymają awarię blisko jej przyczyny. Większe zmiany strukturalne, takie jak przenoszenie modułów czy dzielenie serwisów, opisują strategie refaktoryzacji w Cursorze.

Brakujące pliki testów i dowód, że wykrywają błędy

Wygenerowanie pierwszego pliku testów dla każdego nieprzetestowanego serwisu jest szybkie. Ryzykiem są testy, które przechodzą bez względu na to, co robi kod: dają zielony znaczek i zero bezpieczeństwa. Dlatego każdy wygenerowany zestaw dostaje drugi prompt, który próbuje go złamać.

Prompt do skopiowania: brakujące pliki testów

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.

Prompt do skopiowania: dowód, że nowe testy wykrywają błędy

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.

Tabelę agent pisze o własnych testach, więc nie przyjmuj jej na wiarę. Powtórz jeden wiersz samodzielnie: wprowadź ręcznie ten sam błąd, uruchom ten plik testów i sprawdź, czy test nie przechodzi. To właśnie ręczne testowanie mutacyjne, po jednym mutancie naraz.

Narzędzie mutacyjne robi to samo dla każdego warunku i operatora w pliku. StrykerJS (@stryker-mutator/core 10.x, sprawdzone 2026-10-02) zmienia wskazane pliki źródłowe, uruchamia testy przy każdej zmianie i wypisuje te, których żaden test nie wykrył. Z Vitestem:

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'

W --mutate podaj pliki źródłowe, które pokrywają nowe testy, nigdy same pliki testów. Każdy wpis [Survived] w wyniku to błąd, który zestaw testów przepuścił. Najpierw zainstaluj pakiet z zakresem @stryker-mutator: gołe npx stryker bez instalacji pobiera pakiet stryker bez zakresu, czyli wydanie 0.x oznaczone w npm jako przestarzałe. Przy Jeście albo Mochy npm init stryker@latest zapyta o runner i zapisze plik konfiguracyjny. Jak silna jest twoja wyrocznia? wyjaśnia, jakiego wyniku wymagać w CI, a wzorce testowania w Cursorze opisują szersze workflow testowe.

Kontrola przed pushem i naprawa tego, co wykryje

Czerwone CI po pushu kosztuje pełny cykl pipeline’u. Uruchom najpierw te same komendy lokalnie i pozwól agentowi poprawić to, co znajdą. Poprawia agent; o tym, czy się udało, decydują komendy.

Prompt do skopiowania: pętla poprawek przed pushem

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.

Potem sprawdź, czy agent dotrzymał zasad. Uruchom to przed pushem:

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'

Diff względem commita, a nie zakresu (origin/main...HEAD), obejmuje też zmiany w stagingu i niezacommitowane. To ważne, bo powyższa pętla niczego nie commituje: zakres z trzema kropkami widziałby tylko zacommitowaną historię i nic by nie wypisał. git fetch aktualizuje origin/main. Grep nie może nic wypisać. Ostatnia komenda pokazuje każdy plik testów zmieniony na gałęzi, zacommitowany czy nie; zmiana testu, o którą nie prosiłeś, to pierwsza rzecz do zakwestionowania. CI uruchamia te same komendy na pull requeście i to jest niezależne potwierdzenie.

Notatka przekazania na początek i koniec dnia

Pierwsze minuty poranka często idą na „gdzie ja skończyłem?”. Krótka notatka napisana przez agenta pod koniec dnia i trzymana poza gitem odpowiada na to pytanie.

Prompt do skopiowania: notatka przekazania na koniec dnia

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.

Raz dodaj HANDOFF.md do .git/info/exclude, żeby nigdy nie trafił do commita. Rano otwórz nowy czat z agentem i poproś: „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.” Dla każdego odrębnego zadania zaczynaj nowy czat; długi wątek niesie stare instrukcje, których bieżące zadanie nie potrzebuje.

Jak utrwalić oszczędności: skille, reguły, hooki i Automations

Prompt wklejany z notatnika z czasem się rozjeżdża. Zapisz każdy z tych sposobów tam, gdzie Cursor uruchomi go bez twojej pamięci.

• Agent Skills (albo komendy) do zadań, które uruchamiasz ręcznie. Agent Skill to folder z plikiem SKILL.md, którego frontmatter zawiera name i description; żeby go uruchomić, nazywasz skill w prompcie (cursor.com/docs/skills, sprawdzone 2026-08-28). Nowe powtarzalne prompty zapisuj jako skille; jeśli twoja wersja ma jeszcze starsze pliki komend z ukośnikiem, zanim je przeniesiesz, sprawdź jej dokumentację. Szablony promptów dla agenta Cursora porównują skille i reguły oraz pokazują, gdzie je zainstalować.
• Reguły projektu z zakresem dla konwencji, których agent musi przestrzegać za każdym razem, gdy dotyka określonych plików, na przykład „handlery tras rzucają AppError”. Reguła z zakresem src/routes/**/*.ts sprawia, że opisana wyżej zmiana masowa nie będzie już potrzebna. Format opisują reguły projektu w Cursorze.
• Hooki dla kontroli, które muszą działać bez względu na to, czy ktoś o nie poprosi. Hooki Cursora „run before or after defined stages of the agent loop and can observe, block, or modify behavior” (dokumentacja Cursora, sprawdzona 2026-08-28), więc hook może uruchomić formatter albo linter po tym, jak agent zmieni plik. Zobacz workflow automatyzacji.
• Automations dla zadań, które nie potrzebują nikogo w pętli. Cursor Automations uruchamiają agentów w chmurze według harmonogramu albo na zdarzenia z GitHuba, Slacka, Lineara i innych (dokumentacja Cursora, sprawdzona 2026-08-28), więc cotygodniowe zadanie „znajdź eksportowane funkcje bez komentarzy i otwórz pull request” dobrze tu pasuje. Zobacz Cloud Agents i Automations.

Jak sprawdzić te oszczędności bez czytania każdej linii?

Każdy z opisanych sposobów kończy się kontrolą wykonywaną przez maszynę, a kod czytasz tylko tam, gdzie kontrola jest słaba.

1. Formatowanie i lint: CI uruchamia ten sam formatter i linter; zielony przebieg jest akceptacją.
2. Komentarze dokumentujące: kontrola diffu tylko w komentarzach nic nie wypisuje, a kontrola typów przechodzi.
3. Wiadomości commitów: commitlint przechodzi, a podsumowanie zgadza się z git diff --staged --stat.
4. Zmiany masowe: licznik starego wzorca wynosi zero, a kontrola typów i testy przechodzą poza sesją agenta.
5. Nowe testy: każdy nowy plik testów przynajmniej raz nie przeszedł na celowo wprowadzonym błędzie, a co najmniej jeden wiersz tej tabeli powtórzyłeś sam.
6. Poprawki przed pushem: brak nowych wyciszeń i zmian w testach, o które nie prosiłeś, a CI się zgadza.

Pull request akceptujesz, czytając te dowody. Zmiany w uwierzytelnianiu, płatnościach, schematach i migracjach nadal wymagają przeczytania kodu przez człowieka, bez względu na autora. Pakiet dowodów określa, co powinien zawierać pull request, żeby recenzent mógł zrobić to samo.

Kiedy oszczędności w Cursorze kosztują więcej czasu, niż dają

Przebieg z komentarzami przy okazji „ulepsza” kod. Kontrola tylko komentarzy wypisuje linie kodu. Cofnij je przez git restore -p i przenieś linię „Do NOT change any code” na początek prompta.

Zmiana masowa coś psuje, a nie wiesz, w którym pliku. Partia była za duża. Odrzuć ją przez git reset --hard <start-sha> && git clean -fd, uruchom ponownie na jednym katalogu i zostaw instrukcję o partiach po pięć plików.

Pętla przed pushem przechodzi na zielono, osłabiając kontrole. Grep wyciszeń coś wypisuje albo zmienił się plik testów, o którym nie było mowy. Przywróć testy przez git checkout origin/main -- <ścieżki testów>, usuń wyciszenia i uruchom ponownie. Żeby to zmechanizować, zablokuj ścieżki testów zgodnie z opisem w ochronie wyroczni.

Wygenerowane testy przechodzą na zepsutym kodzie. Tabela „dowód, że wykrywają błędy” ma zielony wiersz. Te testy sprawdzają mocki zamiast wyników; poproś agenta o przepisanie asercji tylko w tym pliku i powtórz test z błędem.

Wiadomości commitów są poprawne i bezużyteczne. Wiadomość brzmi „update order service”. Z diffu agent nie wyczyta, dlaczego wprowadziłeś zmianę, więc podaj mu powód w jednym zdaniu.

Formatowanie przy zapisie jest wolne albo walczy z agentem. Ciężki formatter uruchamia się przy każdym zapisie, gdy agent zapisuje wiele plików. Zostaw akcje kodu na "explicit"; formatowanie przy zapisie nie uruchamia się przy autozapisie po opóźnieniu. Pliki agenta niech sformatuje za jednym razem hook albo pętla przed pushem.

Edycja inline ciągle chybia. Ta zmiana nie mieściła się w jednym zdaniu. Cofnij ją i daj to samo polecenie agentowi, razem z plikiem i testem, który ma przejść.

Dokąd dalej

• Szablony promptów dla agenta Cursora: pełne szablony do funkcji, błędów, refaktoryzacji i przeglądów.
• Zarządzanie snippetami w Cursorze: tworzenie szkieletów nowych plików ze snippetów, reguł i agenta.
• Checkpointy i gałęzie: warstwa wycofywania pod każdą zmianą masową.
• Skróty klawiszowe: to one przyspieszają te sposoby w codziennej pracy.
• Te same pomysły w innych narzędziach: triki wydajnościowe Claude Code i triki wydajnościowe Codexa.