Open Flow Frontend Development

This skill defines frontend conventions for shared UI, forms, the canvas, Workbench, and host integration. Paths beginning with src/ are relative to packages/open-flow/; other repository paths are relative to the repository root. Use production code as the source for component usage.

Core workflow

• Identify the component that owns the behavior and its affected consumers. Correct shared behavior at its owner and keep feature-specific requirements local.
• Prefer existing components, tokens, and public interfaces. Preserve required state, language, theme, coordinate, clipping, stacking, and dismissal contexts when composing UI.
• Components own interaction semantics. Preserve keyboard operation, accessible names, state communication, focus restoration, expected opening and closing behavior, real link semantics, and reduced-motion behavior.
• Icon-only action buttons and links must use the shared Tooltip as well as a localized accessible name. A native title is not a substitute. Hosts use HostTooltip from @oomol-lab/open-flow/ui; product components use the shared UI Tooltip primitives. Verify keyboard focus and hover, preserve the surrounding theme, and keep dynamic hints in sync with the current state.
• When adding, replacing, or choosing icons, use the iconify-icons skill. Lucide icons use i-lucide-light:<name>, not i-lucide:<name>; existing lucide-react components use strokeWidth={1.5}.
• Prefer Lab for appearance and interaction checks. Maintain related Stories and add missing states. Supplement Lab with the product when host layout or a complete flow matters. Consult the Lab documentation only when changing Lab infrastructure or deployment, or when an unfamiliar Story API requires it.
• For appearance or interaction changes, verify the affected states in Lab or the product. Static checks do not establish visual correctness. Report material verification gaps.

Task-specific references

Read only the references relevant to the task; read more than one when the change crosses domains.

• For Value Node, Inputs, value editors, inspector navigation, field or node settings, and property-panel layout or interaction, start with Property panel contracts, then read only the routed detail relevant to the task.
• For shared controls, themes, host-facing UI, spacing, visual styling, shared browser UI, or localization, read Shared UI and visual design.
• For standalone forms, Schema-controlled values, validation drafts, or shared code editors, read Forms and editors.
• For canvas, Workbench, sidebar composition, node menus, canvas popovers, or undo/redo behavior, read Canvas and Workbench.