Agent team do budowy feature
Jak i kiedy użyć
Użyj tego prompta w Claude Code, OpenAI Codex albo innym agentowym środowisku codingowym, które ma dostęp do repozytorium i może koordynować pracę nad plikami. Najlepiej sprawdza się przy większych feature, gdzie samo polecenie napisania kodu jest zbyt ryzykowne: najpierw potrzebujesz architektury, potem backendu, frontendu i testów. W zwykłym ChatGPT albo Claude bez dostępu do kodu możesz użyć go do przygotowania specyfikacji, ale implementację trzeba będzie przenieść ręcznie do projektu.
Prompt
Chcę, żebyś stworzył zespół AI agentów do zaprojektowania i zbudowania nowego feature. Feature: [opisz feature, np. chat 1:1, panel administracyjny, system rekomendacji, płatności, onboarding, scoring leadów] Kontekst projektu: [opisz produkt, użytkowników, stack technologiczny, backend, frontend, bazę danych, autoryzację, hosting, ograniczenia i aktualne wzorce w kodzie] Working directory: [ścieżka albo moduł projektu] Stwórz 4 role: 1. architect Najpierw zaprojektuj feature. Uwzględnij cel biznesowy, user flow, data model, API endpoints, eventy, uprawnienia, edge cases, ryzyka, plan migracji danych, observability, test strategy oraz decyzję techniczną: WebSocket, polling, REST, kolejka, cron albo inny mechanizm. Architect musi zakończyć pracę tech specem i listą decyzji do zatwierdzenia. Dopóki plan architecta nie jest zatwierdzony, backend-dev i frontend-dev nie mogą implementować. 2. backend-dev Po zatwierdzeniu planu architecta dopasuj implementację do istniejącego stylu backendu. Dodaj handlery, endpointy, walidację, modele danych i integracje. Zadbaj o auth, idempotency, retries i error handling. Nie wprowadzaj nowych wzorców, jeśli istniejące wystarczą. 3. frontend-dev Po zatwierdzeniu planu architecta zaprojektuj i zbuduj UI zgodny z istniejącym stylem aplikacji. Uwzględnij loading, empty state, error state i edge cases. Zadbaj o responsywność i dostępność. Nie buduj landing page, tylko właściwy ekran feature. 4. test-dev Pracuj równolegle od początku. Na podstawie planu architecta przygotuj test cases, unit tests backendu, integration tests API, edge cases frontendu, testy regresji i minimalny plan ręcznej weryfikacji. Zasady koordynacji: Ty jesteś leadem i koordynujesz pracę agentów. Architect blokuje backend-dev i frontend-dev do czasu zatwierdzenia planu. Test-dev może pracować od początku na podstawie specyfikacji. Każdy agent raportuje status: TODO / IN PROGRESS / BLOCKED / DONE. Jeśli agent jest zablokowany, musi jasno napisać czego brakuje. Nie koduj, dopóki plan nie zostanie zatwierdzony. Na końcu przygotuj: 1. Tech spec. 2. Listę plików do zmiany. 3. Kolejność implementacji. 4. Test plan. 5. Ryzyka. 6. Pytania do właściciela produktu. 7. Definicję done. Po przygotowaniu specyfikacji oceń feature przez 5 filtrów: czy rozwiązuje realny problem użytkownika, czy da się wdrożyć mniejszym zakresem, czy wymaga migracji danych, czy zwiększa ryzyko bezpieczeństwa, czy ma jasne testy akceptacyjne. Jeśli któryś filtr nie przechodzi, zatrzymaj implementację i zaproponuj mniejszy wariant. Na końcu przygotuj też komunikat dla właściciela produktu: co dostanie użytkownik, czego nie robimy w tej wersji i jakie decyzje blokują start pracy.
Najczęstsze pytania
Kiedy używać agent team do budowy feature?
Użyj go przy większej funkcji, która wymaga architektury, backendu, frontendu i testów. Prompt jest szczególnie przydatny, gdy zwykłe polecenie napisania kodu grozi chaosem albo pominięciem ważnych decyzji.
Dlaczego rola architect blokuje implementację?
Architect ma najpierw ustalić cel, przepływ użytkownika, model danych, API, ryzyka i strategię testów. Bez tego backend i frontend mogą zacząć budować różne wersje tej samej funkcji.
Czy prompt nadaje się do małego zadania?
Do bardzo małych zmian może być zbyt ciężki. Najlepiej działa przy funkcjach z kilkoma modułami, stanami UI, uprawnieniami, integracjami albo ryzykiem regresji.
Co trzeba wkleić przed użyciem prompta?
Wklej opis funkcji, cel biznesowy, użytkownika, stack, katalog projektu, wzorce w kodzie, ograniczenia i znane ryzyka. Im lepszy kontekst, tym lepszy plan i mniej przypadkowych decyzji.
Jaki jest dobry wynik pracy agent team?
Dobry wynik to tech spec, lista plików, kolejność implementacji, plan testów, ryzyka, pytania do właściciela i definicja done. Implementacja powinna ruszyć dopiero po zaakceptowaniu planu.