Summary
The bundled bb-plugin-authoring skill documents bb.sdk.threads.list as returning { threads }. It returns a plain array. An author who copies the example gets undefined with no error, and only finds out by reading the 700KB of bundled declarations.
Versions and environment
- bb 0.40.0, desktop app. Reproduced from source at
ad79bbb5ec909524f8f281e62d860c588a86f332.
- macOS 15 (Darwin 25.3.0), arm64. Node v20.13.1.
Steps to reproduce
In any plugin's server.ts, copy the example the skill gives:
const { threads } = await bb.sdk.threads.list({ projectId, limit: 50 });
console.log(threads); // undefinedExpected vs actual
threads.list resolves to ThreadListResult = ThreadListResponse, a z.ZodArray. Destructuring { threads } from an array yields undefined, silently — the call succeeded, so nothing throws and nothing logs.
Typechecking the documented line against the SDK's own declarations gives:
probe.ts(24,9): error TS2339: Property 'threads' does not exist on type
'{ id: string; projectId: string; environmentId: string | null; providerId: string;
title: string | null; ... 19 more ...; environmentWorkspaceDisplayKind: ... }'.
Expected: const threads = await bb.sdk.threads.list(...).
Evidence
- The documented line:
|
const { threads } = await bb.sdk.threads.list({ projectId, limit: 50 }); |
- The declaration:
ThreadsArea.list(args?: ThreadListArgs): Promise<ThreadListResult>, type ThreadListResult = ThreadListResponse, declare const threadListResponseSchema: z.ZodArray<...> (bundled bb-plugin-sdk.d.ts).
Found while writing a plugin against the skill: the array form is what actually works at runtime, confirmed by a loaded plugin whose readBoard calls .filter() on the result and returns real threads.
What you ruled out
- Not an older SDK: the array shape is what
packages/plugin-sdk declares at ad79bbb.
plugin-authoring-docs.test.ts cannot catch this — it proves the skill mentions every API member, not that its examples compile. This is the only bb.sdk destructuring in the file, so it is a single wrong line, but nothing structural was stopping the next one.
Suggested priority and effort
Silent-wrong-answer bug in the document agents read before writing any plugin. One-line fix; the durable part is a test that compiles the examples.
AGENT GENERATED
Summary
The bundled
bb-plugin-authoringskill documentsbb.sdk.threads.listas returning{ threads }. It returns a plain array. An author who copies the example getsundefinedwith no error, and only finds out by reading the 700KB of bundled declarations.Versions and environment
ad79bbb5ec909524f8f281e62d860c588a86f332.Steps to reproduce
In any plugin's
server.ts, copy the example the skill gives:Expected vs actual
threads.listresolves toThreadListResult = ThreadListResponse, az.ZodArray. Destructuring{ threads }from an array yieldsundefined, silently — the call succeeded, so nothing throws and nothing logs.Typechecking the documented line against the SDK's own declarations gives:
Expected:
const threads = await bb.sdk.threads.list(...).Evidence
bb/apps/server/src/services/skills/builtin-skills/bb-plugin-authoring/SKILL.md
Line 689 in ad79bbb
ThreadsArea.list(args?: ThreadListArgs): Promise<ThreadListResult>,type ThreadListResult = ThreadListResponse,declare const threadListResponseSchema: z.ZodArray<...>(bundledbb-plugin-sdk.d.ts).Found while writing a plugin against the skill: the array form is what actually works at runtime, confirmed by a loaded plugin whose
readBoardcalls.filter()on the result and returns real threads.What you ruled out
packages/plugin-sdkdeclares atad79bbb.plugin-authoring-docs.test.tscannot catch this — it proves the skill mentions every API member, not that its examples compile. This is the onlybb.sdkdestructuring in the file, so it is a single wrong line, but nothing structural was stopping the next one.Suggested priority and effort
Silent-wrong-answer bug in the document agents read before writing any plugin. One-line fix; the durable part is a test that compiles the examples.