Skip to content

Add plugin entry: task-router - #124

Open
yegor-korobeynikov wants to merge 1 commit into
get-bb:mainfrom
yegor-korobeynikov:submit-task-router
Open

Add plugin entry: task-router#124
yegor-korobeynikov wants to merge 1 commit into
get-bb:mainfrom
yegor-korobeynikov:submit-task-router

Conversation

@yegor-korobeynikov

Copy link
Copy Markdown

What the plugin does

Task Router notices when a composer draft belongs to a different project than
the one currently selected, and offers to open a new thread there with one
click. Matching is fully deterministic (name/path against the workspace's git
repositories, no model call) and stays silent whenever it isn't confident.

Source release

Plugin checks that succeeded

  • npm install
  • npm test (18/18 passing)
  • npm run typecheck (clean)
  • bb plugin build (produces dist/server.js, dist/app.js, metadata)

Marketplace checks that succeeded

  • npm ci --ignore-scripts
  • npm run build (composed dist/marketplace.json with 83 entries, including this one)
  • npm run check (liveness check against the live git tag passed)

Permissions / external services

No external services. The plugin reads local git config/host directory
listings via the bb SDK (bb.sdk.hosts.*) to build a workspace census, and
registers/spawns bb projects/threads (bb.sdk.projects.*, bb.sdk.threads.*)
only when the user clicks the suggestion. No network calls, no model calls.

@SawyerHood

Copy link
Copy Markdown
Contributor

Automated note from a Claude Code agent, posted on behalf of the marketplace maintainer.

Thanks for the submission — we really want to get this in. For the first run of the marketplace we are aiming for a small set of very polished plugins, and we will open it up more broadly soon. Here is what we found reviewing the source at the tag your entry resolves to and installing it from that entry into a dev build of BB 0.40:

This installs and runs cleanly, the tests pass, and the deterministic matching approach (no model call, ties suppressed, a stoplist of ordinary words, worktrees collapsed via commondir) is nicely done. Two things to fix before we list it, plus one icon nit.

1. With the default settings it walks your entire home directory — and the README says it does not

workspaceRoot defaults to "" (server.ts:132-139). buildCensus() sets root = "" (:188), seeds the walk with it (:195-196), and calls bb.sdk.hosts.directory({ hostId, path: "" }) (:212). The host route treats an empty path as omitted, and omitting path lists the host's home directory. So an unconfigured install enumerates $HOME three levels deep (up to MAX_DIRECTORY_READS = 4000), reads .git/config for every repo it finds (:159-184, :238-241), and does it automatically at plugin start (:558) and again every 30 minutes.

Your SKIP_DIRECTORIES set including "Library" and "Applications" (:56-70) suggests this was anticipated. But the README states "Empty by default; the plugin stays silent until it is set" — that is not what happens: the census populates from $HOME and classify() will suggest repos found there.

Nothing is exfiltrated — it is all local, all through the SDK — but the entry description mentions only "the workspace's git repositories" and neither it nor the settings UI warns about a home-wide scan.

Fix: early-return from buildCensus() when workspaceRoot is empty, so the plugin is genuinely inert until configured. Failing that, correct the README and disclose the scan in the entry description.

2. Undisclosed side effect: it creates BB projects

server.ts:405-413 calls bb.sdk.projects.create() when the target repo is not registered. Your README discloses it; the entry description does not — it says only "offers to open the thread there with one click". Clicking the banner permanently adds a project to the user's sidebar. Please add that to the description.

3. Split is not a valid host icon name

We checked against all 143 valid names (the 47 CORE_ICON_MAP keys plus the 96 EXTENDED_ICON_NAMES) — Split is in neither, so it renders the generic Zap fallback. Fork or GitBranch both work and both are valid.

Smaller notes

  • The composer draft is RPC'd to the plugin server on every 500ms debounce (app.tsx:42-65). It stays in-process and never leaves the machine, and you correctly do not log draft text — but it does mean the plugin observes every character typed into the root composer. Worth a line in the description.
  • Overlap worth knowing about: the listed dispatch plugin also classifies a one-liner to a BB project and spawns a thread there. Different mechanism (yours is deterministic name/path matching, theirs is model classification), but installed together both act on the same composer draft.
  • Your dependency placement is correct, incidentally — sonner and react in devDependencies is right, since BB runtime-shims both. We verified a clean --omit=dev install plus bb plugin build succeeds.

@SawyerHood SawyerHood left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review (Claude Code agent on behalf of the maintainer): requesting changes per the feedback comment above. Ping here when a new version is published and we will re-check.

@SawyerHood SawyerHood added the blocked Waiting on plugin author changes before it can be listed label Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocked Waiting on plugin author changes before it can be listed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants