SuperAPI AI Directory
Partner中文AI newsFavorites
Skillspeach-team-ui-proto

peach-team-ui-proto

Coding & development

View repository

Updated 10-15 23:57

About this skill

Peach Team UI Proto

A planning-concretization deliverable skill that creates and verifies ui-proto screens.

The core of this skill is not team automation, but concretizing human intent into screens/actions/states to produce deliverables that business stakeholders can review as if they were a real program.

Core principles

  • No Backend: All APIs go through a Mock interceptor (keep calling useApi())
  • Generation method: Reference the test-data guide code as the base skeleton, then adapt it specifically for Mock
  • Component usage: Use kebab-case (e.g. <u-button>, <u-modal>, <my-component>)
  • Completion criteria: vue-tsc + lint + build all pass
  • Preparation for production transition: Keep API signatures intact; real-server integration possible by replacing only the Mock
  • Repository separation (decided 2026-04-27): Accumulated not in this project but in a separate ui-proto repository의 src/modules-task/{년월}/{태스크폴더}/accumulated in
  • Spec source material: Vue screens + Mock data + overview explanation pages become the input for the follow-up peach-gen-specbecomes input for
  • First-pass completeness support: Leave screen lists, key actions, and completion/error states so that peach-gen-speccan create a confirmed Spec
  • Planning concretization first: When a planner concretizes directly without a Spec, prioritize the solo/conversational flow, and the AI team does not arbitrarily amplify requirements

Role boundaries

Skill Responsibility
peach-team-ui-proto Mock-based planning-review screens + task metadata + overview + screen/action/state generation and verification
peach-team-dev Implement this project's code based on the prepared DB/Spec/ui-proto
peach-team-e2e After main development is complete, verify the actual browser flow matches the plan
peach-gen-ui Standalone generation of UI based on real API/Store

ui-proto is not the main development code. Modifying production code, real API integration, final E2E judgment, and designing complete E2E scenarios are not handled by this skill.

ui-proto repository structure

This skill runs in a separate ui-proto repository(e.g. peach-ui-proto-backoffice). If it is not the current project, confirm the repository location with the user.

peach-ui-proto-{도메인}/                       ← 별도 저장소
└── src/modules-task/
    └── {년월}/                                예: 2604
        └── {년월일-이니셜-태스크명}/          예: 260427-{이니셜}-goods
            ├── _task-meta.ts                  메타 (날짜/담당자/제목/modules)
            ├── _routes.ts                     overview + 서브모듈 라우트
            ├── layout/
            │   ├── task-layout.vue            서브모듈용 (배너+사이드바)
            │   └── task-overview-layout.vue   기획서용 (배너+전체)
            ├── overview/pages/overview.vue    기획서 화면
            └── {서브모듈}/                    실제 UI 화면
                ├── pages/
                ├── store/
                └── type/

When creating a new task, it is faster to copy an existing task folder (e.g. 2603/260320-{이니셜}-board/) wholesale and then modify only the metadata, routes, and submodule names. For details, see the ui-proto repository's AGENTS.md reference.

Conditional team formation (decided 2026-04-27, direction reinforced 2026-05-04)

This skill automatically branches into team mode/solo modedepending on request complexity. However, the purpose of team mode is not autonomous development but improving the quality of the criteria for subsequent development/verification.

Mode decision tree

화면/흐름 요구가 충분히 주어짐?
       │
       ├─ Yes + 복잡 화면 → 자동 팀 모드
       │       (proto-ui-dev + proto-ui-qa)
       │       목적: 화면/액션/상태/overview 품질 보강
       │       랄프루프: 5회(단순) / 10회(복잡)
       │
       ├─ Yes + 단순 화면 → 단독 모드
       │       기획자가 직접 빠르게 구체화하는 경우
       │       랄프루프: 5회 (단독 검증만)
       │
       └─ No  → 요구사항 구체화 요청
               team=Y만 있고 화면/흐름 요구가 없으면 진행하지 않음

team=Yteam mode can be forced with , but screen/flow requirements are essential. team=N Solo mode can be forced with the argument.

Team mode (when complex screen/flow requirements are input)

Input type

/peach-team-ui-proto [모듈명] "화면/흐름 요구사항" [옵션]
/peach-team-ui-proto [모듈명] req=<요구사항 파일 경로> [옵션]
/peach-team-ui-proto [모듈명] spec=<Spec 파일 경로> [옵션]

spec=is an optional input used when an already-organized requirements document exists. ui-proto's standard responsibility is to produce the input artifact for the follow-up peach-gen-spec, so Spec is not required as mandatory.

Team composition

Role Responsibility
proto-ui-dev Screen implementation based on screen/flow requirements (create modules-task folder)
proto-ui-qa Visual/UX verification + verification of suitability as follow-up gen-spec input (independent worktree, read-only)

proto-ui-qa verification items

  1. Were all of the user's screen/flow requirements reflected
  2. Compliance with NuxtUI v4 component usage rules
  3. This project (peach-{도메인}) consistency with component patterns
  4. Avoidance of AI Slop patterns (gradients, purple colors, etc.)
  5. Compliance with modules-task folder structure rules (_task-meta.ts, _routes.ts, layout separation, etc.)
  6. Compliance with route integration rules (_task.routes.tsadded to taskDetailRoutes)
  7. If DESIGN.md exists, compliance with design system rules (colors, component naming, typography)
  8. Are the screen list and main features explained in the overview
  9. Are the completion and error states of main actions (search/save/approve/reject/upload/download, etc.) expressed on the screen
  10. Follow-up peach-gen-specAre there sufficient clues about the screen transition flow so that E2E scenario candidates can be organized
  11. Follow-up peach-gen-specAre screen/Store/API expectations sufficiently revealed so that a development Spec can be created

Ralph loop 5/10 judgment criteria

Mode Max iterations
Simple screen (list only, single modal) 5회
Complex screen (multi-tab, multiple modals, charts, multi-step forms) 10회

When the upper limit is reached, report to the user and stop.

Solo mode (simple screen or team=N)

When the planner concretizes directly. Performs only self-verification (no separate QA agent). Ralph loop 5 times (attempt to pass vue-tsc + lint + build).

Auto-generate module name/task folder name

When a requirements document or natural language input is given:

  • From the requirements body and user input, extract planner, date, title candidates
  • Task folder name: {YYMMDD}-{planner}-{영문슬러그} format (Korean prohibited)
  • With the confirmed meta, _task-meta.tsis generated. Afterwards, peach-gen-spec proto=<경로>reads this meta and the screen files to generate a development Spec
  • Show auto-extraction results to the user and get confirmation

When given as natural language input:

  • AI proposes 1~3 candidates → user selects

Prototype characteristics

  • Without Backend, using Mock interceptor useApi() Handles the call.
  • Mock data is mock/separated into, and the signature is maintained when switching to the real API.
  • For visual quality and AI Slop prevention details, follow peach-gen-ui/references/core/visual-guide.md. Shared UI patterns follow peach-gen-ui가 SoT다.

First-pass completeness deliverable

The overview and screen files must reveal the following information. This information is not a complete E2E scenario, but peach-gen-specthese are the screen/action/state criteria for creating the development Spec.

## UI Proto 검증 매핑

### 화면 목록
| 화면 | 경로 | 목적 |
|------|------|------|

### 주요 액션
| 액션 | 시작 화면 | 결과 화면/상태 |
|------|-----------|----------------|

### 완료/오류 상태
| 상태 | 표시 위치 | 메시지/피드백 |
|------|-----------|---------------|

### 결정 필요 항목
| 항목 | 모호한 이유 | 후속 처리 |
|------|------------|-----------|

Writing rules:

  • Items whose actual data accuracy cannot be verified due to Mock data limitations are left as items requiring a decision.
  • If the permission/state/error rules are not finalized by the screen alone, peach-gen-specrecord it so the user can confirm it in.
  • The detailed selectors, fixtures, and suite combinations of the scenario are left as the responsibility of peach-team-e2e .

Absolutely required patterns (common to all UI patterns)

Warning: The patterns below must be applied in all UI patterns. If omitted, search, paging, and URL state management will not work.

Required checklist

# Pattern Application location
1 <form @submit.prevent="listAction"> list-search.vue
2 @change="listAction" (select, radio) list-search.vue, list-table.vue
3 @update:modelValue="listAction" (date) list-search.vue
4 @update:page="listMovePage" (pagination) list-table.vue
5 watch pattern (route → listParams) list-search.vue
6 watch pattern (route → getList) list-table.vue
7 listAction(), resetAction(), listMovePage() Each component

Detailed code and prohibited patterns: peach-gen-ui/references/core/common-patterns.md reference (required, shared SoT)

Input method

/peach-team-ui-proto [모듈명] [옵션]

Option

Option Default value Description
excel N Excel download/upload feature (Mock)
file N File upload feature (Mock)
req (none) Screen/flow requirements file path. If complex, team mode auto-entry
spec (none) Path of an already-written Spec or requirements document. If complex, team mode auto-entry
team (auto) team=Yforce team mode with, team=Nforce-disable team mode with

Example

# 단독 모드 (기획자 직접 작업)
/peach-team-ui-proto notice-board
/peach-team-ui-proto member-manage excel=Y
/peach-team-ui-proto product file=Y excel=Y

# 복잡 화면 팀 모드
/peach-team-ui-proto product team=Y "상품 목록, 검색, 등록, 수정, 삭제, 엑셀 다운로드, 상태별 승인 흐름이 필요함"
/peach-team-ui-proto product req=docs/prd/product.md

# 팀 모드 강제 비활성화
/peach-team-ui-proto product team=N

UI patterns are selected interactively after execution (Step 1) For complex screens, after request analysis, automatically switch to proto-ui-dev + proto-ui-qa team mode.

Workflow

Step 0. Check design system

cat DESIGN.md 2>/dev/null | head -200
  • If present: Inject component rules, colors, and typography into the context and reflect them in subsequent steps
  • If not present: Output the warning below and continue
⚠️ DESIGN.md 없음 — 디자인 시스템 문서가 없습니다. 작성을 권장합니다.
   참고: peach-harness/templates/DESIGN-template.md (또는 /peach-gen-design)

Step 1: Required UI pattern selection

This step cannot be skipped! Always ask the planner about the UI pattern and proceed only after receiving a selection. You must not start code generation without a selection.

To the planner, must ask the question below and receive a selection:

## UI 패턴 선택 (필수)

어떤 UI 패턴을 사용할까요?

### 기본 UI 패턴 (test-data 가이드 있음)
| 패턴 | 설명 | 사용 시기 |
|------|------|----------|
| **crud** | 목록 + 모달 | 일반적인 CRUD, 입력 10개 미만 |
| page | 목록 + 별도 페이지 | 입력 10개 이상, URL 공유 필요 |
| two-depth | 좌우 분할 | 목록/상세 동시 표시 |
| infinite-scroll | 무한 스크롤 | 피드형, 모바일 최적화 |
| select-list | 선택 모달 | 다른 화면에서 데이터 참조 |
| show-more | 더보기 버튼 | 적은 데이터, 단계별 로드 |
| batch-process | 일괄 처리 | 순차 작업 진행바 |

### 추가 옵션 (기본 패턴과 조합)
| 옵션 | 설명 |
|------|------|
| excel | 엑셀 다운로드/업로드 (Mock 로컬 생성) |
| file | 파일 업로드 (Mock UUID 반환) |

### 고급 UI 패턴 (MCP 활용, test-data 없음)
| 패턴 | 설명 |
|------|------|
| adv-search | 복합 검색 (5개 이상 조건) |
| calendar | 달력 UI |
| kanban | 칸반 보드 |
| mega-form | 대량 입력 폼 (50개+) |
| tab-list | 탭 내 리스트 |

선택해주세요 (예: crud, excel=Y)

Guide code path:

  • crud: src/modules/test-data/pages/crud/if present, reference it first
  • Other patterns: src/modules/test-data/pages/[패턴명]/ or the closest existing src/modules-task/{년월}/{태스크폴더}/

Step 2: Check test-data guide code + detect ui-proto repository

# test-data 모듈 존재 여부 확인
ls src/modules/test-data/ 2>/dev/null

# _common 래퍼 컴포넌트 존재 여부 확인
ls src/modules/_common/components/ 2>/dev/null

# 빌드 도구 감지
ls package.json && head -20 package.json
ls bun.lockb 2>/dev/null && echo "BUILD_TOOL=bun"

# 공유 UI 패턴 references 경로 감지 (SoT: peach-gen-ui)
SHARED_UI_REFS=$(find ~/.claude ~/.agents ~/.codex "${CODEX_HOME:-$HOME/.codex}/skills" -path "*/peach-gen-ui/references" -type d 2>/dev/null | head -1)

# proto 자체 references 경로 (Mock 특화 패턴)
PROTO_REFS=$(find ~/.claude ~/.agents ~/.codex "${CODEX_HOME:-$HOME/.codex}/skills" -path "*/peach-team-ui-proto/references" -type d 2>/dev/null | head -1)
  • test-data present → generate based on guide code
  • no test-data → generate based on references documents
  • no SHARED_UI_REFS → there is no shared UI pattern SoT, so report to the user and stop
  • no PROTO_REFS → proto-specific Mock patterns cannot be read, so report to the user and stop

Separation of shared/proto-specific patterns

peach-team-ui-protodoes not hold a copy of the UI pattern catalog. For shareable UI patterns, read peach-gen-ui/references, and keep only the Mock differences needed only by proto in its own references.

Classification Location Content
Shared UI SoT ${SHARED_UI_REFS} common-patterns, ui-patterns, visual-guide, Store/Type skeleton, basic/advanced UI patterns, validator
proto-specific ${PROTO_REFS} mock-service, mock-store, Mock excel/file option, completion/validation, proto team agent

In team mode, proto-ui-dev와 proto-ui-qa pass the value of SHARED_UI_REFS, PROTO_REFS together with the work instruction.

Build tool basis

File existence Build tool Validation command
bun.lockb bun bunx vue-tsc --noEmit && bun run lint:fix && bun run build

Prefer _common wrapper (conditional)

In the target project, _common/components/ if the directory exists, use wrapper components first instead of using NuxtUI directly.

NuxtUI _common wrapper (preferred if present)
<UInput> <p-input-box>
<USelect> <p-nuxt-select>
<UFormField> <p-form-field>
<UFileInput> <p-file-upload>
  • _common/components/ if absent → use NuxtUI directly (keep existing approach)

Step 2.5: Domain analysis (Analyze)

Compare and analyze the test-data UI and the requested domain:

  1. UI complexity assessment: number of fields, search conditions, table column composition
  2. Mock data design: devise realistic sample data suited to the domain
  3. Adaptation decision:
    • Must Follow → as is (script setup, required patterns, no AI Slop)
    • May Adapt → tailored to domain (table columns, search form, modal form composition)
  4. Structure suggestion (May Suggest): If the analysis shows a structure other than the guide code is more suitable, propose it to the user:
    • Component separation (e.g., split a complex form into per-step components)
    • Page composition change (e.g., list within tabs, separate detail page)
    • Apply after user confirmation. Do not violate Must Follow.

Step 3: Mock service + Store + code generation

Reference the selected pattern's guide code as the base skeleton, then adapt it to the domain:

3-1. Mock data generation (required)

${PROTO_REFS}/core/mock-service-pattern.md reference

mock/[모듈명].mock.ts 생성:
- 도메인 맞춤 샘플 데이터 (5~10건)
- 동적 데이터 생성 함수
- API 시그니처 유지 (프로덕션 전환 대비)

3-2. Store generation (via Mock useApi())

${PROTO_REFS}/core/mock-store-pattern.md reference

store/[모듈명].store.ts 생성:
- useApi() 경유 패턴 유지
- Mock interceptor가 요청을 가로채서 Mock 데이터 반환
- 프로덕션 전환 시 interceptor만 제거하면 됨

3-3. Page generation

Pattern Guide code path Reference documents (peach-gen-ui SoT)
crud test-data/pages/crud/ ${SHARED_UI_REFS}/basic/page-pattern.md + ${SHARED_UI_REFS}/basic/modal-pattern.md
page test-data/pages/crud/ + detail-page.vue ${SHARED_UI_REFS}/basic/page-pattern.md
two-depth test-data/pages/two-depth/ ${SHARED_UI_REFS}/basic/two-depth-pattern.md
infinite-scroll test-data/pages/infinite-scroll-list/ ${SHARED_UI_REFS}/basic/infinite-scroll-pattern.md
select-list test-data/pages/select-list/ ${SHARED_UI_REFS}/basic/select-list-pattern.md
batch-process test-data/modals/list-table-progress.modal.vue ${SHARED_UI_REFS}/basic/batch-process-pattern.md

Required standard patterns: ${SHARED_UI_REFS}/core/common-patterns.md Reference

  • Selectbox pattern (all options value='')
  • Router sync pattern (listAction, resetAction, watch)
  • Date search pattern (initial values: 5 years ago ~ today)

Step 4: Verification & completion

# ui-proto 저장소 루트 기준
bunx vue-tsc --noEmit  # 타입 체크
bun run lint:fix       # 린트
bun run build          # 빌드

On error: analyze cause → fix code → verify again → repeat until it passes

Generated file structure

src/modules-task/{년월}/{태스크폴더}/ Under _task-meta.ts, _routes.ts, layout/, overview/, {서브모듈}/pages, {서브모듈}/store, {서브모듈}/type, {서브모듈}/modalsis generated. For the subsequent peach-gen-spec proto=<경로>, pass this task folder path.

Bounded Autonomy (autonomous adaptation rules)

Must Follow (absolute compliance)

  • <script setup> Required
  • NuxtUI components first, no AI Slop
  • Required patterns: listAction, resetAction, listMovePage, watch pattern
  • @submit.prevent="listAction", @change="listAction" pattern
  • Module boundary: _common만 import
  • Mock data is separated into the mock/ directory
  • Maintain the pattern of going through useApi() (in preparation for production transition)

May Adapt (supplement after analysis)

  • Table column composition (tailored to domain fields)
  • Search form composition (layout according to number of fields)
  • Modal/page form composition (grouping input fields)
  • Mock data composition (domain-specific samples)
  • UI interaction flow (domain-specific UX)

May Suggest (confirm with user after suggesting)

  • Component separation (e.g., splitting a complex form into step-by-step components)
  • Page composition changes (e.g., list within a tab, separating detail pages)
  • Suggest UI pattern changes (e.g., page is more suitable than crud)

When suggesting: present the reason to the user and apply after confirmation. Do not infringe on Must Follow.

Adapt conditions

When supplementing, always: (1) explain the reason (2) do not infringe on Must Follow (3) pass vue-tsc + lint + build

Completion conditions

  • UI pattern selection complete
  • Mock data, Store, page/modal component creation complete
  • vue-tsc, lint, build passes
  • Team mode requires proto-ui-qa APPROVED or user-approved CONDITIONAL

Do not declare completion without a successful build.

Guidance after completion

Report created/modified files, vue-tsc/lint/build results, browser verification path, and the scope of Mock removal for production transition.

Conditional reference guide (token saving)

Important: Read only the reference files for the selected pattern! Do not load all references at once.

Required references (must read - do not omit!)

Warning: The files below must be read first regardless of which pattern is selected! If you do not read these files, search, paging, and URL state management patterns will be missing.

  • ${SHARED_UI_REFS}/core/common-patterns.md - URL Watch pattern, Selectbox, Router sync, Date search, modal open pattern
  • ${PROTO_REFS}/core/mock-service-pattern.md - Mock data definition, dynamic generation, maintaining API signatures
  • ${PROTO_REFS}/core/mock-store-pattern.md - Mock useApi() via Store pattern

Reference mapping by pattern

Selected pattern Files to read
crud Shared: basic/page-pattern.md + basic/modal-pattern.md
page Shared: basic/page-pattern.md
two-depth Shared: basic/two-depth-pattern.md
infinite-scroll Shared: basic/infinite-scroll-pattern.md
select-list Shared: basic/select-list-pattern.md
batch-process Shared: basic/batch-process-pattern.md
adv-search Shared: advanced/adv-search-pattern.md
calendar Shared: advanced/calendar-pattern.md
kanban Shared: advanced/kanban-pattern.md
mega-form Shared: advanced/mega-form-pattern.md
tab-list Shared: advanced/tab-list-pattern.md

Additional references by option

Option Files to read
excel=Y proto-specific: options/excel-pattern.md
file=Y proto-specific: options/file-upload-pattern.md
validator required Shared: options/validator-pattern.md

Conditional references

Situation Files to read
loading state required Shared: core/loading-state-pattern.md
error handling required Shared: core/error-handling-pattern.md

Reference

  • Guide code (preferred): src/modules/test-data/ or existing src/modules-task/{년월}/{태스크폴더}/
  • Mock data: src/modules-task/{년월}/{태스크폴더}/{서브모듈}/mock/
  • Store: src/modules-task/{년월}/{태스크폴더}/{서브모듈}/store/

Reference the test-data guide code as the baseline skeleton, but adapt it within the Bounded Autonomy scope to suit Mock specialization + domain characteristics