How to use the Team UI Pipeline agent skill (team-ui)

What the team-ui skill makes the agent do

Team UI is a process guide for the agent. When you invoke it with a description of a screen or UI feature, the agent coordinates a simulated UI team and works through phases. The UX designer drafts user flows and specs, the UI programmer plans the implementation, the art director checks visual consistency, and the accessibility reviewer audits the result.

The skill does not produce code on its own. Its job is to structure the work, and it writes standard spec templates along the way, such as ux-spec.md for screens and flows, hud-design.md for HUDs, interaction-pattern-library.md for reusable patterns, and accessibility-requirements.md for the committed accessibility tier.

• Phases with decision points where you choose from options the agent proposes
• Spec templates written as the pipeline moves forward
• Review depth controlled by the --review option (full, lean or solo)

Install the team-ui skill from a ZIP file or the Claude apps

Download the ZIP for the skill from the page you are reading. Unzip it into one of two locations. For a personal install, use ~/.claude/skills/. For a single project, use the .claude/skills/ folder inside that project.

If you use the Claude apps instead, upload the skill under Settings, then Capabilities, then Skills. Either way, the skill's files must be present in a folder named team-ui so the agent can find its SKILL.md file.

The skill is a single SKILL.md file. It depends on referenced studio files from the same repository, so installing the skill alone is not enough for the full pipeline (see the requirements section).

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ inside your project
• Claude apps: Settings, Capabilities, Skills, then upload

Know what the skill needs before you run it

The skill is written for Claude Code. It also depends on referenced studio files from the Donchitos Claude Code Game Studios repository: .claude/docs/automation-modes.md, .claude/docs/config-resolution.md, .claude/docs/technical-preferences.md, and the hooks/yaml-helper.sh script. Without these, the pipeline may fall back to defaults and give less useful results.

The skill is licensed under MIT and runs scripts. It reads config through yaml-helper.sh. It does not use the network.

• Claude Code
• The referenced studio files and hooks/yaml-helper.sh from the same repository
• Scripts run: yes. Network use: no

Trigger the skill with a request

Invoke the skill with /team-ui followed by a description of the screen or feature, and optionally a --review flag. The argument hint is [UI feature description] [--review full|lean|solo]. Describe what the screen is for, since the agent uses that description to start the flows and specs.

If you run the skill with no description, it prints usage guidance and stops. It does not spawn agents or read design files in that case, so add a description before expecting a pipeline run.

• Example screen types from the usage guidance: inventory screen, main menu, combat HUD
• --review full, lean or solo sets how deep the review goes

Choose how much of the team runs (team.size and automation)

The team.size setting decides which agents are active. At the default individual size, the UI programmer and UX designer do the work and other agents are consulted through them. The small size adds the accessibility specialist and art director. The studio size adds an engine UI specialist and an adversarial review pass, where reviewers are told to look for where the work fails the spec rather than confirm it matches.

The automation setting controls how decision points behave. In collaborative mode, you must approve each phase before the next one starts. In guided mode, the pipeline advances on its own unless a phase is blocked. In autonomous mode, it runs end to end and records each phase outcome.

• team.size: individual (default), small, studio
• automation: collaborative, guided, autonomous
• Before work starts, the skill states which agents will run and which will not

Make the most of the review workflow

Give a concrete screen, not a vague goal. A request such as inventory screen with a grid of items and a detail panel gives the designer something to map into flows. Use the --review option to match the effort to the task.

Read the decision options carefully. The agents propose options at each transition, and your choice shapes the spec that is written. Keep the decision labels short, but read the full analysis in the conversation before choosing.

• Name the screen type and its main actions
• Use the default team size for a single menu, and raise it for a full HUD with accessibility concerns
• Check the written spec files after each phase