Intent UI: Interaction Specifications for Action
Convert business goals into justified feature scoping, operational rules, and observable acceptance criteria. The process layer determines "how work progresses and what deliverables are produced," the methodology layer constrains "how AI thinks and self-checks," the business layer decides "what capabilities are needed," and the component layer dictates "how these capabilities are understood and operated." Defaults to Chinese, targeted at collaboration between product, design, frontend, and test; not tied to any framework or requiring installation of any reference project's component library.
Core Constraints
- First determine the user's task, then decide on the page and components. Just because a database table exists does not mean the user needs a CRUD interface for it.
- Distinguish between "interaction baselines that all related pages must satisfy" and "capabilities that must be provided only when business conditions are met." When conditions are unknown, mark as pending confirmation; do not arbitrarily classify as optional.
- Operations depend on the business object, its current state, user permissions, associated dependencies, and sphere of influence. Do not merely list a static set of buttons.
- Distinguish between business deactivation, control disabling, read-only, deletion, archiving, undo, and rollback; ensure consistency in naming, results, and recovery methods.
- Explain both what is provided and why something is omitted, along with what changes would trigger a re-evaluation. When users request simplification, retain the already-applicable error recovery and status feedback.
- Reference Cloudscape's patterns and selection rationale; business capability matrices, approvals, task recovery, etc., are backend extension rules of this Skill and should not be presented as official Cloudscape requirements.
- At the component layer, verify keyboard and focus behavior against native semantics and corresponding APG patterns; supplement with scenario principles from Carbon and Ant Design, and implementation experience from Radix and React Aria. Do not treat library defaults as universal component specifications, and do not claim these projects share a unified standard.
- Do not turn the button order, number of fields, modal size, or time thresholds of one product into universal hard metrics. Respect existing product specifications; when conflicts arise, explain the trade-off and its impact on users.
- Do not perform actual deletions, deactivations, approvals, exports, or permission changes just from writing or reviewing specifications. Only modify corresponding code when the user asks for implementation, following their authorization scope.
Select Working Method Per Request
| User Intent | What To Do | Delivery Scale |
|---|---|---|
| Create general specifications | Establish conditional rules and scenario examples; do not invent specific business logic | Specifications, capability matrix, acceptance template |
| Design a specific module | Derive required capabilities from known flows and data states | Module decision table, page interaction contract, acceptance scenarios |
| Design or review a backend component's behavior | Clarify component semantics, states, input methods, and composition boundaries | Component selection rationale, behavior contract, necessary interaction check |
| Review an existing backend | Identify gaps against visible pages, requirements, or source code | Evidence-based issues, impact, minimal fixes, and acceptance |
| Extract or apply reference backend style | Analyze pages and source code; select composition, token roles, and interaction patterns per task | Executable style conventions, adaptation boundaries, acceptance points |
| Implement or fix interactions | Implement the defined scope within the existing architecture | Code changes, corresponding verification, remaining dependencies |
Specification requests do not automatically expand into code refactoring; review requests do not automatically refactor the entire backend. For simple pages, output only the necessary decisions and rules.
At the start of any design task, follow Design Workflow to determine process depth, stage progression thresholds, and the deliverable chain; when AI drafts interfaces, drives generation tools, or collaborates via multiple agents, first execute the pre-generation self-calibration and failure mode prevention from AI Design Method.
Establish Business Context
Prioritize reading requirements, flows, screenshots, existing pages, and related source code provided by the user. Only review materials relevant to the task. Distinguish between observed behavior, documented requirements, and assumptions; a single screenshot cannot assert that backend permissions or asynchronous recovery have been implemented.
Extract the minimum information that influences decisions:
- Who completes what task within what scope; main entry points and completion indicators.
- Whether data is user-maintained, externally synchronized, or system-generated; which fields or records are mutable.
- What business states the data goes through, which state transitions are valid, and who can trigger them.
- Whom an operation affects, whether it is reversible, any associated dependencies, whether there are long-running tasks or concurrent edits.
- Constraints imposed by data size, usage frequency, working devices, and existing specifications.
When context is missing, first provide a customizable solution for "generic web backend" and clearly state assumptions. Only ask questions about gaps that would change key decisions; continue processing the unaffected parts. Without evidence, do not assume permanent deletion, unauthorized operations, or a full task center.
Select Capabilities
When defining or reviewing feature scope, consult Capability Decision. Build a capability matrix for the modules in scope, marking each item as:
- Base Required: The bare minimum that must exist for this type of interaction to be present (e.g., loading data requires recognizable loading and error states).
- Conditionally Required: Must be provided when specific business conditions are met; document the conditions and evidence.
- Optional Enhancement: Beneficial but does not block the core task; can be scheduled or omitted.
- Not Applicable: Irrelevant or disallowed for the current business; explain why.
- Pending Confirmation: Insufficient evidence; this is a decision state, not a pretense that it can be omitted.
High implementation cost does not equal "not applicable"; a missing API does not mean the capability is unnecessary. Record both business necessity and prerequisites for implementation.
Select Specific Rules
Read only the reference documents relevant to the scope; do not load all by default:
| Scope | Read |
|---|---|
| Design stage orchestration, diverge/converge, deliverable chain, design specs and handover | Design Workflow |
| AI-generated interfaces, design context degradation, failure mode prevention, multi-agent division of labor | AI Design Method |
| Navigation, workbench, lists, search, filtering, details, charts | Navigation and Data Browsing |
| Add, edit, validation, enable/disable, delete, archive, batch operations, import/export | Operations and Forms |
| Loading errors, permissions, multi-tenancy, concurrency, async tasks, approval/release, notifications, accessibility | States and Workflows |
| Component selection, state language, keyboard, focus, overlays, component composition | Component Interaction Language |
| Heuristic evaluation, cognitive walkthrough, accessibility acceptance, experience metrics, design QA | Design Evaluation |
| Design system governance, design tokens, component documentation templates, consistency audit | Design System and Token Specifications |
| Extract or apply reference styles (e.g., NextLabs, LarkAgentX), high-frequency workspaces, operations consoles, and companion display surfaces | Tool Interface Style |
| Output specifications, review reports, acceptance, scenario walkthroughs | Delivery and Review |
| Reference Cloudscape business patterns | Cloudscape Sources and Adaptation Boundaries |
| Reference APG, Carbon, Ant Design, Radix, or React Aria component rules | Component Sources and Difference Handling |
| Reference process models, evaluation methods, or design system sources | Process, Evaluation, and Design System Sources |
| Reference NextLabs, LarkAgentX case evidence and verification boundaries | Tool Interface Style Sources |
For every actual operation provided, document: Entry point and target object → Permissible states and permissions → Input or confirmation → During execution → Success result → Failure or unknown result → Return location and recovery method. Non-applicable steps can be omitted with explanation; do not force a confirmation dialog for viewing details.
For objects with a lifecycle, provide a "state × operation × role" matrix; for multi-step tasks, describe saving, leaving, recovery, and partial completion. Use compact tables or Mermaid diagrams for branches or many states; do not force diagrams for single-step operations.
When a request explicitly involves designing, reviewing, or implementing a specific component, read the relevant parts of the Component Interaction Language; do not expand the full component list when only making business feature trade-offs. Components may look similar but behave differently; especially check menus vs. selectors, switches vs. checkboxes, tooltips vs. interactive overlays, and ordinary tables vs. data grids.
Pre-Delivery Check
- Can each feature selection be traced back to a task or business rule? Are there any baseless full CRUD, dashboards, or batch operations?
- Do the same operations on lists, detail views, quick entries, and batch entries follow consistent conditions?
- Are empty data, no matches, load failures, insufficient permissions, and stale data distinguished?
- Is a request being accepted mistaken for completion? Is a timeout mistaken for certain failure, allowing duplicate submission?
- Are operations like delete, deactivate, and publish clearly scoped? Does the recovery capability actually exist?
- Can the main flow, failures, permissions, status changes, partial success, and applicable keyboard flows be verified?
- Are component semantics, focus, selection, and executing states consistent? Do nested overlays, custom wrappers, and different input methods break established behavior?
- Does the output declare the process path followed and the reason for any skipped stages? Does an AI-generated interface include a state completeness check result?
When referencing outputs, link to specific pattern pages and distinguish official patterns from your own business suggestions. When online verification is impossible, use built-in summaries, state the reference date and the parts that could not be verified, and do not claim it is the latest version.