chuxinneko/nekocodedesktop/design

Design

Build the design requested in the user brief that follows this skill block inside the current NekoCode workspace. This is NekoCode's curated in-chat adaptation of OpenDesign with Taste Skill as a contextual frontend craft layer: use the current model, filesystem tools, and browser preview rather than launching a separate design daemon, desktop app, or plugin.

Discovery

If no user brief follows the skill block, ask what the user wants to design before writing files. If a brief exists, infer safe defaults and ask at most three focused questions only when the artifact type, essential content, or destination is genuinely ambiguous. Do not ask the user to choose implementation details that can be derived from the repository.

Before editing, inspect the repository's framework, conventions, dependencies, existing routes, design tokens, DESIGN.md, and likely destination files. Preserve existing work. If the requested destination already exists and replacement was not explicit, ask before replacing it.

Choose one route

Read references/open-design/frontend-design/SKILL.md for every route, then read the matching route completely, including the side files it names:

• General website, landing page, marketing page, or desktop prototype: references/open-design/templates/web-prototype/SKILL.md
• Admin, analytics, operations, or data dashboard: references/open-design/templates/dashboard/SKILL.md
• iOS, Android, phone screen, or mobile app mockup: references/open-design/templates/mobile-app/SKILL.md
• Presentation, pitch, report, or slides: references/open-design/templates/simple-deck/SKILL.md
• A vague brief that needs concrete tokens: references/open-design/design-brief/SKILL.md
• Poster, cover, or static visual: use the frontend craft rules to create an editable SVG or a self-contained HTML poster. Do not claim to have generated PNG/JPEG pixels unless an available tool actually did so.
• Video, reel, animation, or motion study: create a self-contained animated HTML/CSS/JS artifact that the NekoCode browser can preview. Do not claim MP4 export unless an available renderer actually produced the file.

For landing pages, marketing sites, portfolios, editorial or blog surfaces, and redesigns of those experiences, also read references/taste-skill/SKILL.md completely before planning. Treat it as a contextual quality and pre-flight layer, not as a second skill or a replacement for the selected OpenDesign route. Do not apply it wholesale to dashboards, dense product UI, data tables, multi-step flows, native mobile, decks, posters, or motion-only artifacts; its own out-of-scope section explains those boundaries.

The Taste Skill reference describes defaults for many frameworks and optional image-generation environments. The user's brief, the repository's existing stack and conventions, these wrapper instructions, and the design contract below take precedence. Never add a package merely because the reference lists it: first verify the dependency and prefer the project's established system. Use image generation only when an actual image tool is available; otherwise follow this skill's editable-asset and honest-limitation rules. Ignore the upstream block-library authoring path unless the user explicitly asks to build reusable Taste Skill blocks.

The OpenDesign references describe their native project root. Resolve every path against the user's chosen destination in this workspace, not against this skill directory. Treat OpenDesign-only host features such as injected design systems, data-od-id comment mode, <artifact> wrappers, OD_BIN, media dispatch, and daemon metadata as optional context, not available NekoCode tools.

Design contract

1. Lock one specific visual direction before implementation. Use the user's brand or existing DESIGN.md when present; otherwise define a compact local token set covering color, typography, spacing, layout, component shape, states, and motion.
2. Build real usable content, not lorem ipsum or empty decorative shells. Label invented metrics and examples honestly.
3. Follow the existing framework and component system when integrating into an application. For a standalone artifact, prefer one self-contained HTML file with inline CSS/JS and no new dependency.
4. Use semantic markup, responsive layouts, keyboard-accessible controls, visible focus states, sufficient contrast, and reduced-motion handling.
5. Avoid generic AI styling: interchangeable SaaS cards, gratuitous purple gradients, excessive glass effects, uniform pill shapes, decorative blobs, and animation without purpose.
6. Include the states needed by the artifact: hover, focus, active, disabled, loading, empty, and error where applicable.
7. Keep source files editable. Never replace editable output with a screenshot.

Output placement and preview

Honor an explicit target path. When adding to an existing application, integrate into its established route/component structure. For a standalone artifact with no requested location, write directly in the workspace root, normally as index.html, and keep any local assets in root-relative asset paths. If that destination already exists, ask before replacing it. Do not overwrite a root DESIGN.md; reuse it when present, or place artifact-specific design notes beside the output.

After writing a standalone HTML file, let NekoCode's browser preview open it. For an application route, run the narrowest available validation and start its existing development server only when runtime verification is needed. Never guess a server URL or claim visual verification that was not performed.

Review and delivery

Use browser_check when available to record assertions on the real page: document horizontal overflow and expected selectors, text, visibility, enabled state or viewport intersection. Exercise controls with browser_action first, then assert the resulting state. Use acceptance_check to register important acceptance criteria; passing or failing criteria must cite actual tool-call evidence, while skipped or unverified criteria need an honest reason. A successful evaluate or navigation is not a passing assertion. Repeat browser_check after restoring the natural panel viewport.

Validate the actual top-level preview page. With browser_viewport, check desktop (1440×900) and mobile (390×844); the preview is scaled to fit the panel, while DOM geometry and input coordinates remain in the requested CSS pixels. Confirm innerWidth/innerHeight, compare document scrollWidth with clientWidth, and inspect overflowing containers and important element bounds. A temporary iframe or modified copy of the DOM is not evidence that the real preview passed. If viewport tools fail, report that limitation instead of claiming responsive verification. Fix layout causes in the source; do not hide document overflow to mask clipped content. Before delivery call browser_viewport with { "reset": true }, then verify the actual panel width and leave this natural viewport visible for the user.

Default webpage QA is element-based and requires no screenshots, even when the model accepts images. Use the available browser tools to read DOM/accessibility elements, text, visibility, geometry, computed styles and overflow at desktop and mobile sizes; exercise controls and verify the resulting element state, keyboard behavior and reduced motion. Take screenshots only when the user explicitly requests screenshots or image comparison. If image inspection is unsupported or unreliable, stop screenshot attempts and report that limitation. Element checks do not prove complete visual fidelity. After a targeted correction and recheck still fails, or checks produce no new evidence, stop repeating verification and report the remaining issue. Before finishing, check desktop and mobile behavior, text overflow, hierarchy, interaction states, keyboard use, contrast, and reduced motion. Run the repository's relevant typecheck/build when available. Report:

• artifact type and visual direction
• files created or changed
• preview or validation actually performed
• any export limitation or remaining discrepancy

PNG/JPEG model generation and MP4/PPTX/PDF export are not bundled with this curated integration. Offer the editable SVG/HTML/deck source instead unless a compatible installed tool is actually available.

Attribution

Adapted from OpenDesign 0.22.2 by nexu-io under Apache-2.0. The selected upstream references are bundled under references/open-design/; see the repository's licenses/OpenDesign-LICENSE.txt and third-party notices.

The frontend craft layer bundles Taste Skill's design-taste-frontend v2 experimental reference by Leonxlnx under MIT, pinned to commit 4843a7fdb4fb7320d4e3c021df72ee393d1dcf3e; see references/taste-skill/SKILL.md, the repository's licenses/TasteSkill-LICENSE.txt, and third-party notices.