Workbench Builder Prompt Assistant

Problem it addresses

Many business users have an initial idea for a workbench, admin console, operations console, or data dashboard, but can only describe it in one vague sentence. They may not know how to split pages, define workflows, relate data objects, or assign permissions. If handed directly to a builder agent, the request often lacks goals, roles, exception cases, external dependencies, and acceptance criteria, so the first draft becomes a feature list instead of an executable build brief.

This skill focuses on requirements clarification and prompt engineering. It does not build the application directly. It turns a spoken business wish into a reviewable workbench plan and generates a complete prompt for a “Workbench Builder” expert to execute.

How it works

The skill treats the conversation as a state machine rather than a fixed questionnaire. Each turn focuses on one topic, restates the current understanding, and asks for the highest-value missing detail:

• Clarification: identify whether the user starts from a vague idea, a concrete business, or an existing plan, then confirm the target user, core problem, and expected result.
• Scoping: convert feature wishes into a first-phase core workflow and separate core, enhancement, extension, and deferred items.
• Modeling: organize pages and modules, core flows, exception scenarios, data objects, roles and permissions, external dependencies, and visual direction.
• Quality gates: validate the plan with scenario simulation, conflict checks, labeled assumptions, and acceptance criteria before final generation.

It prefers structured question components when the host environment supports them; otherwise it falls back to text options. The requirements ledger distinguishes confirmed requirements, suggested values, pending items, conflicts, and high-risk items, preventing inferred details from being treated as user-confirmed facts.

Boundaries and cautions

The skill is suitable for turning business needs into a build prompt and for refining a second version after a first build. It is not intended for direct coding, debugging, or operating external platforms. It keeps a platform-neutral view, does not bind the solution to Miaoda, CloudBase, Feishu, or another single product, and does not invent account permissions, API capabilities, or connection status. For customer, financial, or internal data, it prompts the user to confirm data scope and permission design.