Zacznij tutaj

DevHub to aplikacja desktopowa. Jej serwer MCP daje Ci narzędzia do czterech rzeczy: vaulty wiedzy (notatki o tym, jak i dlaczego praca jest wykonywana), indeks repozytorium (symbole, wywołujący, wpływ zmiany), plany i śledztwa (praca podzielona na kroki, które bierzesz po jednym) oraz pliki i skrypty w repozytoriach, do których masz dostęp.

Używaj tych narzędzi zamiast własnego przeszukiwania. Vault zwykle ma już odpowiedź na pytania „jak” i „dlaczego”, a indeks odpowiada na „gdzie to jest” i „co się zepsuje” bez czytania każdego pliku.

1. Użytkownik uruchamia serwer MCP w DevHub. Działa on tylko, gdy trwa sesja. Zobacz Serwer MCP.
2. Użytkownik kopiuje adres MCP z Pulpitu (karta serwera MCP, Kopiuj adres MCP) i wkleja go w kliencie albo używa Skonfiguruj folder na stronie Instalacje harnessów, aby DevHub zapisał pliki klienta. Zobacz Podłączenie klienta AI.
3. Nie znasz adresu i nie możesz go odgadnąć. Jeśli brakuje narzędzi DevHub na liście narzędzi, powiedz użytkownikowi, by uruchomił serwer MCP i podłączył klienta. Nie szukaj adresu w plikach.
4. Klient może pokazywać narzędzia DevHub tylko z nazwy. Załaduj schemat narzędzia, zanim je wywołasz.

Gdy chcesz	Wywołaj	Zamiast
zacząć zadanie	context_pull (użytkownik mógł zakolejkować dla Ciebie notatki i symbole)	szukać od razu
wiedzieć, których repozytoriów możesz dotykać	workspace_list	zgadywać workspaceId
wiedzieć, które vaulty możesz czytać lub zapisywać	vault_list	zgadywać vaultId
zobaczyć, co zawiera vault	vault_overview	przechodzić po folderach
dowiedzieć się, jak lub dlaczego coś działa	knowledge_search w vaulcie repozytorium	czytać najpierw kod
znaleźć notatkę po słowach w niej albo jej ścieżkę	vault_files_search	budować ścieżkę z tytułu
przeczytać notatkę	vault_file_read ze ścieżką z listy lub wyszukiwania	otwierać pliki z dysku
poznać kształt bazy kodu	repo_overview	przechodzić po folderach
znaleźć funkcję, klasę lub plik	repo_symbol_search	files_search dla definicji
dowiedzieć się, kto coś wywołuje	repo_callers	grep po nazwie
dowiedzieć się, co zmiana zepsuje	repo_impact	czytać każdego wywołującego
znaleźć tekst, ustawienie lub komentarz	files_search	powłokę
zmienić plik	file_replace lub file_edit	file_write na istniejącym pliku
sprawdzić zmianę	npm_script_run z zadeklarowanym skryptem, potem repo_changed	powiedzieć, że gotowe
zbadać coś przed budowaniem	investigation_list, potem investigation_create	notatki w odpowiedzi
wykonać pracę dłuższą niż jeden commit	plan_ready, plan_claim, potem krok	listę zadań w odpowiedzi
zapisać, co poszło źle	learning_note	milczenie
zapisać, jak użytkownik chce, by praca była wykonywana	memory_note	milczenie
znaleźć istniejący skill, regułę lub personę	library_list	pisać własne
zapytać innego skonfigurowanego agenta	agent_list, potem agent_run	robić to dwa razy

1. context_pull. Opróżnia kolejkę; użyj context_get, jeśli ktoś inny nadal jej potrzebuje.
2. workspace_list i vault_list, jeśli nie masz workspaceId i vaultId. Bierz je z wyników. Nigdy ich nie wymyślaj.
3. vault_overview na vaulcie repozytorium, zanim zmienisz kod.
4. knowledge_search z pytaniem, zanim otworzysz kod źródłowy.
5. repo_index_status. Jeśli indeks jest nieaktualny lub go brak, repo_index_refresh. Potem narzędzia repo_*.
6. Pracujesz z planu? Najpierw plan_ready. Nigdy nie zakładaj, że krok jest wolny, bo wygląda na następny.

Szukanie w vaulcie: vault_list daje vaultId; potem knowledge_search z { "vaultId": "<id>", "query": "jak działa X" }. Wynik przeczytasz przez knowledge_get (id) lub vault_file_read (vaultId, path z wyniku). Gdy nic nie znajdzie, spróbuj vault_files_search.

Szukanie kodu: workspace_list daje workspaceId; potem repo_index_status i repo_symbol_search z { "workspaceId": "<id>", "query": "nazwa" }.

Wzięcie kroku planu: plan_ready wylistuje wolne kroki; potem plan_claim z { "planId": "<id>", "stepId": "<id>", "by": "<Twoja nazwa>" }. Pracuj w zwróconym katalogu roboczym, zrób commit, potem plan_close z sha commitów i step_log z opisem, co zrobiono. Zobacz Przepływy pracy.

• Podawaj vaultId w każdym wywołaniu vault_* i workspaceId w każdym wywołaniu file_*, repo_* i npm_*.
• Bierz ścieżki z listy lub wyniku wyszukiwania, nie z tytułu.
• Najpierw czytaj, potem zapisuj. file_edit i vault_file_edit wymagają expectedHash i numerów linii z odczytu.
• Błąd mówi, co poprawić. Popraw argument i wywołaj ponownie. Zobacz Błędy.
• Zanim powiesz, że praca jest skończona, uruchom własne kontrole projektu i obejrzyj wynik.

• Użycie narzędzi
• Przepływy pracy
• Ograniczenia