swapped docs symlink

2026-08-07 21:07:23 -05:00
parent 5005cd7001
commit f240486a7e
92 changed files with 69 additions and 42 deletions
@@ -0,0 +1,89 @@
+---
+icon: lucide/messages-square
+prompt:
+   version: "1.0.0"
+   description: Extract a user-selected component from a JSFiddle page layout and implement it as a reusable NiceGUI render function.
+   tags: [nicegui, components, frontend, refactoring, jsfiddle, prompts]
+   arguments:
+      component:
+         description: Visible label, semantic role, or selector identifying the component.
+         required: true
+      source_layout:
+         description: Optional source HTML and CSS.
+         required: false
+      target_location:
+         description: Optional target NiceGUI page, module, or package.
+         required: false
+      behavior_requirements:
+         description: Optional interactions, state, callbacks, or variations.
+         required: false
+---
+
+# NiceGUI Component Extraction
+
+Extract one user-selected component from the output of the [JSFiddle Page Layout](../jsfiddle-page-layout/PROMPT.md) prompt and implement it as a reusable NiceGUI component in the target repository.
+
+## Supplied Inputs
+
+- `component`: {{component}}
+- `source_layout`: {{source_layout}}
+- `target_location`: {{target_location}}
+- `behavior_requirements`: {{behavior_requirements}}
+
+## Inputs
+
+1. `component`: required visible label, semantic role, or selector identifying the component to extract
+2. `source_layout`: optional HTML and CSS; when omitted, use the latest applicable JSFiddle page layout output in the conversation
+3. `target_location`: optional target page, module, or package; infer it from the repository when omitted
+4. `behavior_requirements`: optional interactions, state, callbacks, or content variations
+
+If the selected component or source layout cannot be identified unambiguously, ask one concise clarification question before editing.
+
+## Required References
+
+Apply both references before implementation:
+
+1. Component boundaries, responsive layout, Quasar props, Tailwind utilities, and shared CSS: [NiceGUI Page Layout and Styling](../../skills/nicegui/references/architecture-and-styling.md)
+2. Typed UI state, propagation, mutable defaults, binding strictness, and version checks: [Binding Dataclasses Deep Dive](../../skills/nicegui/references/binding-dataclasses.md)
+
+## Workflow
+
+1. Locate the selected region in the source HTML and CSS, including its responsive rules, states, and dependencies on surrounding layout.
+2. Inspect the target repository's NiceGUI version, package structure, component conventions, shared CSS loading, and nearest page call site.
+3. Define the smallest reusable API for the component:
+   - name the public function `render_<component_name>` using snake_case
+   - accept content, typed state, and event callbacks as explicit parameters
+   - keep business rules, persistence, and service access outside the component
+   - preserve an established return-value convention; otherwise return the component's root NiceGUI element
+4. Translate semantic HTML into native NiceGUI and Quasar elements. Do not embed the original page wholesale with `ui.html` when standard components express the structure.
+5. Recreate only the CSS needed by the extracted component:
+   - use Quasar props for component appearance and behavior
+   - use NiceGUI classes and Tailwind utilities for spacing, sizing, alignment, and responsive layout
+   - use scoped shared CSS only where props and utilities are insufficient
+   - do not override Quasar field internals or duplicate globally loaded styles
+6. Model editable or shared component state with a typed `@binding.bindable_dataclass` only when binding improves the interaction:
+   - use `field(default_factory=...)` for mutable defaults
+   - scope state to the appropriate page, client, or user
+   - keep binding transforms pure and inexpensive
+   - assign updated collections back to bound fields instead of relying on in-place mutation
+7. Integrate the render function at the nearest target page or call site without moving unrelated page composition or domain logic into the component.
+8. Preserve accessibility, focus behavior, text wrapping, stable dimensions, and the source layout's visual hierarchy.
+9. Run the narrowest available tests, lint, and type checks for the changed files. For visual components, verify representative mobile, landscape desktop, and portrait desktop viewports when browser tooling is available.
+
+## Output Contract
+
+Complete the implementation in the target repository, then report:
+
+1. Files created or updated.
+2. The `render_*` function signature and its state or callback contract.
+3. Any deliberate visual or interaction differences from the JSFiddle source.
+4. Validation commands and outcomes, including viewport checks when performed.
+
+## Quality Rules
+
+1. Extract exactly the requested component and its necessary local dependencies.
+2. Prefer the target repository's established patterns over introducing a new abstraction style.
+3. Keep the component presentation-focused and reusable across pages with compatible data.
+4. Do not add a bindable dataclass for static content or event-local state that is clearer as ordinary parameters.
+5. Do not create a second component tree for mobile; use responsive classes and stable layout constraints.
+6. Keep custom CSS tokenized, scoped to the component, and loaded once by the application's composition layer.