Prototype Builder

Prototype Builder

Overview

Use this skill to convert planning and design documents into a runnable UI prototype quickly, without pretending the prototype is a fully integrated product.

The main goal is to make the IA explorable, the role split understandable, and the key screens reviewable in the browser.

Trigger Cases

Use this skill when the user asks for things like:

• 프로토타입 만들어줘
• 문서 기반으로 화면 붙여줘
• IA 기준 누락 화면 추가해줘
• 시연용으로 빠르게 만들어줘
• 백엔드 없이 프론트 프로토타입으로 보여줘

This skill is also appropriate when the user wants representative pages, placeholder screens, and menu coverage before real backend integration.

Workflow

1. Read the documents first.

• Identify the planning doc, IA/info architecture doc, and screen design doc.
• Determine whether the docs are:
  • target-system baseline
  • current prototype baseline
• Preserve screen IDs like EXT-01, INT-07, AIX-02 when they exist.

2. Define prototype interpretation rules.

• Clarify whether the prototype is:
  • full implementation
  • representative demo
  • IA coverage prototype
• Explicitly separate:
  • implemented
  • partially implemented
  • missing
• If entry uses role cards, interpret them as portal -> representative role unless the docs clearly define real IAM.

3. Align routes and menus before deep UI work.

• Check whether each documented screen has:
  • a route
  • a visible menu path when appropriate
  • a page file
• If the IA is missing screens, add minimal routes and pages first.
• For prototypes, it is better to have an explorable placeholder screen than a dead IA branch.

4. Build representative screens, not fake completeness.

• Without backend integration, prioritize:
  • representative cards
  • summary tables
  • action buttons
  • section titles that explain the screen purpose
• Do not overbuild fake business logic.
• Make it obvious which parts are demo-only and which parts are intended future actions.

5. Reuse shared UI patterns aggressively.

• Prefer a common placeholder or section pattern for missing screens.
• Reuse shared layout, metric cards, tables, and status chips.
• Keep visual consistency higher than per-screen uniqueness at this stage.

6. Keep documents in sync.

• Update planning docs when the prototype interpretation changes.
• Update design docs when routes, menus, or screen coverage change.
• Note when a screen is only placeholder-level.

7. Verify.

• Run:
  • npm run build
  • npm run lint
• Keep a local dev server available when browser review is needed.
• Use Playwright when the user wants visual confirmation or walkthrough.

Prototype Standards

• A prototype may omit real backend actions such as:
  • actual save/submit
  • live query/download
  • real auth
  • full state transitions
• But it should still make these clear:
  • what the screen is for
  • who uses it
  • where it sits in the IA
  • what action would happen later

Placeholder Rule

When missing screens block the IA, add placeholder pages that include:

• screen ID
• screen title
• short business purpose
• 2-4 representative highlights
• 2-4 representative action areas
• a short list of next implementation steps

This is better than leaving the route absent.

Output Pattern

When reporting work done, use this order:

1. planning docs updated
2. design docs updated
3. routes/menus/screens added or changed
4. verification results
5. commit/push status under ask-before-push rules

Notes

• This skill is for fast, document-driven frontend prototyping.
• If the user later asks for real functionality, continue from this prototype using the normal spec-first workflow.