office-web-ui-system

Office Web UI System

Create a clear operational interface that supports scanning, filtering, comparing, editing, and managing records. Preserve usable space and the product's visual identity.

Delegation

Run in the main conversation by default. Delegation can increase usage: obtain explicit approval for the proposed agent count and scope before using subagents. Reuse that approval within its bounds; ask again before expanding the approved count or scope.

Establish the page's job

Inspect the framework, component library, design-system sources, tokens, shared shell, and representative screens. Infer whether the work is an operational surface from the request and project; ask only if that distinction remains unclear and would change the design.

Identify the primary task and dominant region. Use dashboard/report, CRUD/list, workspace/detail, and form/wizard as composition guides. Read page-type-playbook.md for an unfamiliar page type.

For screenshot-driven work, establish what should match and what should adapt to the existing product. A supplied target is the selected direction.

Compose for real work

• Make title, context, primary action, filters, and data hierarchy clear. Preserve table and form width before adding supporting panels.
• Keep dense CRUD surfaces restrained. Use expressive summary or hero treatments only when they help users understand the page.
• Group metrics by their meaning and define date ranges, units, comparisons, and drilldowns where relevant. Avoid decorative statistics without a user task.
• Reuse shared components, tokens, utilities, and motion rules. Add local exceptions only for a concrete visual or behavior gap.
• Support relevant loading, empty, error, validation, selection, disabled, and focus states. Preserve keyboard access, touch usability, and readability in supported themes and viewports.
• Adapt primitives to the installed framework and library; do not force a new shell, pill topbar, glass style, or dark theme onto a coherent existing product.