원클릭으로 Manus에서 모든 스킬 실행

ux-onboarding

스타3

포크0

업데이트2026년 6월 23일 10:30

This skill should be used when someone wants to get familiar with an existing project's UX/design choices and patterns — e.g. "walk me through how this app does UX", "onboard me onto the design system", "explain this project's UI patterns", "I'm new to this codebase, show me the design layer", or runs /ux-onboarding. It builds a working mental model by surveying the design layer, teaching it part by part (explaining, sending the user to read the real code, and checking comprehension with questions), then having the user reimplement a small recent UX change picked from history. Familiarization — not scaffolding (ux-foundations) or scoring (ux-audit).

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

TimboGP

TimboGP/timbogp-marketplace

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

UX Onboarding

Build a working mental model of how this project does UX — its design tokens, component patterns, accessibility conventions, interaction-feedback states, and copy voice — by being walked through the real code, not by reading a summary. This is familiarization, not scaffolding (the ux-foundations skill / /ux-bootstrap) or scoring (the ux-audit skill / /ux-audit). Lean on the ux-foundations, design-tokens, accessible-components, interaction-feedback, and ux-audit skills for what "good" looks like in each area.

When to use

The user wants to understand an existing UX/design layer they did not build — joining a new repo, picking up an unfamiliar frontend, or learning a team's conventions. Phrases like "walk me through this app's UX", "onboard me onto the design system", or "explain how this project handles components/tokens/a11y". If they instead want to create a baseline, use ux-foundations; to score one, use ux-audit.

Optional focus: a path or an area (e.g. "tokens", "the dialog component"). If none is given, cover the design layer end to end.

Procedure

Detect the stack and survey the design layer. Read ../ux-foundations/references/stack-detection.md and run it; report framework, styling approach, and language in one line. Then build a short map: where tokens/theme live, the component library and its primitives, styling conventions, the accessibility patterns in use, the interaction-feedback patterns (loading / empty / error / success, toasts), and copy/voice conventions. Skim recent history (git log, recently merged PRs) for changes to use in step 4.
Confirm the path. List the parts you'll walk through — dependencies first, usually tokens → primitives → composed components → app screens — and confirm scope. Honor any focus the user gave.
Walk it part by part — one part at a time, never a wall of text. For each:
- Explain how this project handles it and the pattern/convention it follows.
- Send the user to the code — name concrete files/components to open and read (e.g. "open tokens.css and Button.tsx"), rather than pasting them.
- Ask questions to answer — a few comprehension/prediction questions ("which token drives the focus-ring color?", "what makes this dialog's focus trap correct?"), then check the answers, correct misconceptions, and push deeper before moving on.
Reimplement a recent change. From recent history, pick a few smaller UX/design changes — a new component variant, a token change, an added interaction state, a copy fix — each small enough to redo in one sitting and ideally in a part already walked. Present them as an interactive choice; the user picks one (or asks for different candidates). Stub out or revert it in a scratch copy (without showing the original diff), state the change's intent and acceptance criteria, and have the user reimplement it. Then review against what the project actually shipped — convention fit, accessibility, and which approach is better and why.
Wrap up. Summarize the parts covered and the user's comprehension, the reimplementation outcome, and suggest the ux-audit skill (to score what they now understand) or a focused component review as next steps.

Notes

Read-only by default — do not modify the project's real files; the user's reimplementation happens in a scratch copy.
Keep each part short and interactive: the user reading the real code and answering is the point.
In Claude Code this skill backs the /ux-onboarding command; it also triggers from natural language on both Claude Code and Codex.

이 저장소의 다른 Skills

같은 저장소

adjust-level

TimboGP/timbogp-marketplace

Adjust the difficulty level of a learning sub-project's curriculum — simplify a too-advanced curriculum into a gentler on-ramp, or deepen a too-introductory one into something with real teeth. Use whenever the user signals the curriculum's level doesn't match their starting point — phrases like "this paper is too hard, can we build up to it?", "simplify the curriculum", "make it easier", "go more advanced", "I want a more rigorous version", "this is too basic, push deeper", "I need an intro version of this", or "create a simpler/harder curriculum from this material". The skill is allowed to pull in external materials and training knowledge to fill the gap between the source's natural level and the target level, but every external addition is explicitly labeled — the user always knows what came from their own source materials and what came from elsewhere.

2026-07-073

bootstrap

TimboGP/timbogp-marketplace

Scaffold a new learning sub-project under the agentic-study-environment harness — create the directory, generate per-project AGENTS.md, CLAUDE.md, and PROGRESS.md from templates, and register the new project in the .studyenv/PROGRESS.md cross-project tracker. Use this skill whenever the user wants to start studying a new topic, paper, book, language, or domain with the tutor harness — phrases like "bootstrap a new project to learn X", "start a new sub-project for Y", "set up a learning project on Z", or "create a sub-project to study W" should all trigger this skill. Do not use for general project scaffolding outside the agentic-study-environment harness.

2026-07-073

help

TimboGP/timbogp-marketplace

Explain the agentic-study-environment plugin — what it does, the lifecycle skills it ships, the domain overlays, the session types, and the key conventions — or a specific one of those if the user names it. Use this skill whenever the user asks for help with the study harness itself rather than asking to study something: phrases like "help with agentic-study-environment", "what can the study harness do", "how does this plugin work", "list the study skills", "how do I use set-curriculum", "what domains are there", "explain session types", or the /study-help command. With no topic, give the full overview; with a named skill, overlay, session type, or convention, explain just that. Do NOT use this to bootstrap, set a curriculum, or run a session — those are the lifecycle skills.

2026-07-073

onboard-session

TimboGP/timbogp-marketplace

Begin a bracketed onboarding session over an existing artifact you didn't author — a codebase, a document corpus, a body of papers — inside a agentic-study-environment sub-project. The agent surveys the artifact, walks it part by part with comprehension checks, then has the user reproduce a recent change from its history. Use whenever the user signals they want to get up to speed on something someone else made — phrases like "onboard me on this codebase", "walk me through this repo", "help me get up to speed on X", "I just joined this project", "drop me into this codebase", or "get familiar with this corpus" should trigger this skill. `onboarding` is the fourth core session type; unlike `theory`/`practice`/`role-play` it has its own dedicated entry point rather than being proposed inside `start-session`. A session ends with the `stop-session` skill.

2026-07-073

set-curriculum

TimboGP/timbogp-marketplace

Build or update the teaching curriculum for a learning sub-project from its source materials. Use whenever the user wants to plan, structure, or refresh the learning path for a sub-project — phrases like "set curriculum for X", "update the curriculum", "plan the teaching path", "build a curriculum from these materials", or general intent to organize source material into an ordered teaching plan. This skill reads the sub-project's source materials and writes ai-agent-materials/curriculum.md. It does not start a session and does not update PROGRESS.md.

2026-07-073

start-session

TimboGP/timbogp-marketplace

Begin a bracketed learning session inside a agentic-study-environment sub-project — pick a topic, propose theory vs. practice (or an overlay-specific type such as simulation or defense), and conduct it per the sub-project's domain overlay. Use whenever the user signals they want to actively study, work an exercise, role-play a clinical case, rehearse a research defense, or review theory inside a sub-project — phrases like "start session", "let's work on X", "begin a practice session", "ok let's study Y", or "I want to do an exercise on Z" should trigger this skill. A session is the harness's unit of work and ends with the stop-session skill.

2026-07-073

name	ux-onboarding
description	This skill should be used when someone wants to get familiar with an existing project's UX/design choices and patterns — e.g. "walk me through how this app does UX", "onboard me onto the design system", "explain this project's UI patterns", "I'm new to this codebase, show me the design layer", or runs /ux-onboarding. It builds a working mental model by surveying the design layer, teaching it part by part (explaining, sending the user to read the real code, and checking comprehension with questions), then having the user reimplement a small recent UX change picked from history. Familiarization — not scaffolding (ux-foundations) or scoring (ux-audit).
version	0.1.0

UX Onboarding

When to use

Optional focus: a path or an area (e.g. "tokens", "the dialog component"). If none is given, cover the design layer end to end.

Procedure

Detect the stack and survey the design layer. Read ../ux-foundations/references/stack-detection.md and run it; report framework, styling approach, and language in one line. Then build a short map: where tokens/theme live, the component library and its primitives, styling conventions, the accessibility patterns in use, the interaction-feedback patterns (loading / empty / error / success, toasts), and copy/voice conventions. Skim recent history (git log, recently merged PRs) for changes to use in step 4.
Confirm the path. List the parts you'll walk through — dependencies first, usually tokens → primitives → composed components → app screens — and confirm scope. Honor any focus the user gave.
Walk it part by part — one part at a time, never a wall of text. For each:
- Explain how this project handles it and the pattern/convention it follows.
- Send the user to the code — name concrete files/components to open and read (e.g. "open tokens.css and Button.tsx"), rather than pasting them.
- Ask questions to answer — a few comprehension/prediction questions ("which token drives the focus-ring color?", "what makes this dialog's focus trap correct?"), then check the answers, correct misconceptions, and push deeper before moving on.
Reimplement a recent change. From recent history, pick a few smaller UX/design changes — a new component variant, a token change, an added interaction state, a copy fix — each small enough to redo in one sitting and ideally in a part already walked. Present them as an interactive choice; the user picks one (or asks for different candidates). Stub out or revert it in a scratch copy (without showing the original diff), state the change's intent and acceptance criteria, and have the user reimplement it. Then review against what the project actually shipped — convention fit, accessibility, and which approach is better and why.
Wrap up. Summarize the parts covered and the user's comprehension, the reimplementation outcome, and suggest the ux-audit skill (to score what they now understand) or a focused component review as next steps.

Notes

Read-only by default — do not modify the project's real files; the user's reimplementation happens in a scratch copy.
Keep each part short and interactive: the user reading the real code and answering is the point.
In Claude Code this skill backs the /ux-onboarding command; it also triggers from natural language on both Claude Code and Codex.