apply-turbo-handoffs
Audit the turbo skill lessons that /self-improve writes into this repo's .turbo/handoff/ from other projects, apply the ones the…
@tobihagemannInstall SkillDevelopment
Skill
/user-experience
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does.
Claude Code
$ npx -y skills add tobihagemann/turbo --skill user-experience --agent claude-code
Codex
$ npx skills add tobihagemann/turbo --skill user-experience -a codex -y
Cursor
$ npx skills add tobihagemann/turbo --skill user-experience -a cursor -y
Gemini CLI
$ npx skills add tobihagemann/turbo --skill user-experience -a gemini-cli -y
GitHub Copilot
$ npx skills add tobihagemann/turbo --skill user-experience -a github-copilot -y
OpenCode
$ npx skills add tobihagemann/turbo --skill user-experience -a opencode -y
Windsurf
$ npx skills add tobihagemann/turbo --skill user-experience -a windsurf -y
SKILL.md
user-experience.SKILL.mdname: user-experience
description: "Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path holds together. Use when scoping, planning, or assessing a change to what users see or do."
User Experience
Apply this lens to any user-facing change, both before committing to an approach and when judging a built experience. Keep the work anchored to what the user is trying to accomplish.
Lead with the user's goal rather than a list of surface fixes. A pile of small corrections ("relabel this", "move that") is a sign the underlying flow was never examined. Start from intent and work down to detail.
**Scope:** this lens covers whether a change serves the user and whether the path through it is coherent. Visual and aesthetic craft — typography, color, spacing, motion polish — is a separate concern and stays out of scope here.
Understanding
Establish what the user actually needs before shaping a solution.
- Name the user and the job they came to do.
- Separate the stated request from the goal behind it, and solve the goal.
- Ground claims about user needs in evidence (observed behavior, recurring reports, real usage). Flag a need that is assumed rather than known.
Bridging
Translate the need into the right solution rather than the first one that comes to mind.
- Check that the solution addresses the goal, not just the visible symptom.
- Weigh whether the change adds a step, a screen, or a concept the user must learn, and whether that cost is justified.
- Check whether an indicator or notice the change adds repeats what an existing surface already tells the user, and prefer relying on that surface.
- Prefer the path that removes work for the user over one that adds configuration or choices.
- Watch for solving a builder's convenience at the user's expense.
Flowing
Trace the path the user takes from end to end.
- Follow the full journey: how the user arrives, the change itself, and what happens after.
- Walk the unhappy paths in the running software when it can be run: empty states, seeded defaults, errors, interruptions, first-time versus returning use. Flag any of these judged from source alone.
- Confirm the user always knows what just happened and what to do next.
- Surface friction: redundant steps, dead ends, and points where the user must hold state in their head.
Read more
name: user-experience description: "Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path holds together. Use when scoping, planning, or assessing a change to what users see or do."
User Experience
Apply this lens to any user-facing change, both before committing to an approach and when judging a built experience. Keep the work anchored to what the user is trying to accomplish.
Lead with the user's goal rather than a list of surface fixes. A pile of small corrections ("relabel this", "move that") is a sign the underlying flow was never examined. Start from intent and work down to detail.
**Scope:** this lens covers whether a change serves the user and whether the path through it is coherent. Visual and aesthetic craft — typography, color, spacing, motion polish — is a separate concern and stays out of scope here.
Understanding
Establish what the user actually needs before shaping a solution.
- Name the user and the job they came to do.
- Separate the stated request from the goal behind it, and solve the goal.
- Ground claims about user needs in evidence (observed behavior, recurring reports, real usage). Flag a need that is assumed rather than known.
Bridging
Translate the need into the right solution rather than the first one that comes to mind.
- Check that the solution addresses the goal, not just the visible symptom.
- Weigh whether the change adds a step, a screen, or a concept the user must learn, and whether that cost is justified.
- Check whether an indicator or notice the change adds repeats what an existing surface already tells the user, and prefer relying on that surface.
- Prefer the path that removes work for the user over one that adds configuration or choices.
- Watch for solving a builder's convenience at the user's expense.
Flowing
Trace the path the user takes from end to end.
- Follow the full journey: how the user arrives, the change itself, and what happens after.
- Walk the unhappy paths in the running software when it can be run: empty states, seeded defaults, errors, interruptions, first-time versus returning use. Flag any of these judged from source alone.
- Confirm the user always knows what just happened and what to do next.
- Surface friction: redundant steps, dead ends, and points where the user must hold state in their head.
Ships withturbo
Reusable workflows for planning, building, reviewing, and shipping with Claude Code and Codex.
41775 skills
Stars on GitHub
Momentum
- stars in total
- 417
Other skills on turbo.
@tobihagemannInstall Skillapply-findings
Apply findings by making the suggested code changes. Applies accepted verdicts, escalates ambiguous findings to the user, and…
@tobihagemannInstall Skillassess-technical-debt
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, architecture rot,…
@tobihagemannInstall Skillchangelog-rules
Shared changelog conventions and formatting rules referenced by /create-changelog and /update-changelog. Not typically invoked…
@tobihagemannInstall Skillcode-style
Enforce existence, reuse, mirror, and symmetry principles to keep new code minimal and consistent with surrounding code. Use when…
@tobihagemannInstall Skillcodex-exec
Run autonomous task execution using the codex CLI. Use when the user asks to \"codex exec\", \"run codex exec\", \"execute a task…
@tobihagemannInstall SkillMore skills from other plugins.
Auto-invoked
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
@obraInstall Skillask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
@mattpocockInstall SkillAuto-invoked
Questions about user-experience.
- Which coding agents can use user-experience?
- user-experience installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.