Worker Board

A VS Code side-panel extension showing every AI task running right now, in one place: Claude Code sessions and subagents, plus external Spark (muse) and Codex workers. Rozszerzenie VS Code z panelem w pasku bocznym, pokazującym w jednym miejscu wszystkie zadania AI wykonywane w tej chwili: sesje i subagentów Claude Code oraz workery zewnętrzne Spark (muse) i Codex.

English | Polski

The extension is free and available on the Visual Studio Marketplace: code --install-extension dtcode.worker-board.

What it is

A VS Code extension with a side-panel showing, in one place, every AI task running right now: Claude Code sessions and subagents, and the external Spark (muse) and Codex workers. The panel is read-only — it never launches a worker; the only mutating actions are killing a process by PID and deleting the files of finished heartbeats.

What it shows:

• Claude Code main sessions and subagents (read from ~/.claude/projects transcripts),
• Spark and Codex workers (read from ~/.claude/worker-status heartbeats),
• for each task: model, effort, git branch, current tool, context and token usage — wherever that can reliably be determined from the source file.

What a row shows

The panel has no per-engine section, and no separate section for waiting sessions. The layout is a single tree rooted in the conversation: the root of each branch is a Claude Code session, and beneath it — indented one fixed step per level — hang all of its subtasks regardless of engine: Claude subagents and Spark/Codex workers pinned by sessionId (see CRITICAL: how to use it). A session stays visible in the tree even when it isn't doing anything itself, as long as it has at least one visible child — otherwise starting a single worker would collapse the whole branch. At the end of the tree sits the fallback group "Unassigned" for workers that can't be pinned to any visible conversation. The panel header carries a single number — the total count of visible tasks across the whole tree, not a sum per section (since there's no longer a section per engine).

A single row consists of:

The context bar's color is a signal, not decoration — thresholds are inclusive (>=):

The context window size (the bar's denominator) isn't present in the transcript — it comes from the workerBoard.contextWindowTokens setting (see Configuration); it's never read from any session file.

Statuses

The panel shows only tasks in one of two visible states — everything else (finished, inactive, abandoned) is hidden; the panel is not a history log.

Rule for determining status (positive evidence from the transcript, never a guessed activity-time threshold):

• w toku (in progress) — the last assistant message has stop_reason: tool_use, and either (a) that specific tool call has no result yet (tool_result) in the file, or (b) the turn is still formally open (same stop_reason: tool_use condition, no newer user message) and the transcript file was written to within the last 60 seconds. The second case covers the window where the model is composing its next step — momentarily there's no unpaired tool call in the file, but a fresh write to disk proves the session is working.
• czeka (waiting) — the assistant closed its turn (a terminal stop_reason: end_turn, stop_sequence, or max_tokens) and there's no newer user message after it.
• a deliberately hidden state — "the user sent a message, but nothing has been produced yet." From the transcript file alone there's no way to tell a model that's currently thinking apart from a message sitting queued with no reaction at all — the panel prefers to show nothing rather than guess either way.

Subagents and workers (Spark/Codex) never get the czeka (waiting) status — that status exists only for Claude Code main sessions.

"czeka (waiting)" is no longer a separate section — it's a row state. A waiting session sits in the tree exactly where its place in the conversation puts it (the root of its branch), just dimmed (reduced opacity) and with a frozen counter for X min — unlike w toku (in progress) tasks, whose counter ticks every second, this one stands still because the session isn't doing anything anymore.

Requirements

Requirements split by level — see Installation for what each level means.

Node.js, npm and @vscode/vsce are not needed to install or run the extension from the Marketplace — they only matter if you build it yourself. A missing Spark/Codex requirement doesn't break anything else: the rest of the panel keeps working, that worker's rows just never appear.

Installation

Worker Board has two independent levels. Almost everyone only needs Level 1.

Level 1 — Claude Code sessions and subagents (Marketplace install)

This is the default path and the only thing most people need.

1. Install the extension:
   • from VS Code: open Extensions, search for Worker Board, click Install; or
   • from a terminal: code --install-extension dtcode.worker-board.
2. Ctrl+Shift+P → Developer: Reload Window.
3. Click the Workery icon in the activity bar.
4. Verify: View → Output → pick the Worker Board channel — an entry Worker Board <version> uruchomiony ("Worker Board started") should appear. That's the only reliable way to confirm which version is actually running.

Nothing else needs installing or configuring at this level. The panel reads Claude Code sessions and subagents straight from ~/.claude/projects, with no wrapper script and no extra setup involved. The only requirements are VS Code (1.96.0+) and a Claude Code you're already using — Node.js and npm are not needed here (see Requirements).

If the panel looks empty right after installing, that's most likely correct, not a bug: it only ever shows tasks that are currently running or sessions waiting for a reply. A quiet moment with nothing in flight looks empty by design — see Statuses.

Level 2 — Spark and Codex workers (needs the wrapper)

Skip this unless you actually run Spark (muse) or Codex workers and want them to show up in the panel too. In one sentence: Spark leaves no trace on disk, and Codex writes no completion marker, so the panel needs the state records that only the worker-run.ps1 wrapper writes — see CRITICAL: how to use it.

There are two ways to get the wrapper and the skill in place:

A. Via the installer (recommended)

git clone https://github.com/DTCodePL/WorkerBoard.git
cd WorkerBoard
powershell -File install.ps1

This route additionally requires Node.js >= 20 (recommended: 26) and npm, because the installer builds the extension from source (npm ci/npm install → npm run build → npx @vscode/vsce package) before installing it — and it replaces the Marketplace build with your own build.

The script runs on the Windows PowerShell 5.1 that ships with every Windows install — no separate PowerShell 7 setup is required. If PowerShell 7 (pwsh) is installed, pwsh -File install.ps1 works identically.

The script, in order: checks requirements (see above), builds the package, installs the extension in every detected VS Code edition, and deploys two dependencies that live outside the repository into ~/.claude/ (see the CRITICAL: how to use it section). Once it's done, reload the window and verify the same way as in Level 1 above.

Switches:

• -SkipBuild — skips npm ci/build/vsce package and installs the newest (by modification time) .vsix file already present in the repository directory. Useful when the package was built moments earlier.
• -DryRun — prints the full plan of action (detected requirements, what would be built/installed/overwritten), changing nothing on disk.

The installer is idempotent — rerunning it against an unchanged repository and ~/.claude/ state gives the same outcome (aside from the repeated uninstall+install of the extension, which VS Code performs on every run regardless, since it can keep the old copy when the version number hasn't changed).

B. Manually, no cloning, no Node.js

For anyone who wants to keep the Marketplace build and add only the two missing pieces. Download these two files from the repository and place them at:

• deploy/claude/bin/worker-run.ps1 → %USERPROFILE%\.claude\bin\worker-run.ps1
• deploy/claude/skills/external-workers/SKILL.md → %USERPROFILE%\.claude\skills\external-workers\SKILL.md

then create the (empty) directories %USERPROFILE%\.claude\worker-status and %USERPROFILE%\.claude\worker-status\logs. No Node.js, no npm, no vsce — the Marketplace build of the extension is left untouched.

Either route, Spark and Codex workers still MUST be launched through the wrapper to show up in the panel — see CRITICAL: how to use it.

CRITICAL: how to use it

Spark and Codex MUST be launched through ~/.claude/bin/worker-run.ps1. Calling raw wsl.exe/codex.cmd directly, bypassing the wrapper, still starts the worker correctly, but the Worker Board panel won't see it at all — neither that it's running nor that it finished.

Reason: Spark leaves no trace on disk beyond ~/.config/muse (just auth.json/settings.json/trust.json, zero session history), and Codex writes no marker of a run's completion at all. The wrapper fixes this itself — it writes and closes a state record in ~/.claude/worker-status/<id>.json, plus a full log in ~/.claude/worker-status/logs/<id>.log, for the entire duration of the run.

Pinning a worker to a conversation is automatic. The state record carries a sessionId field, which the panel uses to attach the worker under the right tree branch (see What a row shows). The wrapper fills it in on its own from the CLAUDE_CODE_SESSION_ID environment variable, inherited by the child process — nothing needs to be passed by hand. The field is optional: records written before this mechanism existed, and workers launched outside Claude Code (without that variable in the environment), don't have it and land in the "Unassigned" group.

The installer also deploys a modified version of the Claude Code skill external-workers (~/.claude/skills/external-workers/SKILL.md) — thanks to it, Claude Code calls the wrapper itself whenever it delegates work to Spark or Codex; you don't have to remind it every conversation.

Spark (muse) — via WSL:

C:\Users\<username>\.claude\bin\worker-run.ps1 `
  -Engine spark `
  -Title "Short description shown on the card in the panel" `
  -BriefFile C:\...\brief.md `
  -Repo D:\projects\DTCode\RepoName

Codex — natively on Windows:

C:\Users\<username>\.claude\bin\worker-run.ps1 `
  -Engine codex `
  -Title "Short description shown on the card in the panel" `
  -BriefFile C:\...\brief.md `
  -Repo D:\projects\DTCode\RepoName `
  -Model gpt-5.6-luna -Effort low

Parameters:

The full justification for every mandatory flag inside the wrapper (-d Ubuntu, --trust-workspace, --approval-mode never, path translation for Spark; -s workspace-write, --skip-git-repo-check, brief via stdin for Codex) is documented in deploy/claude/skills/external-workers/SKILL.md.

Configuration

All workerBoard.* keys (Settings → Worker Board in VS Code):

What the panel does not show and why

• Spark doesn't report tokens. The muse exec --json stream contains no token-usage events at all — the tokensUsed/contextTokens field for Spark tasks is always absent (undefined), never zero.
• The context window size doesn't come from the transcript. It's always the value from workerBoard.contextWindowTokens — the panel has no way to read the model's real limit from a session file.
• Agents launched through the workflows feature are out of scanning scope — the panel recognizes main sessions and subagents in the standard transcript format, not agents from older/alternative harnesses.
• The "Kill" button on a Spark task kills wsl.exe, not the muse process on the WSL side. The PID stored in the heartbeat is the PID of the wsl.exe process on the Windows side (the only thing the panel can check and kill) — the muse invocation itself inside WSL may be left orphaned after wsl.exe is killed and need manual cleanup on the Linux side.

Troubleshooting

Publishing (optional)

The extension is ready to be published on the Visual Studio Marketplace — the manifest has every required field, a PNG icon, and a LICENSE file. The full procedure (PAT, login, vsce publish, Open VSX) is described in PUBLISHING.md (Polish only — an internal maintainer document).

Repository structure

WorkerBoard/
├── install.ps1                  # installer - see the Installation section
├── package.json                 # extension manifest (contributes, configuration, scripts)
├── esbuild.mjs                  # builds the extension into dist/extension.js
├── src/                         # extension code (scanners, model, view)
├── media/                       # panel webview (main.js, main.css, board.svg activity-bar icon, icon.png Marketplace icon)
├── scripts/                     # helper scripts (incl. the smoke test)
├── deploy/
│   └── claude/                  # source of truth for out-of-repo dependencies
│       ├── bin/worker-run.ps1               # copy -> ~/.claude/bin/
│       └── skills/external-workers/SKILL.md # copy -> ~/.claude/skills/external-workers/
└── dist/                        # build output (git-ignored)

Polski

English | Polski

Rozszerzenie jest bezpłatne i dostępne w Visual Studio Marketplace: code --install-extension dtcode.worker-board.

Czym to jest

Rozszerzenie VS Code z panelem w pasku bocznym, pokazującym w jednym miejscu wszystkie zadania AI wykonywane w tej chwili: sesje i subagentów Claude Code oraz workery zewnętrzne Spark (muse) i Codex. Panel jest wyłącznie czytelnikiem — nie uruchamia żadnego workera, jedyne operacje modyfikujące to zabicie procesu po PID i skasowanie plików zakończonych heartbeatów.

Co pokazuje:

• sesje główne i subagentów Claude Code (czytane z transkryptów ~/.claude/projects),
• workery Spark i Codex (czytane z heartbeatów ~/.claude/worker-status),
• dla każdego zadania: model, effort, gałąź gita, bieżące narzędzie, zużycie kontekstu i tokenów — tam, gdzie da się to wiarygodnie wyznaczyć z pliku źródłowego.

Co widać na wierszu

Panel nie ma sekcji per silnik ani osobnej sekcji na sesje czekające. Układ to jedno drzewo zakorzenione w konwersacji: korzeniem każdej gałęzi jest sesja Claude Code, a pod nią — wcięte, o stały krok na każdym kolejnym poziomie — wiszą wszystkie jej podzadania niezależnie od silnika: subagenci Claude oraz workery Spark i Codex przypięte przez sessionId (patrz KRYTYCZNE: jak używać). Sesja zostaje widoczna w drzewie nawet wtedy, gdy sama nic nie robi, o ile ma choć jedno widoczne dziecko — inaczej start pojedynczego workera zwijałby całą gałąź. Na końcu drzewa stoi grupa zapasowa „Bez przypisania" na workery, których nie da się przypiąć do żadnej widocznej konwersacji. Nagłówek panelu niesie jedną liczbę — łączną liczbę widocznych zadań w całym drzewie, nie sumę per sekcja (bo sekcji per silnik już nie ma).

Pojedynczy wiersz składa się z:

Kolor paska kontekstu jest sygnałem, nie dekoracją — progi liczone są włącznie (>=):

Rozmiar okna kontekstu (mianownik paska) nie występuje w transkrypcie — pochodzi z ustawienia workerBoard.contextWindowTokens (patrz Konfiguracja), nie jest odczytywany z żadnego pliku sesji.

Statusy

Panel pokazuje wyłącznie zadania w jednym z dwóch stanów widocznych — wszystko inne (zakończone, nieaktywne, porzucone) jest ukryte, panel nie jest historią.

Reguła wyznaczania statusu (dowód pozytywny z transkryptu, nigdy próg czasowy zgadujący aktywność):

• w toku — ostatnia wiadomość asystenta ma stop_reason: tool_use, i albo (a) to konkretne wywołanie narzędzia nie ma jeszcze wyniku (tool_result) w pliku, albo (b) tura wciąż jest formalnie otwarta (ten sam warunek stop_reason: tool_use, brak nowszej wiadomości użytkownika) i plik transkryptu był dopisywany w ciągu ostatnich 60 sekund. Drugi przypadek pokrywa okno, w którym model komponuje kolejny krok — w pliku chwilowo nie ma żadnego niesparowanego wywołania narzędzia, ale świeży zapis na dysku dowodzi, że sesja pracuje.
• czeka — asystent domknął turę (stop_reason kończący: end_turn, stop_sequence lub max_tokens) i nie ma po niej nowszej wiadomości użytkownika.
• stan celowo ukryty — "użytkownik wysłał wiadomość, ale jeszcze nic nie powstało". Z samego pliku transkryptu nie da się odróżnić modelu, który w tej chwili myśli, od wiadomości stojącej w kolejce bez żadnej reakcji — panel woli nic nie pokazać niż zgadywać w dowolną stronę.

Subagenci i workery (Spark/Codex) nigdy nie dostają statusu "czeka" — ten status istnieje wyłącznie dla sesji głównych Claude Code.

„Czeka" nie jest już osobną sekcją — to stan wiersza. Sesja czekająca stoi w drzewie dokładnie tam, gdzie wynika to z jej miejsca w konwersacji (korzeń swojej gałęzi), tyle że wygaszona (obniżona krycie) i z zamrożonym licznikiem od X min — w przeciwieństwie do zadań "w toku", których licznik tyka co sekundę, ten stoi w miejscu, bo sesja nic już nie robi.

Wymagania

Wymagania podzielone na poziomy — co znaczy który, patrz Instalacja.

Node.js, npm i @vscode/vsce nie są potrzebne do instalacji ani uruchomienia rozszerzenia ze sklepu — liczą się wyłącznie przy budowie własnej. Brak wymagania dla Sparka/Codexa niczego innego nie psuje: reszta panelu działa normalnie, po prostu wiersze tego workera się nie pojawią.

Instalacja

Worker Board ma dwa niezależne poziomy. Prawie każdemu wystarczy Poziom 1.

Poziom 1 — sesje i subagenci Claude Code (instalacja ze sklepu)

To jest ścieżka domyślna i jedyna, jakiej potrzebuje większość osób.

1. Zainstaluj rozszerzenie:
   • z VS Code: otwórz Extensions, wyszukaj Worker Board, kliknij Install; albo
   • z terminala: code --install-extension dtcode.worker-board.
2. Ctrl+Shift+P → Developer: Reload Window.
3. Kliknij ikonę Workery w pasku aktywności.
4. Sprawdź: View → Output → wybierz kanał Worker Board — powinien pojawić się wpis Worker Board <wersja> uruchomiony. To jedyny pewny sposób na potwierdzenie, która wersja faktycznie działa.

Na tym poziomie nie trzeba niczego więcej instalować ani konfigurować. Panel czyta sesje i subagentów Claude Code wprost z ~/.claude/projects, bez żadnego wrappera i bez dodatkowej konfiguracji. Jedyne wymagania to VS Code (1.96.0+) i już używany Claude Code — Node.js i npm nie są tu potrzebne (patrz Wymagania).

Jeśli panel wygląda na pusty zaraz po instalacji, to najprawdopodobniej poprawny stan, a nie błąd: panel z założenia pokazuje wyłącznie zadania trwające w tej chwili oraz sesje czekające na odpowiedź. Spokojny moment bez niczego w toku wygląda pusto z definicji — patrz Statusy.

Poziom 2 — workery Spark i Codex (wymaga wrappera)

Pomiń ten poziom, jeśli nie uruchamiasz workerów Spark (muse) ani Codex i nie zależy Ci na ich widoczności w panelu. W jednym zdaniu: Spark nie zostawia żadnego śladu na dysku, a Codex nie zapisuje znacznika zakończenia, więc panel potrzebuje rekordów stanu, które zapisuje wyłącznie wrapper worker-run.ps1 — patrz KRYTYCZNE: jak używać.

Są dwie drogi, żeby mieć wrapper i skill na miejscu:

A. Instalatorem (zalecana)

git clone https://github.com/DTCodePL/WorkerBoard.git
cd WorkerBoard
powershell -File install.ps1

Ta droga wymaga dodatkowo Node.js >= 20 (zalecane: 26) oraz npm, bo instalator buduje rozszerzenie ze źródeł (npm ci/npm install → npm run build → npx @vscode/vsce package), zanim je zainstaluje — i nadpisuje zainstalowaną ze sklepu wersję własną budową.

Skrypt działa na Windows PowerShell 5.1, który jest częścią każdej instalacji Windows — nie trzeba osobno instalować PowerShell 7. Jeśli PowerShell 7 (pwsh) jest zainstalowany, pwsh -File install.ps1 działa identycznie.

Skrypt kolejno: sprawdza wymagania (patrz wyżej), buduje pakiet, instaluje rozszerzenie we wszystkich wykrytych edycjach VS Code i wdraża dwie zależności żyjące poza repozytorium do ~/.claude/ (patrz sekcja KRYTYCZNE: jak używać). Po zakończeniu przeładuj okno i sprawdź tak samo jak w Poziomie 1 powyżej.

Przełączniki:

• -SkipBuild — pomija npm ci/build/vsce package i instaluje najnowszy (wg czasu modyfikacji) plik .vsix już obecny w katalogu repozytorium. Przydatne, gdy pakiet został zbudowany chwilę wcześniej.
• -DryRun — wypisuje pełny plan działania (wykryte wymagania, co zostałoby zbudowane/zainstalowane/nadpisane), niczego nie zmieniając na dysku.

Instalator jest idempotentny — powtórne uruchomienie z niezmienionym stanem repozytorium i ~/.claude/ daje ten sam wynik (poza ponownym uninstall+install rozszerzenia, które VS Code i tak wykonuje przy każdym przebiegu, bo potrafi zachować starą kopię przy niezmienionym numerze wersji).

B. Ręcznie, bez klonowania i bez Node.js

Dla kogoś, kto chce zostać przy wersji ze sklepu i dołożyć tylko brakujące dwa elementy. Pobierz z repozytorium te dwa pliki i umieść je w:

• deploy/claude/bin/worker-run.ps1 → %USERPROFILE%\.claude\bin\worker-run.ps1
• deploy/claude/skills/external-workers/SKILL.md → %USERPROFILE%\.claude\skills\external-workers\SKILL.md

a następnie utwórz (puste) katalogi %USERPROFILE%\.claude\worker-status i %USERPROFILE%\.claude\worker-status\logs. Bez Node.js, bez npm, bez vsce — wersja rozszerzenia ze sklepu zostaje nietknięta.

Niezależnie od drogi, workery Spark i Codex nadal MUSZĄ być uruchamiane przez wrapper, żeby pojawić się w panelu — patrz KRYTYCZNE: jak używać.

KRYTYCZNE: jak używać

Spark i Codex MUSZĄ być uruchamiane przez ~/.claude/bin/worker-run.ps1. Wywołanie surowego wsl.exe/codex.cmd z pominięciem wrappera odpala worker poprawnie, ale panel Worker Board nie zobaczy go w ogóle — ani że trwa, ani że się skończył.

Powód: Spark nie zostawia żadnego śladu na dysku poza ~/.config/muse (tylko auth.json/settings.json/trust.json, zero historii sesji), a Codex nie zapisuje żadnego znacznika zakończenia przebiegu. Wrapper naprawia to sam — pisze i domyka rekord stanu w ~/.claude/worker-status/<id>.json oraz pełny log w ~/.claude/worker-status/logs/<id>.log przez cały czas trwania przebiegu.

Przypisanie workera do konwersacji jest automatyczne. Rekord stanu niesie pole sessionId, którym panel dopina worker pod właściwą gałąź drzewa (patrz Co widać na wierszu). Wrapper wypełnia je samodzielnie ze zmiennej środowiskowej CLAUDE_CODE_SESSION_ID, dziedziczonej przez proces potomny — nie trzeba niczego podawać ręcznie. Pole jest opcjonalne: rekordy zapisane przed wprowadzeniem tego mechanizmu oraz workery uruchomione poza Claude Code (bez tej zmiennej w środowisku) go nie mają i trafiają do grupy „Bez przypisania".

Instalator wdraża też zmodyfikowaną wersję skilla Claude Code external-workers (~/.claude/skills/external-workers/SKILL.md) — dzięki niej Claude Code sam wywołuje wrapper, gdy deleguje pracę do Sparka lub Codexa; nie trzeba mu tego przypominać w każdej rozmowie.

Spark (muse) — przez WSL:

C:\Users\<uzytkownik>\.claude\bin\worker-run.ps1 `
  -Engine spark `
  -Title "Krotki opis widoczny na karcie w panelu" `
  -BriefFile C:\...\brief.md `
  -Repo D:\projects\DTCode\NazwaRepo

Codex — natywnie na Windows:

C:\Users\<uzytkownik>\.claude\bin\worker-run.ps1 `
  -Engine codex `
  -Title "Krotki opis widoczny na karcie w panelu" `
  -BriefFile C:\...\brief.md `
  -Repo D:\projects\DTCode\NazwaRepo `
  -Model gpt-5.6-luna -Effort low

Parametry:

Pełne uzasadnienie każdej z obowiązkowych flag wewnątrz wrappera (-d Ubuntu, --trust-workspace, --approval-mode never, tłumaczenie ścieżek dla Sparka; -s workspace-write, --skip-git-repo-check, brief przez stdin dla Codexa) opisuje deploy/claude/skills/external-workers/SKILL.md.

Konfiguracja

Wszystkie klucze workerBoard.* (Ustawienia → Worker Board w VS Code):

Czego panel nie pokazuje i dlaczego

• Spark nie raportuje tokenów. Strumień muse exec --json nie zawiera żadnych zdarzeń o zużyciu tokenów — pole tokensUsed/contextTokens dla zadań Spark jest zawsze nieobecne (undefined), nigdy zero.
• Rozmiar okna kontekstu nie pochodzi z transkryptu. To zawsze wartość z workerBoard.contextWindowTokens — panel nie ma sposobu wyczytać rzeczywistego limitu modelu z pliku sesji.
• Agenci uruchamiani przez funkcję workflows są poza zakresem skanowania — panel rozpoznaje sesje główne i subagentów w standardowym formacie transkryptu, nie agentów starszych/alternatywnych harnessów.
• Przycisk "Zabij" na zadaniu Spark ubija wsl.exe, nie proces muse po stronie WSL. PID zapisany w heartbeacie to PID procesu wsl.exe po stronie Windows (to jedyne, co panel potrafi sprawdzić i zabić) — samo wywołanie muse wewnątrz WSL po zabiciu wsl.exe może pozostać osierocone i wymagać ręcznego posprzątania po stronie Linuksa.

Rozwiązywanie problemów

Publikacja (opcjonalnie)

Rozszerzenie jest gotowe do publikacji w Visual Studio Marketplace — manifest ma komplet wymaganych pól, ikonę PNG i plik LICENSE. Pełna procedura (PAT, logowanie, vsce publish, Open VSX) opisana jest w PUBLISHING.md.

Struktura repozytorium

WorkerBoard/
├── install.ps1                  # instalator - patrz sekcja Instalacja
├── package.json                 # manifest rozszerzenia (contributes, konfiguracja, skrypty)
├── esbuild.mjs                  # build rozszerzenia do dist/extension.js
├── src/                         # kod rozszerzenia (skanery, model, widok)
├── media/                       # webview panelu (main.js, main.css, board.svg ikona paska aktywności, icon.png ikona Marketplace)
├── scripts/                     # skrypty pomocnicze (m.in. smoke test)
├── deploy/
│   └── claude/                  # zrodlo prawdy dla zaleznosci poza repo
│       ├── bin/worker-run.ps1               # kopia -> ~/.claude/bin/
│       └── skills/external-workers/SKILL.md # kopia -> ~/.claude/skills/external-workers/
└── dist/                        # wynik budowy (ignorowany przez git)