# Prototype Builder

> Use when the user wants to build or expand a frontend prototype from planning, IA, and screen design docs, especially for requests like `프로토타입 만들어줘`, `문서 기반으로 화면 추가해줘`, `빠르게 시연용 화면 붙여줘`, or `IA 기준 누락 화면 메워줘`. This skill turns requirements and design docs into a runnable prototype by aligning routes, menus, representative pages, placeholder flows, and document updates.

- Skill: `kim-dh2417/prototype-builder` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kim-dh2417/prototype-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kim-dh2417/prototype-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: kim-dh2417 (https://skillmd.com/u/kim-dh2417)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kim-dh2417/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.