/**
 * Shared projected `qodo-skills.*` tool defs.
 *
 * Lives in a platform-neutral module so the Node `server.ts` and the
 * browser `server.browser.ts` both source the same constants. The
 * original review flagged two coupled issues if these defs were
 * duplicated per-platform:
 *
 *   1. **Browser schema drift.** `qodoSkillsFunctionToolDefs()` is
 *      exported for consumer-side CI lint / Studio previews. A looser
 *      browser schema would let tooling that runs against the browser
 *      build accept argument shapes the Node dispatcher rejects.
 *   2. **Unsafe `FunctionToolDef` cast.** Typing `parameters` as a
 *      generic `Record<string, unknown>` forced an `as unknown as
 *      FunctionToolDef` cast in `TaskClient.mergeQodoSkillsTools`,
 *      defeating the SDK's strict JSON-serializability typing.
 *
 * Both are resolved by:
 *   - Defining one canonical `QODO_SKILLS_TOOL_DEFS` constant typed
 *     directly as `readonly FunctionToolDef[]` so callers don't cast.
 *   - Constraining schemas with `satisfies JsonObject` so a malformed
 *     constant fails at compile time.
 *   - Re-exporting from both `server.ts` and `server.browser.ts` so
 *     the projection layer's `import from '../../skills/mcp/server.js'`
 *     resolves identically per platform without diverging.
 *
 * The module imports no Node-only APIs (`node:fs`, `node:path`, etc.),
 * so bundling for the browser doesn't pull in dead code.
 */
import type { FunctionToolDef } from '../../qar/specs.js';
/**
 * Projected wire-side tool definitions for the `qodo-skills` MCP.
 *
 * The MCP projection layer auto-includes these three entries whenever
 * `ClientOptions.skills` is configured, regardless of the consumer's
 * `mcpTools.allowlist`. The projection layer normally skips
 * `transport: 'sdk'` MCPs because they bypass the `tools/list` round-
 * trip; without this hardcoded surface the LLM would see the
 * `<available_skills>` preamble ("Use the qodo-skills.get_skill tool to
 * ...") and fail to call a tool it can't see. See `render.ts`
 * `BLOCK_PREAMBLE` + `QodoClient.attachSkillsMcpBridge` for the matching
 * SDK-owned ends of the contract.
 *
 * Names use the `qodo-skills.` prefix so they match QAR's default
 * `prefixToolNames: true` mental model. The skills MCP bridge in
 * `QodoClient` accepts bare names (`list_skills`) and prefixed forms
 * (`qodo-skills.list_skills`, `qodo-skills:list_skills`) interchangeably,
 * so the wire prefix doesn't constrain dispatch.
 *
 * **Same defs in Node + browser.** The browser build can't actually
 * *dispatch* a qodo-skills call (the manager stub throws on
 * `discover()`), but tooling that introspects the wire surface
 * (CI-lint a consumer's agent spec, render a Studio preview) must see
 * the same schemas as the Node runtime would accept. Hence the shared
 * module rather than per-platform stubs.
 */
export declare function qodoSkillsFunctionToolDefs(): readonly FunctionToolDef[];
//# sourceMappingURL=wireDefs.d.ts.map