xique-bid WorkBuddy integration

Team-ready WorkBuddy integration for @xqyz/xq-cli is split into two delivery parts:

• this plugin supplies the xique-bid Skill, first-use installers, /xique-bid command, and hooks;
• ../workbuddy-connector-xique supplies the WorkBuddy Connector manifest;
• the published npm package supplies the MCP server and standard MCP App;
• the Connector proxy, not the ordinary plugin MCP client, loads that server.

The plugin's .mcp.json must remain empty. Registering the server there makes its tools visible to the model but bypasses WorkBuddy's ConnectorMcpProxy. The MCP Apps catalog then rejects the linked ui://xique-bid/selection.html resource, so the configuration card may not render or may appear to click without advancing the conversation.

Together, the Skill and Connector provide complete Chinese configuration cards, confirmation gates, durable status reconciliation, outline review and editing, body continuation, export, and automatic Word-file delivery.

The MCP server intentionally does not call xq-cli wizard because that command always opens an interactive TTY session.

Prerequisites

Use WorkBuddy 5.3.11 or newer. The first-use installer prefers WorkBuddy's bundled Node.js 20.19.0 or newer and falls back to a compatible system Node. Customers do not install xq-cli globally: the MCP npm package pins and carries @xqyz/[email protected] as a production dependency.

The user's Xique login state remains in ~/.xq-opencli/config.json. Never copy that file into the plugin, SkillHub, npm, or Connector repository. API-key and token logins are both supported; when XQ_API_KEY is set, the plugin uses it first. New keys use the xq_sk_ prefix. For API-key-first setup, run xq-cli login --api-key xq_sk_xxx locally or set XQ_API_KEY; never paste the key into WorkBuddy chat.

SkillHub self-service installation

SkillHub intentionally labels its action 复制 prompt. The copied prompt tells WorkBuddy to install the complete xique-bid Skill directory, including its scripts/ resources, under ~/.workbuddy/skills.

On the first Xique request, the Skill checks xique_runtime_status, including the actually loaded pluginVersion. SkillHub's explicit copied installation prompt authorizes the complete setup, so the Skill runs the bundled Windows or macOS/Linux installer without asking the user to confirm the same installation twice. If an older Plugin is loaded, the Skill treats the SkillHub update as an upgrade authorization and runs the fixed 0.10.14 installer. An ordinary bid request never silently changes the local environment; it asks once before an upgrade. The installer:

1. selects the newest compatible WorkBuddy-bundled Node and npx;
2. validates and backs up ~/.workbuddy/mcp.json;
3. merges only mcpServers.xique-bid, preserving all other MCP entries;
4. pins @xqyz/[email protected];
5. opens Xique browser authorization when no local API key or token exists;
6. reports that the configuration is saved but not active yet;
7. directs the user to click 信任 for xique-bid in WorkBuddy's MCP service management, then fully restart WorkBuddy.

Repeated installation is idempotent, including an upgrade from an older xique-bid entry. Invalid JSON is never overwritten, and all other MCP entries are preserved. The MCP package and its bundled xq-cli dependency are downloaded by npx on the first WorkBuddy start after registration. Login uses browser authorization and never asks the user to paste a username, password, API key, or token into WorkBuddy. Writing mcp.json is not reported as installation completion: after restart, xique_runtime_status must report pluginVersion >= 0.10.14, cliVersion >= 0.3.5, cliFound=true, and loggedIn=true. If the old version remains loaded, report that exact version and do not claim success or loop the installer.

Before reporting that the configuration was saved, the npm installer starts the exact pinned MCP with the selected Node/npm and completes the MCP initialize handshake. A failed startup restores the previous configuration and prints the captured stderr, so a cached or broken npx package is never reported as an upgrade. Windows .cmd and .bat launchers are quoted during this probe, so a system Node installed under a path such as C:\Program Files\nodejs is supported too.

Install for local development

First add this repository as a local plugin marketplace and install the Skill/Hook companion xique-bid@xique-tools. In CodeBuddy-compatible command mode:

/plugin marketplace add <xq-cli-repository-path-or-url>
/plugin install xique-bid@xique-tools

You can also load only the Skill/Hook plugin directory for development:

codebuddy --plugin-dir <repository>\workbuddy-plugin-xique

Then add workbuddy-connector-xique as a local Connector market and install 喜鹊标书 / Xique Bid. For unpublished local development, register workbuddy-plugin-xique/mcp/server.mjs as a trusted custom MCP named exactly xique-bid, then fully restart WorkBuddy.

In the WorkBuddy desktop UI, the plugin is installed from 插件市场 and the MCP service is installed from Connector 市场. Installing only the plugin is not sufficient for interactive cards.

After installation, users can enter /xique-bid 生成标书 to force the explicit standard entry point. Natural-language requests mentioning Xique or bid generation are also routed to the same Skill and MCP workflow.

When configuration is missing, WorkBuddy polls the same runId until the status is awaiting_input/bid-config, then calls the named xique_bid_configuration stage once to show page scope, writing mode, style, tables, response basis, images, export settings, and the dependent output path on one page. The following confirmation card is named xique_outline_start / “开始生成大纲”. Individual fields remain available through xique_select_option only for targeted edits. A compatible client can use a native MCP form. WorkBuddy v5.3.11 returns Method not found for that protocol method, so the tool returns interactionMode=mcp-app. Its tool metadata links ui://xique-bid/selection.html, and WorkBuddy automatically opens the standard MCP App in its dedicated panel. The app submits clicks through the MCP Apps ui/message channel, which WorkBuddy forwards as the next user prompt.

Every MCP App card is single-submit. The first click immediately locks the card and persists that state locally, including while WorkBuddy is processing the message and when the card is reopened. The user cannot choose a second option from the same card. Generation confirmation IDs are consumed atomically, and the special-project continuation reuses the same runId and rejects or neutralizes duplicate submissions.

Confirmation cards carry their exact runId and confirmationId in the click message. Repeated xique_prepare_outline_continue calls for the same unchanged outline reuse one durable record instead of creating competing confirmations. If the model accidentally supplies an older ID, the server can consume the current matching record only after verifying the same run and unchanged outline, so one outline decision never asks the user to click a second time.

The dedicated panel surface is intentional for WorkBuddy v5.3.11. Its inline MCP App renderer depends on anchoring the App to a visible tool-call message. Tool calls inside the collapsed process area can lose that anchor even though the sandbox App was created successfully, leaving the conversation to say “请选择” while no card is visible. The panel host does not depend on that message anchor.

This path intentionally does not use the legacy show_widget renderer. WorkBuddy v5.3.11 renders those Widgets but omits the hostConfig send callback: sendPrompt() reaches widget:sendMessage, then the host silently discards it. That defect produces the exact symptom where a card changes color or becomes disabled but the conversation does not continue. The MCP App channel bypasses that broken callback and reports visible submission errors instead of leaving a dead selected card. WorkBuddy's built-in AskUserQuestion is intentionally not used because it caps each question at four options and always appends a free-text Other/其他补充 entry. Typed selection is not used as a fallback; if both native form and MCP App rendering are unavailable, the Skill reports a compatibility failure instead.

Before showing image choices, WorkBuddy queries the current user's gallery. “我的图库” remains visible to match the frontend, but it is selectable only when the gallery contains at least one image. Empty galleries show an upload hint, and the MCP prepare gate rejects stale or bypassed attempts to enable the option.

Template 5 remains visible as 模板5｜自定义编号（可视化设置）. Selecting it in the one-page bid configuration card expands the adjacent 模板5自定义编号 group with the complete title/body numbering definition; the same settings can be adjusted again after正文完成 through xique_export_configuration, together with margins and image sizes. WorkBuddy never displays or requests advanced style JSON.

The one-page bid configuration card also includes an 图片设置 group (image-source toggles and diagram style), which is expanded by default so users can choose image options immediately. Image sizes and the 页边距设置 group remain collapsed by default because frontend defaults are valid; expanding them is only needed for custom layout values. These values are carried into the later export defaults, so a second download starts from the user's original choices instead of silently reverting to the frontend defaults.

Confirmation records are stored durably and shared by all local MCP server processes. Restarting WorkBuddy or routing consecutive tool calls to different MCP processes no longer loses an outline-update or outline-continue confirmation. Outline-continue records remain valid for 24 hours and are deduplicated by runId plus outline signature.

Each form field displays every supported value directly. Page scope shows all seven frontend presets and their page ranges in one question; styles, colors, templates, and diagram styles are likewise fully expanded. Enumerated fields never use the WorkBuddy component that adds Other; image choices match the frontend grouping, and the standard flow now shows the plan-mode choice instead of silently forcing quick mode.

After the initial confirmation, WorkBuddy uploads the source and generates the outline. If parsing identifies multiple packages or an EPC project, the same run pauses at awaiting_input/special-config; WorkBuddy calls the named xique_special_project_selection card using only the packages and EPC ranges returned by the backend, then xique_apply_special_project_selection continues the same initialized task without re-uploading the source. Once the outline is ready, the run pauses before body generation. It displays every chapter and theme. The user can confirm the outline, describe edits, reorder/add/delete chapters through a diff-confirmed update, or leave the task paused. Only after the final outline confirmation does WorkBuddy resume the same runId, generate the body, continue through export, and call present_files when the Word file exists. The user receives the completion message and file without asking 完成了吗. If WorkBuddy is closed or the task is interrupted, the durable run continues and can still be recovered by a later status request; the plugin does not claim an out-of-band notification after the app closes.

Team distribution

Release the same version through all three channels:

1. Publish @xqyz/[email protected] to npm. This package contains the executable xique-workbuddy-mcp runtime, pre-bundled MCP App, and @xqyz/[email protected] production dependency.
2. Publish the plugin marketplace paths .codebuddy-plugin/marketplace.json and workbuddy-plugin-xique/ for the Skill, command, and hooks.
3. Publish workbuddy-connector-xique/ as the Connector marketplace. Its mcp.json launches the pinned npm version through npx.

Customers using SkillHub only copy the installation prompt, approve the first MCP setup, restart WorkBuddy, and log in to Xique. Customers using a Connector market can install the xique-bid companion plugin and Xique Bid Connector directly. The Connector proxy remains mandatory for MCP App cards; do not restore a server entry in the plugin .mcp.json as a shortcut.

The only external state is a compatible Node runtime supplied by WorkBuddy and the user's own Xique login. A global @xqyz/xq-cli installation is not needed.

MCP tools

• xique_runtime_status: check Node, CLI resolution, and cached login state.
• xique_choices: read the current CLI configuration choices.
• xique_bid_configuration (“喜鹊标书配置”): collect all ordinary settings on one page.
• xique_outline_start (“开始生成大纲”): collect the post-summary start decision.
• xique_special_project_selection (“选择标包 / EPC”): display only backend-parsed special-project options.
• xique_apply_special_project_selection: apply that selection to the same runId and continue outline generation idempotently.
• xique_outline_confirmation (“确认大纲并生成正文”): collect the final outline decision.
• xique_outline_update_confirmation (“保存大纲修改”): collect the diff-save decision.
• xique_select_option: edit one ordinary field after the one-page configuration has already been submitted.
• xique_prepare_bid: validate and stage a complete bid-generation config.
• xique_generate_bid: start one durable background run and pause after the outline is ready.
• xique_generation_status: return running, outline-review, or final state from the same runId; an expired local polling window remains recoverable and is reconciled with the backend instead of creating a replacement task.
• xique_outline_view: read the complete current outline without retriggering generation.
• xique_prepare_outline_update: preview the full outline diff and prepare a save confirmation.
• xique_apply_outline_update: save the confirmed diff, then return the updated outline.
• xique_prepare_outline_continue: snapshot the reviewed outline and reuse one body-generation confirmation for the same unchanged run.
• xique_continue_bid: resume the same run after one final outline click; safely recover a stale model-selected ID only when the current run and outline still match.
• xique_task_status: query an existing task without changing it.
• xique_prepare_export: validate and stage export settings for an existing task.
• xique_export_bid: export after a new explicit user confirmation.

Confirmation records are stored in a shared local directory. Ordinary records expire after 30 minutes by default; outline-continue records use a 24-hour window so a visible card does not force a second confirmation. Set XIQUE_CONFIRMATION_DIR to override the directory or XIQUE_CONFIRMATION_TTL_MS to change the ordinary expiry.

Security model

• Preparing a workflow never runs xq-cli.
• Initial generation, outline updates, body continuation, and export require a valid confirmation ID and a clear confirmation phrase such as 确认, 开始, or 就按这个跑.
• Execution uses the staged server-side configuration, not arguments supplied again at execution time.
• One confirmed configuration starts one run. The Skill forbids helper scripts, direct xq-cli calls, duplicate generation, and log-based status guesses.
• A UserPromptSubmit hook reinforces standard routing for bid requests, while a deterministic PreToolUse hook denies direct generation commands, manual MCP server launches, and helper scripts that call the CLI or MCP protocol.
• Run state is persisted under CODEBUDDY_CONFIG_DIR/xique-bid-runs in WorkBuddy, so follow-up turns can query the authoritative result.
• Login tokens are never returned by the MCP server.
• Issue-bypass flags remain disabled unless the user explicitly confirms them in the prepared configuration.

Plugin maintainers can set XIQUE_BID_ALLOW_PLUGIN_DEVELOPMENT=1 only in a dedicated development session when they intentionally need to edit or test bypass-detection fixtures. Do not set it in customer environments.

Validate without generating a bid

cd <repository>\workbuddy-plugin-xique
npm test

The tests validate configuration mapping, both confirmation gates, outline review/update behavior, runtime discovery, MCP App resource metadata, and MCP protocol initialization. They use a fake CLI and do not call real bid-generation APIs.