本文へ移動
cccskills
無料GitHub で公開

game-ui-design

Research-grounded workflow for designing, reviewing, and improving video game user interfaces, including HUDs, menus, navigation, focus states, onboarding/tutorials, objective tracking, input prompts, readability, accessibility, and destructive-action flows. Use when asked how to make good game UI, critique a game UI or HUD, propose UI/UX guidelines, design menu or gameplay interfaces, compare HUD vs diegetic/spatial presentation, create a UI design brief, or run a usability/accessibility review for PC, console, mobile, or VR games.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md5.4 KB
  • references/accessibility-platform-guidelines.md4.9 KB
  • references/output-patterns.md2.6 KB
  • references/research-evidence.md5.4 KB
  • references/review-checklist.md4.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Game UI Design

Design game UI around player decisions and task-relevant information. Use visual style to reinforce those decisions after the information architecture and interaction model are defined.

Workflow

  1. Identify the play context.

    • Determine genre, platform, camera perspective, input devices, expected viewing distance, pace, multiplayer constraints, and target audience.
    • If important context is missing, make explicit assumptions and keep recommendations conditional.
  2. Map player decisions to information.

    • List the decisions the player must make during each game state.
    • For each decision, identify the minimum information needed, how frequently it changes, and how quickly the player must notice it.
    • Classify information as immediate, near-term, or reference-only.
  3. Choose the presentation method.

    • Select HUD, diegetic, spatial/world-space, audio, haptic, or menu presentation according to task, urgency, frequency, and occlusion cost.
    • Do not assume diegetic UI or minimal HUD is inherently more immersive or more usable. Evidence does not support a universal winner across information types.
    • Use persistent presentation for information that must be monitored continuously. Use contextual or on-demand presentation for lower-priority information when it reduces distraction without hiding required state.
  4. Establish hierarchy and interaction consistency.

    • Give the highest visual priority to information that changes the player's next action.
    • Keep interaction mappings, button prompts, focus treatment, terminology, and menu structure predictable.
    • Make selected, focused, pressed, disabled, cooldown, warning, and error states perceptibly distinct.
  5. Design learning and recovery.

    • Teach mechanics through practice when possible, with timely feedback and access to reminders later.
    • Stage complex instruction so the player learns near the moment of use.
    • Let players revisit objectives, tutorials, narrative summaries, and progress when the game requires memory over time.
  6. Apply accessibility constraints early.

    • Treat readability, contrast, focus visibility, input flexibility, redundant sensory channels, and error recovery as design constraints rather than late polish.
    • For platform-specific numeric requirements, verify the current official guideline before quoting a number. The bundled accessibility reference contains a dated snapshot for fallback use.
  7. Evaluate with the right method.

    • Use heuristic review for early concepts and prototypes.
    • Use playtesting for task completion, comprehension, attention, and preference.
    • Separate usability findings from aesthetic preference and from game-balance difficulty.

Evidence and reference routing

Read references/research-evidence.md when making claims about HUDs, diegetic interfaces, tutorials, learnability, or game usability research.

Read references/accessibility-platform-guidelines.md when reviewing text size, contrast, sensory redundancy, input, objectives, menu navigation, focus, context, errors, or destructive actions.

Read references/review-checklist.md when auditing an existing UI, screenshot, prototype, or design document.

Read references/output-patterns.md when producing a critique, design brief, implementation guideline, or research-backed recommendation.

Core decision rules

  • Preserve immediate comprehension during play. A visually elegant interface that obscures required state has failed its task.
  • Optimize information placement for the specific gameplay task. Health, ammunition, navigation, targeting, objectives, and inventory can justify different presentation methods.
  • Minimize simultaneous competition for attention. Reduce decorative motion, notifications, and low-priority indicators around high-pressure decisions.
  • Keep critical status visible or quickly recoverable. Avoid forcing memory when the game can present current state or progress.
  • Use more than color alone for critical distinctions. Combine color with shape, label, pattern, position, outline, audio, haptic, or narration as appropriate.
  • Provide a clearly visible focus indicator for controller/keyboard menu navigation.
  • Update on-screen prompts after input rebinding or input-device changes.
  • Give players a review, confirm, cancel, or undo path for destructive or permanent actions.
  • Prefer player-configurable UI density, subtitles/captions, contrast, text scale, and input behavior when those settings are relevant to the game.

Quality bar

Ground strong recommendations in one of three forms: cited research, a current platform/accessibility guideline, or an explicit task-analysis argument. State study scope and limitations when a paper is descriptive, genre-specific, or based on a limited sample. Avoid turning one game's convention into a universal rule.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Add SLSA build-provenance attestations to existing GitHub Actions workflows. Use when the user wants to add artifact attestations, build provenance, or SLSA attestations to Docker container image builds in GitHub Actions CI/CD pipelines.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Guideline for designing, implementing, and verifying secure APIs following OWASP API Security Top 10 (2023) best practices. Use when the user wants to: (1) review API code or design for security vulnerabilities, (2) design a secure REST, GraphQL, or gRPC API architecture, (3) implement API authentication and authorization (OAuth2, JWT, API keys, mTLS), (4) configure rate limiting, input validation, or CORS, (5) audit API endpoints for BOLA, BFLA, or mass assignment vulnerabilities, (6) create API security checklists or verification plans, (7) fix API security bugs or harden existing APIs, (8) set up API security testing (OWASP ZAP, Schemathesis, Burp Suite), or (9) handle any API security concern including SSRF prevention, resource consumption limits, business flow protection, API inventory management, and secure third-party API consumption.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Write, review, and optionally test Bash and Zsh shell scripts following project coding standards. Use for ANY shell scripting task: (1) creating a new Bash or Zsh script, (2) editing, fixing, or reviewing an existing .sh, .bash, or .zsh file, (3) adding error handling, dependency checks, or cleanup traps to shell scripts, (4) implementing API integration or file processing in shell, (5) writing or fixing ShellSpec tests (spec/*_spec.sh), or (6) deciding whether a script should be written in Bash or Zsh. Defaults to Bash; Zsh-specific guidance lives in a reference file that is loaded only when writing Zsh.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

Create, run, and maintain API test collections using Bruno (OpenCollection YAML format and legacy Bru format). Use when the user wants to: (1) create a Bruno API test collection from scratch or from OpenAPI/Swagger specs, (2) write API request files with tests and assertions, (3) run API tests using bru CLI, (4) generate test reports (HTML, JUnit, JSON), (5) set up CI/CD pipelines (GitHub Actions) for automated API testing, (6) debug or fix failing Bruno API tests, (7) add environment configurations for API testing, (8) chain API requests with data extraction, or (9) work with any .yml/.bru Bruno collection files. Triggers on mentions of 'Bruno', 'bru CLI', 'API testing collection', 'OpenCollection', or requests to automate API testing with file-based collections.

日本語の概要は準備中です。原文の説明を表示しています。

jim60105/copilot-prompt212026年10月9日 更新

jim60105 のスキルをすべて見る

このスキルの問題を報告する