source-faithful-dify-prototype

name	source-faithful-dify-prototype
description	Build source-faithful and Dify-native frontend prototypes for Dify screens and proposed Dify features. Use when the user asks for Dify prototypes, Dify UI screens, Knowledge/Dataset/RAG prototype pages, login/default pages, navigation tabs, modals, tables, creation flows, or any frontend work that must follow Dify source, tokens, components, icons, and visual behavior.

Source-Faithful Dify Prototype

Purpose

Use this skill to create or update Dify prototype screens in:

/Users/x/git/lg/dify-prototype

The goal is not generic UI design. The goal is to build Dify prototypes that are either:

• Existing Screen Clone: source-faithful versions of existing Dify pages.
• New Feature Prototype: Dify-native prototypes for proposed features using Dify source patterns.

Existing screens should match Dify as closely as practical. New features should not claim official fidelity when Dify has no page yet; they must still use Dify components, tokens, layout patterns, and interaction language.

Required Start

Before creating or updating a screen:

cd /Users/x/git/lg/dify-prototype
pnpm sync:dify

Do not assume a local Dify repo. Do not add sync flags or alternate sync modes unless the user explicitly asks.

Read .dify-source.json after sync and remember the upstream commit for the final report.

Source Lookup

Find the nearest Dify source before implementing.

Common mappings:

• Login / sign-in: dify-source/web/app/signin
• Header / main nav: dify-source/web/app/components/header
• Sidebar shells: dify-source/web/app/components/app-sidebar
• Studio / apps list: dify-source/web/app/components/apps
• App detail / app surfaces: dify-source/web/app/components/app
• Knowledge list: dify-source/web/app/components/datasets/list
• Knowledge creation: dify-source/web/app/components/datasets/create
• Dataset documents/detail: dify-source/web/app/components/datasets/documents
• Hit testing: dify-source/web/app/components/datasets/hit-testing
• Workflow: dify-source/web/app/components/workflow
• Tags: dify-source/web/features/tag-management
• English copy: dify-source/web/i18n/en-US

When the user says knowledgebase, knowledge base, or 知识库, map it to Dify datasets.

Implementation Rules

• Use @langgenius/dify-ui/* primitives when available.
• Do not hand-roll visible native form controls when Dify has a primitive. Map common controls first to:
  • @langgenius/dify-ui/select for select/listbox UI.
  • @langgenius/dify-ui/input for text inputs.
  • @langgenius/dify-ui/slider for Top K, temperature, score, and weight sliders.
  • @langgenius/dify-ui/checkbox for checkbox lists and multi-select rows.
  • @langgenius/dify-ui/switch for on/off parameter toggles.
  • @langgenius/dify-ui/number-field, radio-group, popover, and dropdown-menu when the source surface uses them.
• Native <select>, <textarea>, input[type="checkbox"], input[type="range"], and plain text inputs are allowed only when Dify source uses that exact native control or when they are hidden/internal backing inputs generated by Dify/Base UI primitives.
• Use synced Dify tokens, themes, Tailwind classes, icons, and assets.
• Use Dify icon systems: i-ri-*, i-custom-*, @remixicon/react, and synced SVG components.
• Put prototype code, adapters, fixtures, and local state in apps/prototype.
• Do not edit synced upstream mirrors under dify-source/ or synced packages unless the user explicitly asks to change the sync project itself.
• Mock backend data locally. Do not present mocked backend behavior as real.
• Do not invent Dify styling when source has an equivalent.

Workflow

1. Run pnpm sync:dify.
2. Identify whether the request is an Existing Screen Clone or a New Feature Prototype.
3. Locate the closest Dify source paths.
4. Extract page structure, component choices, spacing, typography, icons, states, and copy patterns.
5. Implement only the requested surface in apps/prototype.
6. Keep fixtures small and explicit.
7. Run pnpm build.
8. Start or reuse the dev server.
9. Verify visually in the browser, including the specific user-requested interaction.
10. Run the native control leak audit for touched screens.
11. Report source paths, changed files, validation, and mock boundaries.

Verification

Minimum verification before claiming completion:

pnpm build

For UI changes, also open the local dev URL in the browser and verify the requested screen or interaction. Use screenshots when possible. If screenshot capture fails but DOM and interaction checks pass, state that precisely.

Native Control Leak Audit

Before completing any form-heavy, panel-heavy, workflow, modal, table-filter, or creation-flow prototype, check that visible controls are Dify primitives rather than browser-native defaults.

Source scan:

rg -n '<select|<textarea|<input|type="(checkbox|range|text|number|radio)"|accent-' apps/prototype/src

Treat matches as suspicious unless they are:

• hidden/internal backing inputs emitted by Dify/Base UI primitives.
• non-control text matches such as token class names.
• an exact native-control pattern copied from current Dify source.

Browser audit:

• Inspect visible controls on every touched screen.
• Flag visible native <select>, <textarea>, checkbox, radio, range, or text/number input that is not inside a Dify primitive.
• Ignore 1px hidden/backing inputs generated by @langgenius/dify-ui/select, slider, checkbox, or switch.
• Confirm Dify primitives by checking visible roles/classes such as role="combobox", role="switch", role="checkbox", .group/slider, components-input-bg-normal, and Dify token classes.

Final Report

Include:

• Dify upstream commit from .dify-source.json
• Dify source paths used
• Prototype files changed
• Commands run
• Browser checks performed
• Native control leak audit result when UI controls were touched
• What remains mocked or non-functional

Do not say a new-feature prototype is “100% official” when no official Dify page exists. Say it is Dify-native and source-patterned.