workspace-design - SKILL.md Agent Skill

name: workspace-design description: Design or review business operation pages, workbenches, and review or follow-up pages as task-centric workspaces. Use when working from requirement docs, business workflows, wireframes, screenshots, HTML, or frontend page proposals.

Workspace Design

Goal

Design pages as workspaces where the user first understands the current situation, then narrows into real work, and then acts on real objects directly. Do not let the page collapse into an admin-console pattern where the user filters records first and only acts afterward.

Keep this order in mind:

Establish the current situation
Narrow into the right work pool
Land on real objects quickly
Support action in the most suitable view

When rules conflict, use this priority:

Keep the output structurally complete
Satisfy the hard rules
Preserve the workspace hierarchy when it matters
Replace generic labels with business language
Add explanation or examples last

Parse The Input First

Before producing the solution, extract:

Role
Primary goal
High-frequency actions
Risks or exceptions
Core objects
Work rhythm
Key stages or handoff points
Whether the work is queue-driven, category-driven, or mixed
Whether mobile drill-down, responsive behavior, routing, or browser history matters for this task
Problems in the current page, if a current page exists

If information is missing:

Make 1 to 5 minimal assumptions
Put them in 0. Assumptions
Do not fall back to vague principles

Choose The Mode

Generate Mode

Use this when the user provides requirements, a PRD, a workflow, a role goal, or a verbal description.

Review Mode

Use this when the user provides a screenshot, wireframe, HTML, an existing page proposal, or explicitly asks whether something feels like a workspace.

In review mode:

Judge whether the current design is closer to a workspace or an admin console
Identify structural problems
Propose a full workspace-oriented redesign

Do not stop at criticism. Always produce a concrete redesign.

Default Structural Pattern

Prefer this as the default pattern unless the task clearly needs another layout.

Page title + one-line positioning + global quick actions
Situation card strip
Optional page-level filters / scope controls

Two-column workspace:
Left: Level 1 ALL + work categories OR Level 2 Back + task queue
Main: category work view OR Back + task detail / action surface
Optional right drawer

Meaning Of The Areas

The top establishes the situation instead of starting with a large table
The left column is a hierarchical work finder, not app navigation
The left column should move quickly from category scope to concrete tasks
The main column is the real workspace surface
The right drawer is optional and only carries secondary context

Responsive, Mobile, And Routing

Use this section only when the task involves responsive behavior, mobile flow, routing, browser history, or implementation details that depend on navigation structure.

Desktop

Prefer a 2-column workspace:

Left: hierarchical finder
Main: workspace surface
Right drawer: optional only

Mobile

Do not try to preserve side-by-side panes.

Serialize the same hierarchy into drill-down screens:

Categories -> Tasks -> Task -> Subtasks / Operation

Routing Model

Treat the workspace as a navigable hierarchy:

workspace -> scope -> task -> step

How this hierarchy is expressed depends on platform and app conventions:

Path segments
Query state
In-app navigation state
Native stack navigation

Browser back or in-app back should follow this hierarchy when routing is part of the task.

Hard Rules

Apply these in both generate mode and review mode:

Do not start the page from a table
Do not use titles like Manage X
Do not make filters the main character of the page
Do not turn summary cards into decoration without action value
Do not assume every object belongs in a list
Do not force frequent page jumps to handle details on desktop
The page should immediately answer "what is happening now and what should I do first?"
The left side is not app navigation; it is a staged work finder that should land on a real task queue quickly
Queue entry points are not filters
The main work area must support direct progress on the core action
A list inside the main work area is acceptable when it is a subtask list, child-item list, or working list inside the selected task
The drawer is optional and only carries supporting context, secondary actions, and supplemental information
Prefer business action language and business object language for page names, queue names, and card names
If queue groups exist, derive them from workflow, risk, time pressure, or handoff logic rather than generic placeholders
Whether the left side is one level or two levels, it should land on actionable objects quickly rather than staying at pure categories
If the left side is interpreted as pure navigation, the design is drifting away from a workspace
Do not make both columns become nested generic lists; at least one state of the main column must behave like a real workspace surface
If mobile behavior matters, convert the hierarchy into drill-down screens rather than squeezing both columns into narrow panes
If routing or browser history matters, preserve meaningful navigation state such as scope, task, and major operation step
If routing is used, keep incidental UI state such as drawer open state, splitter width, or minor local toggles out of the URL unless the task explicitly requires otherwise

Design Rules

1. Page Positioning

Prefer to provide:

Page title
One-line positioning statement

Requirements:

Let the title describe an action, not a module
Prefer verb-led titles
Let the positioning statement explain who uses the workspace, what goal it serves, and what risks or exceptions it should surface quickly

2. Situation Cards

Situation cards establish the current situation. They are not decorative totals.

Requirements:

Usually design 4 to 6 cards
Every card should drill into real work
Every card should reflect at least one of risk, trend, or urgency

For each card, explain:

Name
Why it matters
Which scope, queue, view, or result set it drills into
Which operating period it represents

Good candidates:

Work due today
Near-timeout items
High-risk objects
Current bottlenecks
Completion rate this week
Capacity pressure
Upcoming expirations

Avoid:

Static totals with no action value
Global KPIs unrelated to the page’s job
Pure BI-style statistics

3. Left Column: Hierarchical Work Finder

The left column is not ordinary sidebar navigation. It is a staged work finder.

Prefer two levels when the user first needs a work scope and then a concrete queue.

Two-Level Pattern

Level 1: ALL + work categories
Level 2: Back + task queue

This is the default pattern when:

The user first needs to choose a work pool
Different work pools have different rhythms
The task queue should not be confused with app navigation
The main area needs more width for actual operation

One-Level Pattern

Task queue only

This fits when:

The user mainly works through one object pool
Category switching is infrequent
Priority can be expressed through ordering, status, or time pressure

Requirements

Land on a concrete task queue quickly
Treat categories as entry points, not final destinations
If you use a two-level left column, the level-1 view should be brief and clearly transitional
The task queue must contain real work objects, not issue taxonomy pretending to be a queue
Queue items should answer "what exact thing can I work on now?"

Prefer deriving category entry points from:

Workflow stage
Risk type
Time window
Approval or handoff step
Recovery or escalation path
Ownership

Only use generic labels like these when nothing more specific is available:

To handle
Risks
Follow-ups

For each left-column entry point, explain:

Why it exists
What work enters it
What the task queue looks like after entering it
What state the main work area enters after selecting a task

Task queue items should usually include:

Object title
Current status
Time pressure
Next action

4. Filters

Filters are optional. Depending on the case, use no filters, one filter layer, or two filter layers. The key question is whether the filters actually help move work forward.

Use this decision logic:

If the system can already push the relevant tasks clearly and the page goal is narrow, use no filters
If only page-wide scope needs to change, use one filter layer
If both page scope and main-area presentation need independent control, use two filter layers

Page-level filters define whole-page context across the workspace. Use them only for conditions that truly change the available work pool, such as:

Time
Organization, region, campus, or project
Owner
Search within the current page

Rules:

If it changes the left-side task pool, it belongs here
Usually show 0 to 4 of them
Keep them few and strong

Main-column local filters only change the main work area, such as:

View switch
Sort
Grouping
High-risk only
Incomplete only

Rules:

Only change the main work area
Do not secretly rebuild the left-side task pool
They can be more detailed, but should not take over the page
Omit them when the main work area is already clear enough

Decision rule:

Changes the left task pool -> page-level filter
Only changes the main view -> local filter
Neither is needed -> no filter

Do not disguise business tasks as top-bar filters. Labels such as To handle, Overdue and incomplete, or High risk usually belong in the left-side work finder or queue.

5. Main Work Area

The main column is the real workspace surface.

In the 2-column pattern, the main column normally has two major states:

State A: Category Work View

After entering a category, the main area may show a category-level workspace such as:

Cards
List
Board
Timeline
Calendar
Mixed view

This is appropriate when the selected work pool benefits from a structured operational view.

State B: Task Detail / Action Surface

After selecting a task, the main area should become a task-oriented surface such as:

Detail view
Form flow
Mixed view
Cards with direct actions
Child-item or subtask list

First decide whether the user is advancing one object or screening a batch of objects.

If the user is advancing one object, prefer:

Detail view
Form flow
Cards
Mixed view
Child-item or subtask list when needed

If the user is screening a batch, prefer:

List
Board
Card wall
Chart plus risk list
Timeline or calendar when time structure matters

These situations usually should not default to a plain list:

Shift and staffing allocation
Time scheduling
On-site execution
Single-object handling
Risk judgment

Make these clear:

Default view
Switchable views
Focus object or focus task
Core actions that can be completed on the page
Whether the page is in category-work-view state or task-action-surface state

6. Lists Inside The Main Surface

A list inside the main action surface is valid when it helps complete the selected task.

Good uses:

Subtasks
Child records
Checklist steps
Exceptions inside the selected case
Related people, lessons, or contract lines that must be handled as part of the current task

Avoid using the main area as just another generic queue unless the job really is batch screening.

7. Right Drawer

The drawer is auxiliary, not the main flow, and it is optional.

Suitable content:

Rule explanation
History
Notes
Related objects
Candidate options
Secondary actions
Risk explanation

Not suitable:

The full primary flow
A whole complex subsystem
Core handling actions that belong in the main work area

Explain:

Whether a drawer is needed at all
When it opens
What it contains
Which secondary actions can be completed there
Why those items belong in the drawer instead of the main area

8. Width, Splitter, And Responsiveness

Use this section only when the task requires layout implementation detail or responsive behavior.

Prefer a 2-column desktop layout with a user-resizable splitter.

Default guidance:

Left column: about 25% to 30%
Main column: about 70% to 75%
A strong starting point is around 30 / 70

Implementation guidance:

Prefer min/max widths over strict percentages
Left column often works well around 320px to 380px on desktop
Main area should remain dominant

Splitter guidance:

Allow user resizing on desktop
Use min/max guardrails
Remember the user preference when possible
Do not put splitter position in browser history

Responsive guidance:

Desktop: 2-column layout
Narrow desktop / tablet: keep the main area dominant; reduce or collapse the left column if needed
Mobile: serialize the same hierarchy into drill-down screens

9. Routing And Browser History

Use this section only when the task requires routing, deep linking, browser history, or shareable navigation state.

Treat the workspace as a navigable hierarchy:

workspace -> scope -> task -> step

Routing rules:

workspace = workspace root
scope = selected category or work pool
task = selected work object
step = major operation step or subtask flow

Back behavior should normally be:

step -> task -> scope -> workspace

Push history when:

Entering a scope
Opening a task
Entering a major operation step
Switching to a different task or scope

Use replace or local state when:

Correcting an invalid route
Restoring a default subview
Opening or closing an optional drawer
Changing splitter width
Changing minor local display controls

Deep-link rules:

Routes should be directly openable when routing is part of the task
Invalid scope should fall back to workspace root
Invalid task should fall back to scope
Invalid step should fall back to task
Use replace for corrective fallbacks

View-mode rule:

Put major shareable view modes such as cards, list, board, timeline, or calendar in shareable state only when they meaningfully change the page
Keep minor UI toggles local

Anti-Patterns

If any of these dominate the page, it likely behaves more like an admin console or a fake workspace:

A giant table is the first thing visible
The top area is crowded with filters
The left side is a module tree or app navigation sidebar
The left side shows issue categories only, and the main area becomes just a list of tasks in that category
The main area is just an enlarged list with row-end actions
Most actions are row-end buttons
Cards only show numbers and do not connect to work
The drawer is only a detail dump
The system never pushes relevant work, so the user must search first
Mobile tries to preserve desktop columns instead of using drill-down
Browser back breaks the work hierarchy or exits the page unexpectedly

Output Protocol

Use this structure by default. Merge or reorder sections when that produces a better result.

0. Assumptions

Only include this when information is missing.

1. Page Positioning

Page title
One-line positioning statement

2. Situation Cards

Usually list 4 to 6 cards. For each card include:

Name
Why it changes priority
Where it drills down
Which operating period it represents

3. Left Column Structure

Whether it is one level or two levels
If two levels, define:
- Level 1: ALL + work categories
- Level 2: Back + task queue
Task queue item pattern

For each entry point, explain:

Why it exists
What work enters it
What the task queue looks like
What main-area state follows after selecting a task

4. Filters And Quick Actions

Whether filters are needed
Page-level filters
Main-column local filters
Advanced filters
Quick actions

Also explain:

How the default context is established
Why you chose no filters, one filter layer, or two filter layers
Which page-level filters show by default, if any
Which local filters show by default, if any

5. Main Work Area

Category work view
Task detail / action surface
Default view
Switchable views
Focus object or focus task
Actions that can be completed directly on the page
Whether lists inside the main surface are subtasks, child-item lists, or batch screens
Why this view fits the work best

6. Right Drawer

Whether it is needed
When it opens
What it contains
Actions available there
Why it belongs there

7. Mobile Drill-Down (when needed)

Only include this when the task involves responsive behavior, mobile flow, or explicit mobile requirements.

Describe the mobile sequence, normally:

Categories
Tasks
Task
Subtasks / operation

Explain:

Which levels collapse together
Which actions remain on the task screen
Which actions deserve a deeper operation step

8. Routing And History (when needed)

Only include this when the task involves routing, browser history, deep linking, or shareable navigation state.

Describe:

Route hierarchy: workspace -> scope -> task -> step
Which states go into shareable navigation state
Which states stay local
Back behavior
Any major query or view state

Review Mode Additions

In review mode, add these before 1. Page Positioning:

Current Judgment

The current design is closer to: workspace / admin console / mixed but drifting

Main Problems

Usually list 3 to 8 concrete problems
Point to structure, rhythm, action flow, queue meaning, view choice, filter layering, and, when relevant, mobile or routing behavior
It is valid to point out that the left side is being read as navigation instead of a work finder
It is valid to point out that filters were added even though the page does not need them
Avoid vague criticism

Then provide the redesign and cover the core structure above.

Language Guidance

Prefer:

Business action language
Business object language
Time-pressure language
Risk language
Queue language that sounds like work, not modules

Avoid:

Field language
Database language
Generic system labels
App-navigation language when you really mean work scopes

Prefer phrasing like:

Awaiting review
Blocked
Expires within 7 days
More input needed
Ready to publish
Attendance exceptions
Renewal actions
Contracts awaiting confirmation

Avoid phrasing like:

Status = pending
Priority = high
Type = normal
Manage contracts
Student module

Completion Standard

The result is complete only when all of these are true:

The page name describes an action rather than a module
The top area establishes the situation and connects to real work
The left side acts as a staged work finder rather than app navigation
The left structure is chosen appropriately as one level or two levels and lands on actionable objects quickly
Queue entry points come from workflow, risk, time pressure, or handoff logic
The filter strategy is appropriate, including no filters, one filter layer, or two filter layers
The main work area supports direct progress on the core action
Lists inside the main area are justified as batch screens or subtask / child-item working lists
The drawer remains auxiliary and optional
When mobile behavior is part of the task, it is handled as drill-down rather than squeezed desktop columns
When routing or browser history is part of the task, they support the hierarchy of workspace -> scope -> task -> step
The page clearly moves away from the admin-console pattern of filters, tables, and row actions
The output covers the key page structure and design decisions, plus mobile or routing behavior only when relevant