# Przepływy pracy

> Zadanie po zadaniu, wywołania DevHub po kolei: odpowiedź na pytanie, zmiana kodu, śledztwo, praca z planu, zapis wiedzy.

Każdy przepływ podaje wywołania po kolei. Wszystkie identyfikatory bierz z wyników, nigdy z pamięci.

## Odpowiedz, jak lub dlaczego coś działa

1. `vault_list`, jeśli nie masz `vaultId`. Przy pytaniu o jedno repozytorium wybierz vault tego repozytorium.
2. `knowledge_search` z pytaniem. Użyj `rag_context` zamiast tego, gdy potrzebujesz opartego na źródłach kontekstu do rozumowania.
3. Przeczytaj najlepszy wynik: `knowledge_get` dla wyniku, `vault_file_read` dla ścieżki notatki.
4. Pusty wynik: `vault_overview` pokazuje, które foldery zasilają wyszukiwanie, `vault_files_search` czyta wszystkie foldery, `knowledge_index_status` mówi, czy indeks jest gotowy.
5. Kod źródłowy otwieraj dopiero po vaulcie i tylko dla tego, czego vault nie mówi. Gdy oba się różnią, rację ma kod; zapisz poprawkę (zobacz „Zapisz wiedzę”).

## Zmień kod

1. `context_pull`.
2. `workspace_list` po `workspaceId`; `vault_list` po vault.
3. `vault_overview` na vaulcie repozytorium. Potem `knowledge_search` o reguły tego repozytorium.
4. `repo_index_status`; `repo_index_refresh`, jeśli indeks jest nieaktualny.
5. `repo_symbol_search`, aby znaleźć miejsce, `repo_file` dla jego otoczenia, `repo_impact` i `repo_callers` przed zmianą sygnatury.
6. `file_read`, potem `file_replace` lub `file_edit`. Dla nowego pliku `file_create`.
7. `npm_script_list`, potem `npm_script_run` z własnym skryptem kontroli lub testów projektu.
8. `repo_index_refresh`, potem `repo_changed`, aby zobaczyć, że Twoje pliki trafiły do indeksu.
9. Podaj, co się zmieniło, i wynik kontroli.

## Zbadaj coś przed budowaniem

1. `investigation_list`. Teren mógł być już zbadany, a odrzucony wariant warto znać.
2. `investigation_create` z tytułem i repozytoriami.
3. Po każdym zakończonym kawałku badania `investigation_add`. Jeden dokument na jeden sposób zrobienia rzeczy: analiza (co jest), wariant (jak wejść), plan (co zrobić), ustalenie (co rozstrzygnięto).
4. Nie możesz zamknąć śledztwa. Napisz w odpowiedzi, że jest gotowe do zamknięcia.

## Pracuj z planu

1. `plan_ready`, bez `planId`, aby zobaczyć wszystkie plany. Nigdy nie zakładaj, że krok jest wolny, bo wygląda na następny.
2. `plan_claim` z `planId`, `stepId`. Podaj `by`, jeśli punkt końcowy Cię nie identyfikuje. Odpowiedź zawiera krok, jego wznowienie i katalog roboczy.
3. Przeczytaj zlecenie kroku i `nextSteps`. Decyzje właściciela umieszczone tam mają pierwszeństwo przed zleceniem.
4. Pracuj tylko w katalogu roboczym, który zwrócił claim.
5. Przy długim kroku wywołuj `plan_renew`. Claim, którego nikt nie odnawia, wygasa, a krok trafia do kogoś innego.
6. Zrób commit z trailerem kroku, potem `plan_close` z sha commitów. Scala katalog roboczy i zapisuje, co weszło. Użyj `as: "withdrawn"` dla kroku, który się nie wydarzy; nic nie jest scalane.
7. `step_log` na koniec każdego podejścia, także nieudanego: co zrobiono i co dalej. `step_update`, jeśli zmienił się status lub następne kroki.

> **Ostrzeżenie:** Dokładna postać trailera kroku w komunikacie commitu (wiersz z identyfikatorem kroku) i to, co
> liczy się jako commit „za” krokiem, pochodzą z ekranu Plany i nie są potwierdzone.

Aby samemu otworzyć plan: `plan_create`, gdy śledztwo ustaliło, co robić, potem `step_add` dla każdego kawałka. Rozmiar kroku dobierz tak, by wszedł jako jeden commit. Wskaż kroki, na które czeka (bramki), i pliki, których dotyka (zakres).

## Zapisz wiedzę

1. `vault_overview` lub `vault_files_search`, aby znaleźć miejsce notatki i sprawdzić, czy już istnieje. Ścieżkę weź z wyniku.
2. `vault_file_replace`, aby poprawić notatkę, `vault_file_create` dla nowej. Vault musi zezwalać na zapis przez MCP.
3. `knowledge_index_refresh`, jeśli `knowledge_search` jeszcze nie zwraca Twojej notatki.
4. Coś poszło źle i powód warto opisać: `learning_note`, jedna notatka na lekcję. Trwały fakt o pracy lub użytkowniku: `memory_note`.

## Zapytaj innego agenta

1. `agent_list`. Pokazuje każdego agenta, klienta, który go uruchamia, i to, czy w ogóle może działać.
2. `agent_run` z `agentId` i `task`. Po 45 sekundach może odpowiedzieć `RUNNING <runId>`. To nie jest porażka.
3. `agent_run_status` z `wait`. Nie uruchamiaj zadania ponownie.

## Sprawdź, co zrobiono

- `audit_summary` dla pytania „czy teraz coś nie działa”, `audit_list` dla jednego nieudanego wywołania.
- `display_screenshot` po `display_list`, aby zobaczyć wynik na ekranie, jeśli użytkownik na to pozwala.

## Powiązane

- [Użycie narzędzi](/pl/devhub/for-agents/mcp-tools/index.md)
- [Błędy](/pl/devhub/for-agents/errors/index.md)
- [Plany](/pl/devhub/features/plans/index.md)