Design low fi prototypes

Design Low-Fidelity Prototypes

Create a visible, teachable, interactive, and implementation-ready low-fidelity package. Respond in the user's language. Resolve bundled paths relative to this skill directory.

Select the smallest mode

Read workflow modes and choose exactly one starting mode:

• Use quick prototype by default. Keep one-off and beginner requests simple.
• Use managed project only for long-running revision, review, traceability, or development handoff.
• Add live workspace only when the user requests visible real-time Agent-to-browser changes.

Hide internal IDs and files unless the user asks. Let the user create and revise with natural language; use scripts for fragile bookkeeping, validation, and live synchronization.

Preserve the boundary

• Design structure, flow, components, states, rationale, dimensions, and handoff.
• Keep most surfaces neutral. Use the semantic palette in low-fi color; do not invent brand styling.
• Do not implement the production application unless separately requested.
• Abstract useful structures from references; never reproduce a named product screen.
• Treat the JSON specification, not generated HTML, as the source of truth.

Follow the workflow

1. Select the workflow mode, then inspect existing product notes, routes, and UI structure without changing production files.
2. Identify one primary user, one scenario, one core task, the platform, and the first meaningful outcome. Ask at most three questions only when missing information changes the structure.
3. Separate must have, later, and non-goals.
4. Read cross-platform foundations, then pattern selection and exactly one platform adapter:
   • Web: web patterns
   • Native app: app patterns
   • WeChat mini program: mini-program patterns
   • Desktop: desktop patterns
5. Map entry, core action, outcome, and recovery before composing screens. Use 3–8 screens for one focused flow.
6. If the requirement exceeds eight screens, has multiple global destinations, or represents a complete product, read large projects. Create separate module specs and a project-manifest.json; do not create one unbounded JSON.
7. Read core components, interactions and states, and dimensions.
8. Read comparable product references. Choose two to four official, mature products with a similar structure. Record exactly what to observe and how to adapt it; never copy a screen.
9. If the product itself uses AI, also read AI product states.
10. Write each wireframe-spec.json as Spec v2 using wireframe specification:

• Give every component a stable ID and registered type.
• Build cards, list items, controls, tables, and overlays as component trees. Never encode a composite UI as one text string.
• Give every primary action a real target or state change.
• Make every non-default state patch real nodes. Description-only states are invalid.
• Define canvas, safe area, grid, spacing, radius, and touch-target data.
• Select an explicit shell template and semantic slots so navigation bars, sidebars, inspectors, baskets, and status bars cannot drift with content height.
• Use registered SVG icons with accessible labels and deliberate circle, square, rounded, or pill shapes.
• Treat structural container labels as inspector metadata, never visible product copy.
• Use platform glyph baselines independently from hit-target dimensions.
• Make every bottom-navigation item reach a real screen; exactly one item is selected per destination.
• Put basket/checkout summaries in actionbar above the global bottombar; never let fixed surfaces share one slot.
• Include two to four reference objects with official URL, study points, and adaptation guidance.

11. For a modular project, assemble project-spec.json with assemble_project.py. Otherwise use the single flow spec directly.
12. Run python3 <skill-root>/scripts/validate_spec.py <spec-path>. Fix every error and review every warning.
13. Run:

python3 <skill-root>/scripts/render_wireframes.py <spec-path> \
  --output <artifact-dir>/interactive-prototype.html \
  --pattern-board <artifact-dir>/pattern-board.html \
  --handoff <artifact-dir>/handoff.md

14. In a real browser, test internal navigation, back, overlays, every global destination, at least one non-default state, dimensions, component inspection, wide/narrow behavior, and overflow. For full projects, test one route per module and all cross-module transitions.
15. Apply quality rubric before delivery.

The interactive prototype is the focused working surface. Keep product definition, main flow, MVP scope, comparable references, and the state matrix available through the Design Basis drawer and the separate learning board; do not stack those sections under the device and turn the working page into a long report. Inside the drawer, use one vertical reading column for product definition, flow, MVP, references, and matrix sections; never reuse a dashboard-style multi-column overview that can squeeze prose into vertical fragments. Preserve every app and mini-program canvas at its declared logical dimensions and scale the complete device uniformly when needed.

For managed projects, read managed revisions before the first change. For live workspaces, also read live preview and keep the preview process running during revision.

Produce portable artifacts

Store mutable work outside the Skill directory:

artifacts/<product-slug>/
├── project-manifest.json      # full projects only
├── modules/                   # full projects only
├── project-spec.json          # full projects only
├── wireframe-spec.json        # single focused flows only
├── pattern-board.html
├── interactive-prototype.html
└── handoff.md

Managed mode may also add immutable changes/CR-*/ records. Live mode may add ephemeral .runtime/ files; never commit or deliver .runtime/ as project history.

• pattern-board.html teaches the selected structures, shows screen anatomy, and links comparable official products with observation guidance.
• interactive-prototype.html supports product-internal navigation, back, overlays, counters, toggles, and real state changes.
• Full projects add module navigation without flattening every screen into one tab row.
• On desktop review surfaces, allocate space as vertical page rail | device preview | page notes; do not flatten five or more pages into a long horizontal toolbar. Put product metadata, canvas size, dimensions, inspection, native-size, and design-basis controls inside the page rail; never reserve a persistent full-width toolbar above the device preview. Keep any live event timeline compact so the prototype remains the dominant work area. Preserve the declared device aspect ratio and enlarge it only by uniform scaling. For App and mini-program presets, the declared canvas size is the complete device frame, including simulated top and bottom chrome.
• Keep both HTML files self-contained: no CDN, remote font, authenticated resource, private task ID, or user-specific path.

Revise safely

Never hand-edit generated HTML. Locate stable node IDs in editable JSON sources, make the smallest source change, validate, re-render both HTML files, and re-test the affected route.

In quick mode, a narrow revision may use a temporary revision-patch.json; preserve unrelated screens and states. If a change alters navigation or the primary task, update the flow and handoff as well.

In managed mode:

1. Start an immutable change request with revision.py start.
2. Write a Patch v1 file from the user's natural-language request.
3. Run revision.py impact; show a short impact card and unresolved material questions.
4. Require revision.py approve for medium/high risk.
5. Run revision.py apply. It must stage the patch, verify source hashes, validate, render, snapshot before/after, and promote only after success.
6. Return the change ID, affected pages, validation result, and history path. Do not silently overwrite or reuse a failed change.

When live mode is active, first start live_preview.py and open its printed localhost URL, then apply the revision. revision.py emits visible progress events automatically. Keep the Agent as the approval channel; use the browser as the visual feedback channel. Each atomic patch must visibly select and label its stable screen/node target before the final artifact reloads. A file:// artifact is static delivery, never a live workspace. Never stream incomplete token-by-token DOM edits.

For legacy v1 input, run:

python3 <skill-root>/scripts/migrate_spec.py <v1-spec> --output <v2-spec>

Treat migrated legacy-strip nodes as incomplete. Replace them with typed product components before delivery.

Adapt to the runtime

• Always create portable files first; vendor-specific inline previews are optional.
• If a browser is available, open the interactive prototype and learning board.
• If the user requests real-time visible revisions, run live_preview.py <project-dir>, open the printed local URL, and keep the process alive until the working session ends.
• If only a terminal is available, return absolute paths and a local preview command.
• If visual inspection is impossible, state that limitation; do not claim interactive QA passed.
• Another agent should receive wireframe-spec.json for a single flow, or the manifest, module sources, and project-spec.json for a full project, plus handoff.md; never hand off only screenshots or generated HTML.