| name | nexus-ui-mockups |
| description | Create or update standalone UI mockups for Nexus before implementation. Use when the user asks for a new view, modal, workflow, layout refactor, or other substantial UX change that should be reviewed in `docs/mockups/` before production code. |
Nexus UI Mockups
Use this skill when the task is primarily about shaping or reviewing UX before implementation.
When to Use This Skill
Use it when the user:
- Wants a new screen, panel, modal, toolbar, board, or flow
- Is redesigning an existing UI surface
- Wants to explore interaction options before wiring real plugin state
- Asks for a mockup, prototype, preview, or design artifact
Skip it for tiny visual tweaks unless a mockup would materially reduce implementation risk.
Output Location
Create mockups in docs/mockups/.
Default file shape:
docs/mockups/<feature-name>.html
docs/mockups/<feature-name>.css
docs/mockups/<feature-name>.js
For very small previews, a single self-contained HTML file is acceptable.
Required Pattern
- Build the mockup first, before editing production UI code, when the UX is still being defined.
- Keep it standalone. No framework, bundler, or app bootstrapping.
- Use realistic Nexus copy and sample data. Do not use placeholder lorem ipsum unless the exact text is irrelevant.
- Match the product's visual language with CSS custom properties and Obsidian-style tokens.
- Show the important states and interactions:
- empty/loading/error when relevant
- hover/focus/selected states when relevant
- in-memory interaction simulation for drag/drop, filters, editors, or other flows
- If the mock simulates persistence, say so plainly in the UI copy, for example "updated in this mock".
- After the mockup is accepted, implement the real UI separately under
src/ and move production styling into styles.css.
Repo References
docs/mockups/task-board-view.html is the reference for larger interactive mockups with separate CSS and JS files.
docs/mockups/compaction-indicator-preview.html is the reference for small focused previews.
Guardrails
- Do not wire mockups into the plugin runtime unless the user explicitly asks for that.
- Do not treat mockup-only inline CSS or local event listeners as permission to use those patterns in production plugin code.
- Keep filenames descriptive and kebab-case.
- Prefer sample data that resembles real workspaces, tasks, conversations, or settings from this repo.