Przepływy pracy

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

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ę”).

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.

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.

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.

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).

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.

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.

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

• Użycie narzędzi
• Błędy
• Plany