Często zadawane pytania

Deep Work Plan zamienia repozytorium w uporządkowane środowisko, w którym agent kodujący może niezawodnie realizować długą pracę. Instaluje się jako skill agenta i jednorazowo onboarduje repozytorium (indeks `AGENTS.md`, drzewo `docs/`, zestaw `.agents/` ze skillami i poleceniami, obszar wyjściowy `.dwp/` wykluczony przez gitignore); od tego momentu każdy cel staje się planem: atomowe zadania, każde z kryteriami akceptacji i bramką walidacji, wykonywane pojedynczo, commitowane po przejściu i wznawialne z dysku przez dowolnego agenta. Plan kończy się Final Review, który audytuje bezpieczeństwo i waliduje stan końcowy. Metodyka jest na licencji MIT i działa z każdym agentem kodującym, który czyta repozytorium.

Przeczytaj metodykę

Dla programistów i zespołów, które przekazują agentom kodującym realną, wieloetapową pracę i chcą, by została dokończona. Pasuje, gdy zadanie obejmuje więcej niż jedną sesję, więcej niż jedną rodzinę plików lub więcej niż jednego agenta; gdy członek zespołu musi móc kontynuować od miejsca, w którym agent się zatrzymał; lub gdy „gotowe” musi oznaczać „zweryfikowane”, a nie „agent tak twierdzi”. Jednoliniowa poprawka nie wymaga planu — i metodyka to mówi wprost: reguła proporcjonalnej rygorystyczności zaleca zamiast tego cel, kryteria i bramkę inline.

Szybki start

Wybór reprezentacji, a nie kompromis rygoru. Plany są domyślnie Lite: zwarty README z zakotwiczonymi zapisami zadań, który jest już wykonywalny, a nie częściowym szkicem. Jeśli od razu poprosisz o plan Full, `create` zapisuje bezpośrednio pliki zadań Full; a kiedy szczegółowość instrukcji, zależności lub kontrakty zadania przestają mieścić się w zwartym, możliwym do przejrzenia zapisie, rozwija plan do Full. Późniejsza promocja zachowuje każde ukończone zadanie. Oba formaty niosą te same kryteria akceptacji, bramki walidacji, dowody i obowiązkowy Final Review.

Przeczytaj metodykę

Metodyka zapakowana jako instalowalny skill. Nie ma serwera, konta, formatu zastrzeżonego ani środowiska uruchomieniowego poza agentem kodującym, którego już używasz. Instalowane są instrukcje czytane przez agenta, niewielki zestaw skryptów shell do wykrywania kontekstu i sprawdzania zgodności oraz konwencje przyjęte przez repozytorium. Wszystko, co plan produkuje, to Markdown i JSON w repozytorium — czytelne bez żadnego narzędzia.

Przeczytaj specyfikację

Z każdym agentem, który czyta pliki repozytorium. Skill podąża za otwartym standardem Agent Skills i konwencją `AGENTS.md`, więc Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot i inne przejmują go przez zwykłe ładowanie skilli i instrukcji. Własna ewaluacja metodyki pokazuje plan rozpoczęty przez agenta jednego dostawcy i wznowiony przez agenta innego — w obie strony. Pokrycie instalacji i dowody behawioralne są wymienione per agent w macierzy kompatybilności, a oba aspekty nigdy nie są mieszane.

Przejrzyj zestaw

Trzy kroki. Najpierw zainstaluj skill Deep Work Plan w swoim agencie kodującym — najszybsza ścieżka to `npx skills add DailybotHQ/deepworkplan-skill` (lub sklonuj repozytorium skilla i uruchom `./setup.sh`). Następnie jednorazowo wprowadź repozytorium do onboardingu, aby agent dostosował `AGENTS.md`, `docs/`, zestaw `.agents/` i obszar `.dwp/` ignorowany przez git do twojego stacku: wskaż https://deepworkplan.com/init.md lub uruchom `/deepworkplan-onboard`. Na koniec planuj i wykonuj pracę za pomocą lekkich poleceń: `/dwp-create <goal>` buduje plan; `/dwp-execute` uruchamia go zadanie po zadaniu wobec każdej bramki; `/dwp-refine` edytuje plan w toku (zakres, zadania lub promocję planu Lite do Full); `/dwp-resume` kontynuuje po przerwie; `/dwp-status` raportuje postęp bez wykonywania; `/dwp-verify` tworzy obiektywny raport zgodności; `/dwp-upgrade` przenosi zainstalowanego skilla na nowszy release bez dotykania istniejących planów. Agenci przechwytujący `/` często używają zamiast tego `#` (na przykład `#dwp-execute`). Endpoint adopcji i szybki start przechodzą tę samą ścieżkę bardziej szczegółowo.

Szybki start

Skill agenta jest instalowany tam, gdzie twój agent ładuje skille projektu lub użytkownika. Onboarding następnie dostosowuje samo repozytorium: tworzy lub uzgadnia `AGENTS.md`, `docs/`, `.agents/` oraz obszar roboczy `.dwp/` wykluczony przez gitignore. Skill uczy agenta metody; repozytorium przechowuje kontekst, zestaw i dowody planu, których potrzebują inni agenci, by kontynuować.

Zobacz przepływ adopcji

Git jest zalecany dla repozytoriów, ponieważ jego historia jest częścią powierzchni odzyskiwania i przeglądu, ale metodyka może też działać w przestrzeni roboczej agenta bez repozytorium Git. W takim przypadku wymagana jest maszynowo czytelna warstwa stanu, obejmująca punkty kontrolne `state.json` i zapisy bramek, aby odzyskiwanie nie zależało od transkryptu czatu.

Przeczytaj o archetypach repozytoriów

Skill opisuje, jak agent wykonuje powtarzalną procedurę. Plan DWP opisuje konkretną zmianę poprzez zakres, kryteria akceptacji, bramki walidacji i dowody. Specyfikacja produktu opisuje bieżące zachowanie produktu i ewoluuje poprzez delty po wdrożeniu; skille i plany też są specyfikacjami, ale opisują procedury i zmiany, a nie utrzymują ten kanoniczny kontrakt produktu.

Przeczytaj specyfikację

To wykonywalne asercje, które agent uruchamia sam. Zatwierdzenie przez człowieka ramuje przebieg: osoba zatwierdza plan przed wykonaniem i przegląda końcowy diff przy pull requeście; wykonanie między tymi punktami jest autonomiczne. Każde zadanie wymienia konkretne polecenia, zwykle własną bramkę jakości repozytorium, wybrane z dotkniętej powierzchni zadania: testy zmienionego zachowania i jego konsumentów, rozszerzone do pełnej suity, gdy zmiana jest współdzielona lub nie da się jej ograniczyć. Zadanie jest oznaczone jako ukończone tylko wtedy, gdy te polecenia zakończą się sukcesem, a zadania zmieniające zachowanie muszą rozszerzyć testy. Przy niepowodzeniu agent najpierw naprawia to, co mieści się we własnym zakresie zadania, i ponawia bramkę; niepowodzenie, którego nie da się naprawić w tym zakresie, zostawia zadanie oznaczone jako zablokowane i zatrzymuje przebieg.

Pętla rdzeniowa

Na trzech frontach. Zadania są pisane jako zachowanie, nie jako edycje: kryterium akceptacji mówi, co system musi robić, więc zmiana nazwy pliku lub podmiana implementacji go nie unieważnia. Każda bramka uruchamia się ponownie na repozytorium w jego aktualnym stanie; złamane założenie przy następnym przebiegu kończy się głośnym błędem zamiast cichego dryfu, a to niepowodzenie jest sygnałem do doprecyzowania. Utrzymanie dokumentacji w synchronizacji jest częścią pracy: zadanie zmieniające zachowanie aktualizuje też docs i zestaw skierowany do agentów, które to opisują, w ramach własnej bramki. Każdy przebieg powinien zostawić repozytorium bardziej gotowe dla agentów niż zastał.

Przeczytaj metodykę

Tak — doprecyzowanie częściowo wykonanego planu jest pełnoprawną operacją. Definicje zadań i stan wykonania są rozdzielone: plan to checklista na dysku plus mały plik stanu, więc to, co zrobione, pozostaje zapisane niezależnie od tekstu zadania. Gdy zadanie okaże się błędne, agent oznacza je jako zablokowane i zatrzymuje się, zamiast iść dalej. Następnie edytujesz, zmieniasz kolejność, dzielisz lub usuwasz zadania, które jeszcze nie ruszyły, podczas gdy ukończone zostają ukończone. Wznowienie odbudowuje stan z dysku i faktycznego repozytorium i ponownie uruchamia istotne bramki, więc nic, co się pod spodem przesunęło, nie przejdzie niezauważone.

Pętla rdzeniowa

Plan jest ciągłą kontrolą. Agent pracuje nad jednym małym zadaniem naraz i musi zwalidować przed przejściem dalej — może zboczyć o jeden krok, nie o trzy. Każde zadanie niesie kryteria akceptacji plus dokładne polecenia, które je dowodzą, a postęp jest zapisywany w repozytorium w trakcie pracy, ze statusem per zadanie, więc dryf staje się widoczny dla ciebie, następnej sesji i następnego agenta. Plan nie jest ukończony, dopóki wszystko nie przejdzie walidacji — w tym Final Review. Uczciwy zastrzeżenie: metodyka nie może powstrzymać agenta od napisania słabego kryterium akceptacji na początku; sprawia, że dryf jest głośny zamiast cichy.

Pętla rdzeniowa

Ani jedno, ani drugie. Jest generowany raz z celu, a potem utrzymywany jako część pracy. Plan celowo nie jest przepisywany z diffów kodu, bo specyfikacja goniąca kod staje się opóźnionym lustrem — dokładnie tym dryfem, który metodyka istnieje, by wyeliminować. Ewoluuje celowo: bramki uruchamiają się ponownie na aktualnym repozytorium, nieudana bramka wyzwala doprecyzowanie, a agent wykonuje je w trakcie przebiegu, podczas gdy ty zatwierdzasz z góry i przeglądasz na końcu. Dokumentacja i testy rozwijają się wraz z kodem z definicji, bo ich aktualizacja jest w bramce każdego zadania.

Przeczytaj metodykę

Postęp żyje na dysku, nie w czacie. Checkboxy README, log każdego zadania, ograniczony indeks roboczy i maszynowo czytelny plik stanu są aktualizowane na każdej granicy zadania, a plik stanu rejestruje punkt kontrolny przed każdą planowaną pauzą. Nowa sesja lub inny agent czyta ten zwarty indeks, uzgadnia go z repozytorium i historią git i kontynuuje od pierwszego nieukończonego zadania bez powtarzania gotowej pracy. Nawet przerwane tworzenie planu jest odzyskiwalne: tożsamość planu i zamierzona lista zadań są zapisywane przed jakimkolwiek plikiem zadania, więc półutworzony plan można dokończyć lub odrzucić, zamiast zgadywać.

Pętla rdzeniowa

Jedynym obowiązkowym zadaniem zamykającym każdy plan. Kolejno: przejście bezpieczeństwa przez pełny skumulowany zestaw zmian planu, w tym wymagany lokalny przegląd diffu przez skill AI Diff Reviewer, przy czym krytyczne ustalenia blokują ukończenie do czasu naprawy lub wyraźnej akceptacji; walidacja stanu końcowego, czyli pełne odpowiednie suity testów, lintu, sprawdzania typów i formatowania repozytorium na końcowym kodzie; oraz uzgodnienie decyzji o skillach zarejestrowanych przez każde zadanie. Agent następnie raportuje rezultaty, dowody i ograniczenia oraz jednorazowo oferuje Executive Report, generując go tylko na żądanie.

Specyfikacja

Nieudana bramka to najpierw sygnał do naprawy: agent naprawia to, co mieści się we własnym zakresie zadania, i ponawia bramkę. Niepowodzenie wykraczające poza ten zakres zostawia zadanie zapisane jako zablokowane, a agent zatrzymuje się przed zgłoszeniem ukończenia. Możesz sprawdzić dowody, naprawić kod lub doprecyzować zadanie, a następnie wznowić; nieudane polecenie jest sygnałem do rozwiązania niezgodności, a nie pozwoleniem na osłabienie bramki.

Przeczytaj protokół agenta

Mówi to wprost. Sprawdzacz kończy z kodem wyjścia 2 i jednoznacznym werdyktem `UNVERIFIED` — nigdy nie wypisuje zaliczenia, którego faktycznie nie zweryfikował. Gdy w środowisku brakuje zdolnego interpretera albo sprawdzenie nie może się uruchomić, uczciwy wynik to «niezweryfikowano», nie «zgodny»; zielony wynik zawsze oznacza, że każde sprawdzenie się wykonało i przeszło. Ta sama dyscyplina przenika całą metodykę: żaden przepływ nie osłabia ani nie fałszuje bramki, żeby ogłosić ukończenie.

Kontrakt zgodności

Tak, gdy plan został wcześniej zatwierdzony, niesie wymaganą warstwę stanu i daje agentowi ograniczone uprawnienia. Przebieg bez nadzoru musi się zatrzymać i zapisać blokadę, gdy rzeczywistość odbiega od planu, bramka zawiedzie poza planowanym zakresem naprawy lub potrzebne jest nowe zatwierdzenie bądź poświadczenie.

Przeczytaj protokół pracy bez nadzoru

Tak — archetyp huba-orkiestratora istnieje dokładnie po to. Repozytorium huba trzyma plan koordynujący, a każde repozytorium dziecko uruchamia własny plan we własnym odizolowanym obszarze `.dwp/`, więc dziecko nigdy nie zapisuje do stanu planów huba. Kompletność dziecka jest odczytywana z top-levelowego stanu jego własnego planu, nie przez dopasowywanie stringów w jego wnętrzu, a hub zapisuje, gdzie jest, zanim dokądkolwiek przejdzie. Każde dziecko pozostaje zwykłym repozytorium DWP, które można pilotować także samodzielnie.

Archetypy repozytoriów

Rozwiązują sąsiednie problemy. Narzędzia spec-driven doskonale uchwytują, co powinno się zmienić: specyfikacje, wymagania i propozycje zmian w powtarzalnej formie. Deep Work Plan dotyczy tego, jak agent wykonuje pracę godzinami bez dryfu: onboardowany harness, bramki walidacji per zadanie wybrane z dotkniętej powierzchni, wznawialny stan na dysku, obowiązkowy Final Review z przejściem bezpieczeństwa i sprawdzacz zgodności dla samego repozytorium. Oba podejścia można połączyć — specyfikacja lub propozycja zmiany zasila plan. Strona porównania układa możliwości obok siebie, w terminach każdego narzędzia.

Zobacz porównanie

Frameworki przepływu pracy dla agentów, takie jak BMAD, Superpowers i Get Shit Done, wnoszą silne style pracy: role, zasady, kroki test-first, nawyki weryfikacji. Gentle-AI znajduje się w sąsiedniej kategorii jako konfigurator ekosystemu agentów: wyposaża agentów kodujących, których już używasz, w trwałą pamięć między sesjami (Engram), wyselekcjonowane skille, persony, serwery MCP, opcjonalny Spec-Driven Development i opcjonalną recenzję opartą na dowodach (Receipt-Driven Development), zapisując w katalogach konfiguracyjnych każdego agenta. Deep Work Plan różni się od obu: skupia się na tym, co pozostaje w repozytorium i co można sprawdzić — harness, który każdy agent odczyta bez wcześniejszego kontekstu, pliki zadań z kryteriami akceptacji i bramkami, stan, który przetrwa sesję, weryfikator zgodności z kodem wyjścia przyjaznym dla CI oraz publikowany pomiar liczby bajtów instrukcji ładowanych przez każdy przepływ. Jest niezależny od narzędzia z założenia i nie dodaje do głównej pętli żadnej usługi, dostawcy ani sekretu. Warstwy mogą współistnieć: frameworki i Gentle-AI kształtują sposób pracy agenta; Deep Work Plan sprawia, że długa praca jest trwała i możliwa do zweryfikowania w repozytorium. Strona porównania pokazuje, gdzie każde podejście jest wbudowane, opcjonalne lub poza zakresem.

Zobacz porównanie

Wbudowane tryby planowania są przydatne, a Deep Work Plan buduje na tym samym podłożu: konwencji `AGENTS.md` i otwartym standardzie Agent Skills. Różnica polega na tym, gdzie żyje plan i co go egzekwuje. Natywne plany zwykle żyją poza repozytorium i wygasają z sesją; Deep Work Plan zapisuje plan, jego stan i dowody w repozytorium, więc inny agent lub członek zespołu może go kontynuować, a każde zadanie niesie wykonywalną bramkę i zarejestrowany log. Tryb planowania agenta nadal używasz do myślenia; metodyka dodaje trwałą, weryfikowalną pętlę wykonania.

Zobacz porównanie

Onboarding jest niedestrukcyjny: wykrywa istniejący `AGENTS.md`, `docs/`, `.agents/` lub `CLAUDE.md`, uzgadnia zamiast nadpisywać i pyta przed zastąpieniem czegokolwiek. Zapisuje indeks `AGENTS.md` z realnymi poleceniami, przemyślane drzewo `docs/`, dokumentację per moduł, zestaw `.agents/` z cienkimi poleceniami `dwp-*`, obszar wyjściowy `.dwp/` wykluczony przez gitignore, zweryfikowaną mapę testów i wymagany lokalny przegląd kodu (skill AI Diff Reviewer plus rozszerzenie przeglądu dopasowane do repozytorium). Następnie uruchamia samosprawdzenie i sprawdzacz zgodności, aby pokazać, co zostało wyprodukowane. Repozytorium onboardowane pod wcześniejszym standardem dostaje ukierunkowany upgrade harnessu, który uzgadnia tylko to, czego brakuje lub co jest przestarzałe.

Endpoint adopcji

Są tu dwie różne aktualizacje i przepływ trzyma je osobno. Harness repozytorium — `AGENTS.md`, `docs/`, zestaw `.agents/` — jest uzgadniany ponownym przebiegiem onboardingu, który uzupełnia tylko to, czego brakuje lub co jest przestarzałe. Sam skill rusza dalej przez `/dwp-upgrade`: sprawdzenie najnowszego opublikowanego release’u w trybie tylko do odczytu, instalacja dokładnego taga, który zaakceptowałeś, zweryfikowana, a potem onboarding ponownie jak świeże przejście. Przepływ w każdym kroku wymaga wyraźnej zgody, lokalne adaptacje są porównywane diffem i zachowywane zamiast nadpisywane, a `.dwp/` nigdy nie jest migrowany — istniejące plany zachowują zapisany kształt i działają dalej.

Endpoint adopcji

Tak. Dodatki są warstwami opcjonalnymi, a repozytorium bez żadnego z nich jest w pełni zgodne z DWP. Devcontainery, raportowanie Dailybot, aktualizacje zależności, wsparcie systemu projektowego i opcjonalny przegląd CI są oferowane tylko wtedy, gdy pasują do twojego repozytorium i wyraźnie je akceptujesz.

Przejrzyj dodatki

DWP nie traktuje braku łańcucha narzędzi jako wolnej przepustki. Podczas onboardingu agent proponuje konfigurację walidacji dopasowaną do stosu, zapisuje polecenia w dokumentacji repozytorium i używa tych poleceń jako celu dla przyszłych bramek; propozycja pozostaje widoczna do przeglądu.

Przeczytaj protokół agenta

Metodyka i skill są na licencji MIT i bezpłatne; nie ma usługi, klucza API ani telemetrii w przepływach rdzeniowych. Wydajność jest raportowana jako liczba bajtów instrukcji, które każdy przepływ ładuje **na wejściu** — jego pakiet na początku sesji — publikowana razem z nazwanymi **ścieżkami end-to-end**, które dodają to, co ładują właściwe wyzwalacze przepływu, gdy praca faktycznie jest kontynuowana (na przykład wznowienie, które przechodzi do wykonania, zazwyczaj ładuje kilkukrotność swojego pakietu wejściowego). Żadna z tych dwóch liczb nie ogranicza sesji: rzeczywiste uruchomienie czyta też własne pliki repozytorium, wynik narzędzi i pliki robocze planu, których ten rejestr nie liczy. Obie liczby są mierzone skryptem commitowanym ze skillem, ponownie mierzone na każdej linii bazowej release’u i publikowaną w rejestrze ewaluacji, przy czym wzrosty są raportowane tak samo otwarcie jak spadki. Nie jest raportowana jako procenty tokenów ani oszczędności kosztów, bo inwentaryzacja bajtów tego nie dowodzi. Publiczna ewaluacja na świeżych agentach została już przeprowadzona według zamrożonego protokołu: te same dwa featury zbudowane z czystych klonów bez harnessu, z poprzednią wersją główną i z obecną. Wykazała, że agenci na drzewie z harnessem czytali mniej bajtów w obu zadaniach, a sesje featurów obecnej wersji zużywały mniej wejścia i wyjścia modelu niż poprzedniej wersji głównej w obu zadaniach — tak, jak zaraportował harness, na pojedynczym obciążeniu. Wykazała też uczciwe ograniczenia: onboarding to jednorazowy koszt, który zwraca się tylko wtedy, gdy przepływy są używane; netto-kierunek tokenów na obciążenie był mieszany; nie rości się żadnej przewagi czasu zegarowego; a świeży agent nie wchodzi w przepływy sam z siebie — przepływy to komendy wywoływane przez Ciebie lub przez agenta, który wie, jak je wywołać.

Zaufanie i ujawnianie