메뉴
Define UI design specs, route contracts, visual states, accessibility expectations, and UI/API synchronization before frontend implementation. Use for new screens, redesigns, visual QA, or UI contract updates.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Automatically synchronize documentation with code changes across all project phases. Detects file changes, categorizes update types, auto-generates API docs, changelog entries, implementation handoffs, and validates cross-reference integrity. Use after any phase implementation.
Initialize and operate a project planning harness for Codex. Use this skill when the user types /init, asks to create a new project, add a feature, fix a bug, plan work, generate tests first, update docs, track phases, review changes, audit a repository, or manage architecture decisions.
Create premium frontend web designs and usable first-screen experiences for new websites, web apps, dashboards, tools, and landing pages. Use when Codex is asked to design or build a new frontend UI, create a fresh page or app experience, choose a visual direction for a new product surface, or turn a product brief into implementation-ready React, Next.js, Tailwind, CSS, or HTML.
Create decision-complete plans for Codex harness work, including tests, fixtures, contracts, memory updates, verification, and recovery. Use for new features, refactors, bug fixes, audits, or multi-phase autonomous work.
Prepare Codex harness package releases with version checks, package dry-runs, npm publish readiness, release notes, verification evidence, and rollback notes. Use before publishing or tagging releases.
Auto-enforce research-first pattern - automatically research documentation, best practices, and GitHub before any important decision. Research output feeds directly into planning. Triggered automatically for features, bugs, architecture changes, and spec updates.
| name | genesis-design-spec |
| description | Define UI design specs, route contracts, visual states, accessibility expectations, and UI/API synchronization before frontend implementation. Use for new screens, redesigns, visual QA, or UI contract updates. |
Make UI behavior and visual expectations contract-first before implementation.
Use before creating or changing screens, dashboards, forms, flows, or visual states.
Do not use for backend-only changes with no UI effect.
UI route, audience, state list, API dependencies, fixtures, and visual references if available.
UI contract, a generated visual mockup image representing the screen layout (saved as mockup.png in the active feature/bug directory), Playwright fixture, acceptance states, and visual regression expectations.
Create load, interaction, validation, API sync, and visual regression tests where applicable.
Create UI fixtures for default, loading, empty, error, and success states.
Update contracts/ui/ for changed routes or states.
Update .codebase/UI_ROUTES.md and frontend summary.
Use state tables and route maps instead of long visual prose.
The UI can be implemented and tested without guessing states or API behavior. A high-fidelity visual mockup mockup.png must be created using the generate_image tool and saved in the active task directory as the visual contract.
Designing only the happy path, skipping empty/error states, and omitting API synchronization.
If implementation diverges from spec, update the failing UI test first, then repair contract or UI.
