Zaplanowana automatyzacja zadań z Codex

Jest poniedziałek rano. W weekend opublikowano trzy podatności zależności, ktoś scalił commit ze statementem console.log, a pokrycie testami modułu płatności spadło z 85% do 72%. Dowiadujesz się o tym podczas standupu. Ale gdybyś skonfigurował automatyzacje Codex w piątek, przyszedłbyś do spriorytetyzowanej skrzynki, w której każdy problem został już zidentyfikowany, przeanalizowany i — w niektórych przypadkach — naprawiony.

Czego się nauczysz

• Gotowe do użycia prompty automatyzacji dla najczęstszych powtarzalnych zadań programistycznych
• Przepływ pracy do bezpiecznego testowania automatyzacji przed zaplanowaniem ich
• Techniki łączenia automatyzacji z umiejętnościami dla złożonych wieloetapowych przepływów pracy
• Konfigurację bezpieczeństwa i sandboxa dla nienadzorowanych zadań w tle

Przepływ pracy

Jak działają automatyzacje

Lokalne zaplanowane zadania działają w ChatGPT desktop według zdefiniowanego harmonogramu. Każde uruchomienie:

1. Działa w lokalnym projekcie albo dedykowanym worktree, zależnie od wybranej opcji
2. Wykonuje prompt z domyślnymi ustawieniami sandboxa
3. Raportuje ustalenia do sekcji Scheduled na pasku bocznym ChatGPT desktop
4. Automatycznie archiwizuje uruchomienie, jeśli nie ma nic do zgłoszenia

Do lokalnych przebiegów potrzebujesz uruchomionego ChatGPT desktop i projektu dostępnego na dysku. ChatGPT web także zarządza zaplanowanymi zadaniami, ale przebiegi web nie mogą uzyskać dostępu do folderu komputera.

Krok 1: Testuj przed zaplanowaniem

Nigdy nie planuj automatyzacji na ślepo. Najpierw przetestuj prompt ręcznie w zwykłym wątku.

1. Otwórz ChatGPT desktop w trybie Codex i utwórz nowe zadanie w tym samym projekcie.
2. Wybierz Worktree, jeśli zaplanowane zadanie ma pozostać odizolowane od głównego checkoutu.
3. Wklej prompt automatyzacji i uruchom go.
4. Przejrzyj wyniki: Czy znalazł właściwe rzeczy? Czy wprowadził odpowiednie zmiany? Czy pozostał w zakresie?

Iteruj prompt, aż będziesz zadowolony, a następnie utwórz automatyzację z przetestowanym promptem.

Krok 2: Skonfiguruj podstawowe automatyzacje

Oto automatyzacje, które większość zespołów powinna uruchomić od pierwszego dnia:

Codziennie: Kontrola jakości kodu

Wskazówka

Prompt automatyzacji do skopiowania — codzienna kontrola jakości:

Daily code quality check on the latest main branch:

1. Pull the latest from origin/main
2. Run the linter (npm run lint). Report any new warnings or errors.
3. Run the type checker (npm run type-check). Report any type errors.
4. Check for console.log, console.error, or debugger statements in src/ (excluding test files)
5. Check for TODO or FIXME comments added in the last 24 hours of commits
6. Run npm audit and report any new Critical or High severity vulnerabilities

If issues are found, report each one with the file path and a suggested fix.
If everything is clean, report that no issues were found.

Cotygodniowo: Zdrowie zależności

Wskazówka

Prompt automatyzacji do skopiowania — cotygodniowa aktualizacja zależności:

Weekly dependency health check:

1. Run npm outdated and list packages that are more than 1 major version behind
2. Run npm audit and categorize vulnerabilities by severity
3. For each Critical vulnerability, check if an update is available that fixes it
4. For packages with available minor or patch updates that fix vulnerabilities, update them
5. After updating, run the full test suite
6. If tests pass, report which packages were updated and why
7. If tests fail after an update, revert that specific update and report the failure

Do NOT update major versions automatically. Only report them for manual review.

Co noc: Łowca błędów

Wskazówka

Prompt automatyzacji do skopiowania — nocne wykrywanie błędów:

Check my commits from the last 24 hours and look for bugs:

1. Use git log --since=1.day to find recent commits
2. For each commit, review the changed files for:
   - Off-by-one errors in loops or array operations
   - Unhandled promise rejections or missing error handling
   - Race conditions in concurrent operations
   - Missing null checks on values that could be undefined
3. If you find a potential bug, verify it by checking the surrounding code and any related tests
4. For confirmed bugs, propose a minimal fix and a regression test

Only report issues you are confident about. Do not flag style preferences or theoretical concerns.

To jest podobne do wzorca umiejętności $recent-code-bugfix z oficjalnej dokumentacji Codex. Możesz również utworzyć umiejętność i wywołać ją z automatyzacji:

Check my commits from the last 24h and submit a $recent-code-bugfix.

Cotygodniowo: Wykrywanie dryfu architektonicznego

Weekly architecture check:

1. Pull the latest from origin/main
2. Compare the current codebase structure against docs/ARCHITECTURE.md
3. Check for:
   - New directories or modules not documented
   - Documented modules that no longer exist
   - New cross-module dependencies that violate documented boundaries
   - New external service integrations not mentioned in the architecture doc
4. If drift is detected, update docs/ARCHITECTURE.md to match reality

Report what changed and whether it represents intentional evolution or accidental drift.

Codziennie: Briefing aktywności zespołu

Wskazówka

Prompt automatyzacji do skopiowania — codzienny briefing:

Look at the latest remote origin/main. Produce a briefing for the last 24 hours of commits:

- Group by workstream rather than listing each commit
- Write a short narrative per workstream explaining the changes
- Include PR links inline (e.g., [#123](...)) without a "PRs:" label
- Bold contributor names
- Only include commits within the current cwd
- Use gh to fetch PR titles and descriptions

Format with Markdown headings, horizontal rules, and bullet points.

Krok 3: Łącz automatyzacje z umiejętnościami

Umiejętności pozwalają enkapsulować złożone przepływy pracy, które automatyzacje mogą wywoływać. Utwórz umiejętność, zapisz ją w katalogu umiejętności osobistych lub repozytoryjnych i odwołuj się do niej za pomocą $skill-name w prompcie automatyzacji.

Przykład: Utwórz umiejętność $test-coverage-report, która wie, jak uruchomić pokrycie, porównać z bazowymi wartościami i sformatować wynik. Wtedy automatyzacja staje się:

Run $test-coverage-report on the latest main branch. If coverage dropped on any module, investigate and propose tests to restore it.

Umiejętności czynią automatyzacje bardziej utrzymywalnymi: zaktualizuj umiejętność raz, a każda automatyzacja, która jej używa, otrzymuje ulepszenie.

Krok 4: Skonfiguruj bezpieczeństwo dla zadań w tle

Automatyzacje uruchamiają się z domyślnymi ustawieniami sandboxa. Ponieważ działają nienadzorowane, konfiguracja bezpieczeństwa ma znaczenie.

Zalecane ustawienia sandboxa dla automatyzacji:

• workspace-write (domyślna rekomendacja) — pozwala Codex czytać i modyfikować pliki w projekcie. Wywołania narzędzi wymagające sieci lub dostępu poza workspace kończą się niepowodzeniem, chyba że jawnie dozwolone.
• Użyj pliku rules, aby selektywnie zezwolić na uruchamianie konkretnych poleceń poza sandboxem (na przykład zezwól na npm audit, który wymaga dostępu do sieci). Reguły znajdują się w pliku .rules w katalogu ~/.codex/rules/ i są zapisywane w języku Starlark, z użyciem prefix_rule() do dopuszczenia prefiksu polecenia.

~/.codex/rules/default.rules

# Allow `npm audit` (needs network) to run outside the sandbox in automations.
prefix_rule(
    pattern = ["npm", "audit"],
    decision = "allow",
    justification = "npm audit needs network access for vulnerability checks",
)

Przetestuj regułę, zanim na niej polegniesz, a następnie zrestartuj Codex, aby ponownie wczytał plik:

codex execpolicy check --pretty \
  --rules ~/.codex/rules/default.rules \
  -- npm audit

Uwaga

Unikaj uruchamiania automatyzacji z trybem sandboxa danger-full-access. Zadania w tle z pełnym dostępem mogą modyfikować pliki, uruchamiać dowolne polecenia i uzyskiwać dostęp do sieci bez pytania. Jeśli prompt automatyzacji jest zbyt szeroki lub niejednoznaczny, może to prowadzić do niezamierzonych zmian. Zacznij od workspace-write i selektywnie zezwalaj na konkretne polecenia za pomocą pliku rules.

Polityka zatwierdzania:

Zaplanowane zadania działają bezobsługowo z domyślnymi ustawieniami sandboxa wybranymi dla lokalnego klienta. Użyj najwęższego dostępu, który działa, i sprawdź zarządzane wymagania; operacja poza dostępną granicą kończy się błędem zamiast czekać bez końca na człowieka.

Krok 5: Zarządzaj skrzynką automatyzacji

Panel Automatyzacji na pasku bocznym aplikacji desktopowej ChatGPT w trybie Codex to twoja skrzynka. Ma sekcję Triage, gdzie pojawiają się uruchomienia automatyzacji z ustaleniami. Możesz:

• Filtrować, aby wyświetlić Wszystkie uruchomienia lub tylko Nieprzeczytane
• Kliknąć w uruchomienie, aby zobaczyć pełną konwersację i różnice
• Archiwizować uruchomienia, które obsłużyłeś
• Przypiąć uruchomienia, które chcesz zachować (to również zapobiega czyszczeniu worktree)

Zbuduj rutynę: każdego ranka sprawdź skrzynkę automatyzacji przed standupem. Obsłuż ustalenia, zsynchronizuj poprawki do lokalu i archiwizuj ukończone elementy.

Kiedy to nie działa

Automatyzacja działa, gdy nie patrzysz, i wprowadza niezamierzone zmiany. Jeśli sandbox jest ustawiony na danger-full-access, a prompt jest niejasny, Codex może modyfikować pliki w nieoczekiwany sposób. Użyj trybu workspace-write i przejrzyj kilka pierwszych uruchomień każdej nowej automatyzacji, zanim jej zaufasz. Izolacja worktree chroni twój główny checkout, ale zmiany w worktree mogą nadal być synchronizowane lub przekształcane w PR.

Nagromadzenie worktree z częstych automatyzacji. Zadania skonfigurowane z izolacją worktree tworzą worktree w tle. ChatGPT desktop domyślnie zachowuje 15 ostatnich worktree zarządzanych przez Codex; zmień limit w ustawieniach Worktree albo usuń ukończone przebiegi, których już nie potrzebujesz.

Automatyzacja zgłasza te same ustalenia każdego dnia. Jeśli błąd lintingu jest w bazie kodu od tygodni i nikt go nie naprawia, codzienna automatyzacja ciągle go zgłasza. Dodaj mechanizm ignorowania: “Skip issues listed in .automation-ignore.json. Only report new findings since the last run.”

ChatGPT desktop musi działać dla lokalnych zadań. Po zamknięciu aplikacji lub uśpieniu komputera przebieg korzystający z lokalnego folderu nie wystartuje. Włącz “Prevent sleep while running”, użyj zadania web, gdy lokalne pliki nie są potrzebne, albo wybierz Codex SDK/GitHub Action dla workflow po stronie serwera.

Co dalej

Projektowanie systemów z Codex Użyj automatyzacji obok planowania architektonicznego dla długoterminowego zdrowia bazy kodu

CI/CD z Codex GitHub Action Uzupełnij lokalne automatyzacje o automatyzację CI po stronie serwera