mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
Release 1.1.3 — long skills keep their later steps
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
This commit is contained in:
Donchitos
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
b21fa0f7f2
commit
be8993bbc5
@@ -12,6 +12,7 @@ model: sonnet
|
||||
Resolved above — use as-is. No block → defaults in
|
||||
`.claude/docs/config-resolution.md`.
|
||||
|
||||
# UX Design
|
||||
|
||||
When this skill is invoked:
|
||||
|
||||
@@ -76,575 +77,15 @@ for the filename (e.g., "Main Menu" becomes `main-menu`).
|
||||
|
||||
## 2. Gather Context (Read Phase)
|
||||
|
||||
Read all relevant context **before** asking the user anything. The skill's value
|
||||
comes from arriving informed.
|
||||
|
||||
### 2a: Required Reads
|
||||
|
||||
- **Game concept**: Read `design/gdd/game-concept.md` — or `design/game-brief.md`,
|
||||
the one-page brief that replaces it at `rigor: minimal` — if neither exists, warn:
|
||||
> "No game concept found. Run `/brainstorm` first to establish the game's
|
||||
> foundation before designing UX."
|
||||
> Continue anyway if the user asks.
|
||||
|
||||
### 2b: Player Journey
|
||||
|
||||
Read `design/player-journey.md` if it exists. For each relevant section, extract:
|
||||
- Which journey phase(s) does this screen appear in?
|
||||
- What is the player's emotional state on arrival at this screen?
|
||||
- What player need is this screen serving in the journey?
|
||||
- What critical moments (from the journey map) does this screen deliver?
|
||||
|
||||
If the player journey file does not exist, note the gap and proceed:
|
||||
> "No player journey map found at `design/player-journey.md`. Designing without it
|
||||
> means we'll be making assumptions about player context. Consider running a player
|
||||
> journey session after this spec is drafted."
|
||||
|
||||
Also add to the UX spec's Open Questions section:
|
||||
> "Player journey map not yet created. Author it from the template at `.claude/docs/templates/player-journey.md` to establish player context for this screen."
|
||||
|
||||
> **Do not tell the user to "run `/ux-design` Phase 2b" to create it.** Phase 2b
|
||||
> is this step — the one that *reads* the file. That remediation is circular: it
|
||||
> sends the user back to the check that just reported the gap. No skill
|
||||
> writes `design/player-journey.md`; it is hand-authored from its template.
|
||||
|
||||
### 2c: GDD UI Requirements
|
||||
|
||||
Glob `design/gdd/*.md` and grep for `UI Requirements` sections. Read any GDD whose
|
||||
UI Requirements section references this screen by name or category.
|
||||
|
||||
These GDD UI Requirements are the **requirements input** to this spec. Collect them
|
||||
as a list of constraints the spec must satisfy.
|
||||
|
||||
If designing the HUD, you need the UI Requirements of **every** system — the HUD
|
||||
aggregates them. Collect them with one scan rather than opening each GDD:
|
||||
|
||||
```
|
||||
Grep pattern="^#+ .*UI Requirements" glob="design/gdd/*.md" output_mode="content" -A 20
|
||||
```
|
||||
|
||||
Establish the denominator first (glob `design/gdd/*.md`, count **N**) and check
|
||||
the match count against it. Count system GDDs only: `game-concept.md`,
|
||||
`systems-index.md`, `game-pillars.md`, `gameplay-tags.md`, `entity-registry.md`,
|
||||
`fixture-swap-ledger.md`, `sound-bible.md` and any `gdd-cross-review-*.md` live
|
||||
there too, but they are not systems and have no UI to aggregate.
|
||||
**A GDD with no UI Requirements section is not a GDD
|
||||
with no UI needs** — it may predate the section. List the unmatched ones and
|
||||
confirm with the user that they are genuinely headless before excluding them
|
||||
from the HUD's requirement set; a HUD that silently omits a system's readout is
|
||||
the exact failure this aggregation exists to prevent.
|
||||
|
||||
### 2d: Existing UX Specs
|
||||
|
||||
Glob `design/ux/*.md` and note which screens already have specs. For screens that
|
||||
will link to or from the current screen, read their navigation/flow sections to
|
||||
find the entry and exit points this spec must match.
|
||||
|
||||
### 2e: Interaction Pattern Library
|
||||
|
||||
If `design/ux/interaction-patterns.md` exists, read the pattern catalog index
|
||||
(the list of pattern names and their one-line descriptions). Do not read full
|
||||
pattern details — just the catalog. This tells you which patterns already exist
|
||||
so you can reference them rather than reinvent them.
|
||||
|
||||
### 2f: Art Bible
|
||||
|
||||
Check for `design/art/art-bible.md`. If found, read the visual direction
|
||||
section. UX layout must align with the aesthetic commitments already made.
|
||||
|
||||
### 2g: Accessibility Requirements
|
||||
|
||||
Check for `design/accessibility-requirements.md`. If found, read it. The spec
|
||||
must satisfy the accessibility tier committed to there.
|
||||
|
||||
### 2h: Input Method (from Project Config)
|
||||
|
||||
Read the `platform` block from `project.yaml`; if `project.yaml` has no
|
||||
`platform` block, fall back to the `## Input & Platform` section of
|
||||
`.claude/docs/technical-preferences.md`. Store these values for use throughout
|
||||
the skill — they drive the Interaction Map and inform accessibility
|
||||
requirements:
|
||||
|
||||
- **Primary Input** — `platform.primary_input` — the dominant input for this game
|
||||
- **Gamepad Support** — `platform.gamepad_support` — Full / Partial / None
|
||||
- **Touch Support** — `platform.touch_support` — Full / Partial / None
|
||||
- **Target Platforms** — `platform.targets` — for safe zone and aspect ratio decisions
|
||||
- **Input Methods** — the set of supported methods. When reading from
|
||||
`project.yaml`, derive it: keyboard/mouse if `PC` or `Web` is in `targets`;
|
||||
gamepad if gamepad support is Full/Partial; touch if touch support is
|
||||
Full/Partial; plus the primary input. When falling back to
|
||||
`technical-preferences.md`, use its explicit Input Methods field.
|
||||
|
||||
If neither source is configured, ask once:
|
||||
> "Input methods aren't configured yet. What does this game target?"
|
||||
> Options: "Keyboard/Mouse only", "Gamepad only", "Both (PC + Console)", "Touch (mobile)", "All of the above"
|
||||
>
|
||||
> (Run `/setup-engine` to save this permanently so you won't be asked again.)
|
||||
|
||||
Store the answer for the rest of this session. Do **not** ask again per section
|
||||
or per screen.
|
||||
|
||||
### 2i: Present Context Summary
|
||||
|
||||
Before any design work, present a brief summary to the user:
|
||||
|
||||
> **Designing: [Screen/Flow Name]**
|
||||
> - Mode: [UX Spec / HUD Design / Pattern Library]
|
||||
> - Journey phase(s): [from player-journey.md, or "unknown — no journey map"]
|
||||
> - GDD requirements feeding this spec: [count and names, or "none found"]
|
||||
> - Related screens already specced: [list, or "none yet"]
|
||||
> - Known patterns available: [count, or "no pattern library yet"]
|
||||
> - Accessibility tier: [from requirements doc, or "not yet defined"]
|
||||
> - Input methods: [derived from the `project.yaml` platform block, or "asked above"]
|
||||
|
||||
Then ask: "Anything else I should read before we start, or shall we proceed?"
|
||||
|
||||
---
|
||||
|
||||
## 2b. Retrofit Mode Detection
|
||||
|
||||
Before creating a skeleton, check if the target output file already exists.
|
||||
|
||||
Glob the resolved output path from Phase 1 — `design/ux/[filename].md`, or
|
||||
`design/accessibility-requirements.md` in `accessibility` mode.
|
||||
|
||||
**If the file exists — retrofit mode:**
|
||||
- Read the file in full
|
||||
- For each expected section, check whether the body has real content (more than a `[To be designed]` placeholder) or is empty/placeholder
|
||||
- Present a section status summary to the user:
|
||||
|
||||
> "Found existing UX spec at `design/ux/[filename].md`. Here's what's already done:
|
||||
>
|
||||
> | Section | Status |
|
||||
> |---------|--------|
|
||||
> | Purpose & Player Need | [Complete / Empty / Placeholder] |
|
||||
> | Player Context on Arrival | ... |
|
||||
> | Navigation Position | ... |
|
||||
> | Entry & Exit Points | ... |
|
||||
> | Layout Specification | ... |
|
||||
> | States & Variants | ... |
|
||||
> | Interaction Map | ... |
|
||||
> | Data Requirements | ... |
|
||||
> | Events Fired | ... |
|
||||
> | Transitions & Animations | ... |
|
||||
> | Input Method Completeness Checklist | ... |
|
||||
> | Accessibility | ... |
|
||||
> | Localization Considerations | ... |
|
||||
> | Acceptance Criteria | ... |
|
||||
> | Open Questions | ... |
|
||||
>
|
||||
> (Rows are the skeleton's own `##` headings for the active mode — the list above is
|
||||
> UX spec mode; HUD and accessibility modes list their skeleton's headings.)
|
||||
>
|
||||
> I'll work on the [N] incomplete sections only — existing content will not be overwritten."
|
||||
|
||||
- Skip Section 3 (skeleton creation) — the file already exists
|
||||
- In Phase 4 (Section Authoring), only work on sections with Status: Empty or Placeholder
|
||||
- Use `Edit` to fill placeholders in-place rather than creating a new skeleton
|
||||
|
||||
**If the file does not exist — fresh authoring mode:**
|
||||
Proceed to Phase 3 (Create File Skeleton) as normal.
|
||||
|
||||
---
|
||||
**Read `references/2-gather-context.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
||||
|
||||
## 3. Create File Skeleton
|
||||
|
||||
Once the user confirms, **immediately** create the output file with empty section
|
||||
headers. This ensures incremental writes have a target and work survives interruptions.
|
||||
|
||||
Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except in
|
||||
`accessibility` mode, where the path is `design/accessibility-requirements.md`
|
||||
(see the mode table in Section 1; it is deliberately not under `design/ux/`).
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for UX Spec (screen or flow)
|
||||
|
||||
```markdown
|
||||
# UX Spec: [Screen/Flow Name]
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Journey Phase(s)**: [from context]
|
||||
> **Platform Target**: [target platforms and input methods from 2h]
|
||||
> **Template**: UX Spec
|
||||
|
||||
---
|
||||
|
||||
## Purpose & Player Need
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Player Context on Arrival
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Navigation Position
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Entry & Exit Points
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Layout Specification
|
||||
|
||||
### ASCII Wireframe
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Layout Zones
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Component Inventory
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## States & Variants
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Interaction Map
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Data Requirements
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Events Fired
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Transitions & Animations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Input Method Completeness Checklist
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Localization Considerations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for HUD Design
|
||||
|
||||
```markdown
|
||||
# HUD Design
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Platform Targets**: [target platforms and input methods from 2h]
|
||||
> **Template**: HUD Design
|
||||
|
||||
---
|
||||
|
||||
## HUD Philosophy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Information Architecture
|
||||
|
||||
### Full Information Inventory
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Categorization
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Layout Zones
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## HUD Element Specifications
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## HUD States by Gameplay Context
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Visual Budget
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Feedback & Notification Systems
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform Adaptation
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Tuning Knobs
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for Interaction Pattern Library
|
||||
|
||||
```markdown
|
||||
# Interaction Pattern Library
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Template**: Interaction Pattern Library
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Pattern Catalog
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Patterns
|
||||
|
||||
[Individual pattern entries added here as they are defined]
|
||||
|
||||
---
|
||||
|
||||
## Gaps & Patterns Needed
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for Accessibility Requirements
|
||||
|
||||
Section list mirrors `.claude/docs/templates/accessibility-requirements.md` — if
|
||||
the template gains or loses a section, this skeleton follows it, not the reverse.
|
||||
|
||||
```markdown
|
||||
# Accessibility Requirements
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Template**: Accessibility Requirements
|
||||
|
||||
## Accessibility Tier Definition
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Visual Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Motor Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Cognitive Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Auditory Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform Accessibility API Integration
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Per-Feature Accessibility Matrix
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility Test Plan
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Known Intentional Limitations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Audit History
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## External Resources
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
> **The tier commitment is the gated part.** `gate-pre-production.md` requires
|
||||
> the file to exist *with an accessibility tier committed*, and
|
||||
> `gate-production.md` checks that tier is addressed in every key screen spec.
|
||||
> A skeleton whose Tier Definition is still `[To be designed]` satisfies the
|
||||
> glob but not the gate — author that section first.
|
||||
|
||||
---
|
||||
|
||||
After writing the skeleton, update `production/session-state/active.md` with:
|
||||
- Task: Designing [screen/flow name] UX spec
|
||||
- Current section: Starting (skeleton created)
|
||||
- File: design/ux/[filename].md (or `design/accessibility-requirements.md` in `accessibility` mode)
|
||||
|
||||
---
|
||||
**Read `references/3-file-skeleton.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
||||
|
||||
## 4. Section-by-Section Authoring
|
||||
|
||||
Walk through each section in order. For **each section**, follow this cycle:
|
||||
|
||||
```
|
||||
Context -> Questions -> Options -> Decision -> Draft -> Approval -> Write
|
||||
```
|
||||
|
||||
1. **Context**: State what this section needs to contain and surface any relevant
|
||||
constraints from context gathered in Phase 2.
|
||||
2. **Questions**: Ask what is needed to draft this section. Use `AskUserQuestion`
|
||||
for constrained choices, conversational text for open-ended exploration.
|
||||
3. **Options**: Where design choices exist, present 2-4 approaches with pros/cons.
|
||||
Explain reasoning in conversation, then use `AskUserQuestion` to capture the decision.
|
||||
4. **Decision**: User picks an approach or provides custom direction.
|
||||
5. **Draft**: Write the section content in conversation for review. Flag provisional
|
||||
assumptions explicitly.
|
||||
6. **Approval**: Use `AskUserQuestion`:
|
||||
- "Does this capture the [section name] correctly?"
|
||||
- Options: "Yes — write it to the file", "Small changes needed (describe below)", "Major rethink needed"
|
||||
Do not proceed to step 7 until the user selects "Yes".
|
||||
7. **Write**: Use `AskUserQuestion`: "May I write the [section name] section to `[filepath]`?"
|
||||
- Options: "Yes, write it", "Wait — one more change"
|
||||
Once confirmed, use `Edit` to replace the `[To be designed]` placeholder with approved content.
|
||||
|
||||
After writing each section, update `production/session-state/active.md`.
|
||||
|
||||
---
|
||||
**Read `references/4-authoring.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
||||
|
||||
### Section guidance — read the ONE file for the active mode
|
||||
|
||||
@@ -654,9 +95,9 @@ the other two.**
|
||||
|
||||
| Mode | Guidance file |
|
||||
|------|---------------|
|
||||
| UX Spec (screen or flow) | `.claude/skills/ux-design/references/sections-ux-spec.md` |
|
||||
| HUD Design | `.claude/skills/ux-design/references/sections-hud.md` |
|
||||
| Interaction Pattern Library | `.claude/skills/ux-design/references/sections-patterns.md` |
|
||||
| UX Spec (screen or flow) | `references/sections-ux-spec.md` |
|
||||
| HUD Design | `references/sections-hud.md` |
|
||||
| Interaction Pattern Library | `references/sections-patterns.md` |
|
||||
| Accessibility Requirements | `.claude/docs/templates/guidance/accessibility-requirements-guide.md` |
|
||||
|
||||
> The accessibility guidance lives under `templates/guidance/` rather than this
|
||||
@@ -668,80 +109,9 @@ the other two.**
|
||||
Apply `docs.density` (Section 1) to whatever that file tells you to author — it
|
||||
controls the depth of each section, not which sections exist.
|
||||
|
||||
---
|
||||
|
||||
## 5. Cross-Reference Check
|
||||
|
||||
Before marking the spec as ready for review, run these checks:
|
||||
|
||||
**1. GDD requirement coverage**: Does every GDD UI Requirement that references
|
||||
this screen have a corresponding element in this spec? Present any gaps.
|
||||
|
||||
**2. Pattern library alignment**: Are all interaction patterns used in this spec
|
||||
referenced by name? If a new pattern was invented during this spec session, flag
|
||||
it for addition to the pattern library:
|
||||
Use `AskUserQuestion`:
|
||||
- "This spec uses [pattern name], which isn't in the pattern library yet. What should we do?"
|
||||
- Options: "Add it to the pattern library now", "Flag it as a gap and continue", "Skip — this pattern is one-off"
|
||||
|
||||
**3. Navigation consistency**: Do the entry/exit points in this spec match the
|
||||
navigation map in any related specs? Flag mismatches.
|
||||
|
||||
**4. Accessibility coverage**: Does the spec address the accessibility tier
|
||||
committed to in `design/accessibility-requirements.md`? If not, flag open questions.
|
||||
|
||||
**5. Empty states**: Does every data-dependent element have an empty state defined?
|
||||
Flag any that don't.
|
||||
|
||||
Present the check results:
|
||||
> **Cross-Reference Check: [Screen Name]**
|
||||
> - GDD requirements: [N of M covered / all covered]
|
||||
> - New patterns to add to library: [list or "none"]
|
||||
> - Navigation mismatches: [list or "none"]
|
||||
> - Accessibility gaps: [list or "none"]
|
||||
> - Missing empty states: [list or "none"]
|
||||
|
||||
---
|
||||
|
||||
## 6. Handoff
|
||||
|
||||
When all sections are approved and written:
|
||||
|
||||
### 6a: Update Session State
|
||||
|
||||
Update `production/session-state/active.md` with:
|
||||
- Task: [screen-name] UX spec
|
||||
- Status: Complete (or In Review)
|
||||
- File: design/ux/[filename].md
|
||||
- Sections: All written
|
||||
- Next: [suggestion]
|
||||
|
||||
### 6b: Suggest Next Step
|
||||
|
||||
Before presenting options, state clearly:
|
||||
|
||||
> "This spec should be validated with `/ux-review` before it enters the
|
||||
> implementation pipeline. The Production gate (`/gate-check production`)
|
||||
> requires all key screen specs to have passed `/ux-review` at `workflow: full`
|
||||
> (recommended at `standard`)."
|
||||
|
||||
Then use `AskUserQuestion`:
|
||||
- "Run `/ux-review [filename]` now, or do something else first?"
|
||||
- Options:
|
||||
- "Run `/ux-review` now — validate this spec"
|
||||
- "Design another screen first, then review all specs together"
|
||||
- "Update the interaction pattern library with new patterns from this spec"
|
||||
- "Stop here for this session"
|
||||
|
||||
If the user picks "Design another screen first", add a note: "Reminder: run
|
||||
`/ux-review` on all completed specs before running `/gate-check production`."
|
||||
|
||||
### 6c: Cross-Link Related Specs
|
||||
|
||||
If other UX specs link to or from this screen, note which ones should reference
|
||||
this spec. Do not edit those files without asking — just name them.
|
||||
|
||||
---
|
||||
**Read `references/5-crossref-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.
|
||||
|
||||
## 7. Recovery & Resume
|
||||
|
||||
|
||||
@@ -0,0 +1,189 @@
|
||||
# /ux-design — Sections 2 and 2b: Gather Context and Retrofit Detection
|
||||
|
||||
> Part of `/ux-design`. `SKILL.md` names when to read this file; the settings it
|
||||
> resolved and the rules under its later headings still apply here.
|
||||
|
||||
## 2. Gather Context (Read Phase)
|
||||
|
||||
**In this file:**
|
||||
|
||||
- 2a: Required Reads
|
||||
- 2b: Player Journey
|
||||
- 2c: GDD UI Requirements
|
||||
- 2d: Existing UX Specs
|
||||
- 2e: Interaction Pattern Library
|
||||
- 2f: Art Bible
|
||||
- 2g: Accessibility Requirements
|
||||
- 2h: Input Method (from Project Config)
|
||||
- 2i: Present Context Summary
|
||||
|
||||
Read all relevant context **before** asking the user anything. The skill's value
|
||||
comes from arriving informed.
|
||||
|
||||
### 2a: Required Reads
|
||||
|
||||
- **Game concept**: Read `design/gdd/game-concept.md` — or `design/game-brief.md`,
|
||||
the one-page brief that replaces it at `rigor: minimal` — if neither exists, warn:
|
||||
> "No game concept found. Run `/brainstorm` first to establish the game's
|
||||
> foundation before designing UX."
|
||||
> Continue anyway if the user asks.
|
||||
|
||||
### 2b: Player Journey
|
||||
|
||||
Read `design/player-journey.md` if it exists. For each relevant section, extract:
|
||||
- Which journey phase(s) does this screen appear in?
|
||||
- What is the player's emotional state on arrival at this screen?
|
||||
- What player need is this screen serving in the journey?
|
||||
- What critical moments (from the journey map) does this screen deliver?
|
||||
|
||||
If the player journey file does not exist, note the gap and proceed:
|
||||
> "No player journey map found at `design/player-journey.md`. Designing without it
|
||||
> means we'll be making assumptions about player context. Consider running a player
|
||||
> journey session after this spec is drafted."
|
||||
|
||||
Also add to the UX spec's Open Questions section:
|
||||
> "Player journey map not yet created. Author it from the template at `.claude/docs/templates/player-journey.md` to establish player context for this screen."
|
||||
|
||||
> **Do not tell the user to "run `/ux-design` Phase 2b" to create it.** Phase 2b
|
||||
> is this step — the one that *reads* the file. That remediation is circular: it
|
||||
> sends the user back to the check that just reported the gap. No skill
|
||||
> writes `design/player-journey.md`; it is hand-authored from its template.
|
||||
|
||||
### 2c: GDD UI Requirements
|
||||
|
||||
Glob `design/gdd/*.md` and grep for `UI Requirements` sections. Read any GDD whose
|
||||
UI Requirements section references this screen by name or category.
|
||||
|
||||
These GDD UI Requirements are the **requirements input** to this spec. Collect them
|
||||
as a list of constraints the spec must satisfy.
|
||||
|
||||
If designing the HUD, you need the UI Requirements of **every** system — the HUD
|
||||
aggregates them. Collect them with one scan rather than opening each GDD:
|
||||
|
||||
```
|
||||
Grep pattern="^#+ .*UI Requirements" glob="design/gdd/*.md" output_mode="content" -A 20
|
||||
```
|
||||
|
||||
Establish the denominator first (glob `design/gdd/*.md`, count **N**) and check
|
||||
the match count against it. Count system GDDs only: `game-concept.md`,
|
||||
`systems-index.md`, `game-pillars.md`, `gameplay-tags.md`, `entity-registry.md`,
|
||||
`fixture-swap-ledger.md`, `sound-bible.md` and any `gdd-cross-review-*.md` live
|
||||
there too, but they are not systems and have no UI to aggregate.
|
||||
**A GDD with no UI Requirements section is not a GDD
|
||||
with no UI needs** — it may predate the section. List the unmatched ones and
|
||||
confirm with the user that they are genuinely headless before excluding them
|
||||
from the HUD's requirement set; a HUD that silently omits a system's readout is
|
||||
the exact failure this aggregation exists to prevent.
|
||||
|
||||
### 2d: Existing UX Specs
|
||||
|
||||
Glob `design/ux/*.md` and note which screens already have specs. For screens that
|
||||
will link to or from the current screen, read their navigation/flow sections to
|
||||
find the entry and exit points this spec must match.
|
||||
|
||||
### 2e: Interaction Pattern Library
|
||||
|
||||
If `design/ux/interaction-patterns.md` exists, read the pattern catalog index
|
||||
(the list of pattern names and their one-line descriptions). Do not read full
|
||||
pattern details — just the catalog. This tells you which patterns already exist
|
||||
so you can reference them rather than reinvent them.
|
||||
|
||||
### 2f: Art Bible
|
||||
|
||||
Check for `design/art/art-bible.md`. If found, read the visual direction
|
||||
section. UX layout must align with the aesthetic commitments already made.
|
||||
|
||||
### 2g: Accessibility Requirements
|
||||
|
||||
Check for `design/accessibility-requirements.md`. If found, read it. The spec
|
||||
must satisfy the accessibility tier committed to there.
|
||||
|
||||
### 2h: Input Method (from Project Config)
|
||||
|
||||
Read the `platform` block from `project.yaml`; if `project.yaml` has no
|
||||
`platform` block, fall back to the `## Input & Platform` section of
|
||||
`.claude/docs/technical-preferences.md`. Store these values for use throughout
|
||||
the skill — they drive the Interaction Map and inform accessibility
|
||||
requirements:
|
||||
|
||||
- **Primary Input** — `platform.primary_input` — the dominant input for this game
|
||||
- **Gamepad Support** — `platform.gamepad_support` — Full / Partial / None
|
||||
- **Touch Support** — `platform.touch_support` — Full / Partial / None
|
||||
- **Target Platforms** — `platform.targets` — for safe zone and aspect ratio decisions
|
||||
- **Input Methods** — the set of supported methods. When reading from
|
||||
`project.yaml`, derive it: keyboard/mouse if `PC` or `Web` is in `targets`;
|
||||
gamepad if gamepad support is Full/Partial; touch if touch support is
|
||||
Full/Partial; plus the primary input. When falling back to
|
||||
`technical-preferences.md`, use its explicit Input Methods field.
|
||||
|
||||
If neither source is configured, ask once:
|
||||
> "Input methods aren't configured yet. What does this game target?"
|
||||
> Options: "Keyboard/Mouse only", "Gamepad only", "Both (PC + Console)", "Touch (mobile)", "All of the above"
|
||||
>
|
||||
> (Run `/setup-engine` to save this permanently so you won't be asked again.)
|
||||
|
||||
Store the answer for the rest of this session. Do **not** ask again per section
|
||||
or per screen.
|
||||
|
||||
### 2i: Present Context Summary
|
||||
|
||||
Before any design work, present a brief summary to the user:
|
||||
|
||||
> **Designing: [Screen/Flow Name]**
|
||||
> - Mode: [UX Spec / HUD Design / Pattern Library]
|
||||
> - Journey phase(s): [from player-journey.md, or "unknown — no journey map"]
|
||||
> - GDD requirements feeding this spec: [count and names, or "none found"]
|
||||
> - Related screens already specced: [list, or "none yet"]
|
||||
> - Known patterns available: [count, or "no pattern library yet"]
|
||||
> - Accessibility tier: [from requirements doc, or "not yet defined"]
|
||||
> - Input methods: [derived from the `project.yaml` platform block, or "asked above"]
|
||||
|
||||
Then ask: "Anything else I should read before we start, or shall we proceed?"
|
||||
|
||||
---
|
||||
|
||||
## 2b. Retrofit Mode Detection
|
||||
|
||||
Before creating a skeleton, check if the target output file already exists.
|
||||
|
||||
Glob the resolved output path from Phase 1 — `design/ux/[filename].md`, or
|
||||
`design/accessibility-requirements.md` in `accessibility` mode.
|
||||
|
||||
**If the file exists — retrofit mode:**
|
||||
- Read the file in full
|
||||
- For each expected section, check whether the body has real content (more than a `[To be designed]` placeholder) or is empty/placeholder
|
||||
- Present a section status summary to the user:
|
||||
|
||||
> "Found existing UX spec at `design/ux/[filename].md`. Here's what's already done:
|
||||
>
|
||||
> | Section | Status |
|
||||
> |---------|--------|
|
||||
> | Purpose & Player Need | [Complete / Empty / Placeholder] |
|
||||
> | Player Context on Arrival | ... |
|
||||
> | Navigation Position | ... |
|
||||
> | Entry & Exit Points | ... |
|
||||
> | Layout Specification | ... |
|
||||
> | States & Variants | ... |
|
||||
> | Interaction Map | ... |
|
||||
> | Data Requirements | ... |
|
||||
> | Events Fired | ... |
|
||||
> | Transitions & Animations | ... |
|
||||
> | Input Method Completeness Checklist | ... |
|
||||
> | Accessibility | ... |
|
||||
> | Localization Considerations | ... |
|
||||
> | Acceptance Criteria | ... |
|
||||
> | Open Questions | ... |
|
||||
>
|
||||
> (Rows are the skeleton's own `##` headings for the active mode — the list above is
|
||||
> UX spec mode; HUD and accessibility modes list their skeleton's headings.)
|
||||
>
|
||||
> I'll work on the [N] incomplete sections only — existing content will not be overwritten."
|
||||
|
||||
- Skip Section 3 (skeleton creation) — the file already exists
|
||||
- In Phase 4 (Section Authoring), only work on sections with Status: Empty or Placeholder
|
||||
- Use `Edit` to fill placeholders in-place rather than creating a new skeleton
|
||||
|
||||
**If the file does not exist — fresh authoring mode:**
|
||||
Proceed to Phase 3 (Create File Skeleton) as normal.
|
||||
|
||||
---
|
||||
@@ -0,0 +1,381 @@
|
||||
# /ux-design — Section 3: Create File Skeleton
|
||||
|
||||
> Part of `/ux-design`. `SKILL.md` names when to read this file; the settings it
|
||||
> resolved and the rules under its later headings still apply here.
|
||||
|
||||
## 3. Create File Skeleton
|
||||
|
||||
**In this file:**
|
||||
|
||||
- Skeleton for UX Spec (screen or flow)
|
||||
- Skeleton for HUD Design
|
||||
- Skeleton for Interaction Pattern Library
|
||||
- Skeleton for Accessibility Requirements
|
||||
|
||||
Once the user confirms, **immediately** create the output file with empty section
|
||||
headers. This ensures incremental writes have a target and work survives interruptions.
|
||||
|
||||
Ask: "May I create the skeleton file at `design/ux/[filename].md`?" — except in
|
||||
`accessibility` mode, where the path is `design/accessibility-requirements.md`
|
||||
(see the mode table in Section 1; it is deliberately not under `design/ux/`).
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for UX Spec (screen or flow)
|
||||
|
||||
```markdown
|
||||
# UX Spec: [Screen/Flow Name]
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Journey Phase(s)**: [from context]
|
||||
> **Platform Target**: [target platforms and input methods from 2h]
|
||||
> **Template**: UX Spec
|
||||
|
||||
---
|
||||
|
||||
## Purpose & Player Need
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Player Context on Arrival
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Navigation Position
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Entry & Exit Points
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Layout Specification
|
||||
|
||||
### ASCII Wireframe
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Layout Zones
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Component Inventory
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## States & Variants
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Interaction Map
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Data Requirements
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Events Fired
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Transitions & Animations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Input Method Completeness Checklist
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Localization Considerations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for HUD Design
|
||||
|
||||
```markdown
|
||||
# HUD Design
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Platform Targets**: [target platforms and input methods from 2h]
|
||||
> **Template**: HUD Design
|
||||
|
||||
---
|
||||
|
||||
## HUD Philosophy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Information Architecture
|
||||
|
||||
### Full Information Inventory
|
||||
|
||||
[To be designed]
|
||||
|
||||
### Categorization
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Layout Zones
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## HUD Element Specifications
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## HUD States by Gameplay Context
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Information Hierarchy
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Visual Budget
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Feedback & Notification Systems
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform Adaptation
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Tuning Knobs
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for Interaction Pattern Library
|
||||
|
||||
```markdown
|
||||
# Interaction Pattern Library
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Template**: Interaction Pattern Library
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Pattern Catalog
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Patterns
|
||||
|
||||
[Individual pattern entries added here as they are defined]
|
||||
|
||||
---
|
||||
|
||||
## Gaps & Patterns Needed
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Skeleton for Accessibility Requirements
|
||||
|
||||
Section list mirrors `.claude/docs/templates/accessibility-requirements.md` — if
|
||||
the template gains or loses a section, this skeleton follows it, not the reverse.
|
||||
|
||||
```markdown
|
||||
# Accessibility Requirements
|
||||
|
||||
> **Status**: In Design
|
||||
> **Author**: [user + ux-designer]
|
||||
> **Last Updated**: [today's date]
|
||||
> **Template**: Accessibility Requirements
|
||||
|
||||
## Accessibility Tier Definition
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Visual Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Motor Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Cognitive Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Auditory Accessibility
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Platform Accessibility API Integration
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Per-Feature Accessibility Matrix
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Accessibility Test Plan
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Known Intentional Limitations
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Audit History
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## External Resources
|
||||
|
||||
[To be designed]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
|
||||
[To be designed]
|
||||
```
|
||||
|
||||
> **The tier commitment is the gated part.** `gate-pre-production.md` requires
|
||||
> the file to exist *with an accessibility tier committed*, and
|
||||
> `gate-production.md` checks that tier is addressed in every key screen spec.
|
||||
> A skeleton whose Tier Definition is still `[To be designed]` satisfies the
|
||||
> glob but not the gate — author that section first.
|
||||
|
||||
---
|
||||
|
||||
After writing the skeleton, update `production/session-state/active.md` with:
|
||||
- Task: Designing [screen/flow name] UX spec
|
||||
- Current section: Starting (skeleton created)
|
||||
- File: design/ux/[filename].md (or `design/accessibility-requirements.md` in `accessibility` mode)
|
||||
|
||||
---
|
||||
@@ -0,0 +1,31 @@
|
||||
# /ux-design — Section 4: Section-by-Section Authoring
|
||||
|
||||
> Part of `/ux-design`. `SKILL.md` names when to read this file; the settings it
|
||||
> resolved and the rules under its later headings still apply here.
|
||||
|
||||
## 4. Section-by-Section Authoring
|
||||
|
||||
Walk through each section in order. For **each section**, follow this cycle:
|
||||
|
||||
```
|
||||
Context -> Questions -> Options -> Decision -> Draft -> Approval -> Write
|
||||
```
|
||||
|
||||
1. **Context**: State what this section needs to contain and surface any relevant
|
||||
constraints from context gathered in Phase 2.
|
||||
2. **Questions**: Ask what is needed to draft this section. Use `AskUserQuestion`
|
||||
for constrained choices, conversational text for open-ended exploration.
|
||||
3. **Options**: Where design choices exist, present 2-4 approaches with pros/cons.
|
||||
Explain reasoning in conversation, then use `AskUserQuestion` to capture the decision.
|
||||
4. **Decision**: User picks an approach or provides custom direction.
|
||||
5. **Draft**: Write the section content in conversation for review. Flag provisional
|
||||
assumptions explicitly.
|
||||
6. **Approval**: Use `AskUserQuestion`:
|
||||
- "Does this capture the [section name] correctly?"
|
||||
- Options: "Yes — write it to the file", "Small changes needed (describe below)", "Major rethink needed"
|
||||
Do not proceed to step 7 until the user selects "Yes".
|
||||
7. **Write**: Use `AskUserQuestion`: "May I write the [section name] section to `[filepath]`?"
|
||||
- Options: "Yes, write it", "Wait — one more change"
|
||||
Once confirmed, use `Edit` to replace the `[To be designed]` placeholder with approved content.
|
||||
|
||||
After writing each section, update `production/session-state/active.md`.
|
||||
@@ -0,0 +1,77 @@
|
||||
# /ux-design — Sections 5 and 6: Cross-Reference Check and Handoff
|
||||
|
||||
> Part of `/ux-design`. `SKILL.md` names when to read this file; the settings it
|
||||
> resolved and the rules under its later headings still apply here.
|
||||
|
||||
## 5. Cross-Reference Check
|
||||
|
||||
Before marking the spec as ready for review, run these checks:
|
||||
|
||||
**1. GDD requirement coverage**: Does every GDD UI Requirement that references
|
||||
this screen have a corresponding element in this spec? Present any gaps.
|
||||
|
||||
**2. Pattern library alignment**: Are all interaction patterns used in this spec
|
||||
referenced by name? If a new pattern was invented during this spec session, flag
|
||||
it for addition to the pattern library:
|
||||
Use `AskUserQuestion`:
|
||||
- "This spec uses [pattern name], which isn't in the pattern library yet. What should we do?"
|
||||
- Options: "Add it to the pattern library now", "Flag it as a gap and continue", "Skip — this pattern is one-off"
|
||||
|
||||
**3. Navigation consistency**: Do the entry/exit points in this spec match the
|
||||
navigation map in any related specs? Flag mismatches.
|
||||
|
||||
**4. Accessibility coverage**: Does the spec address the accessibility tier
|
||||
committed to in `design/accessibility-requirements.md`? If not, flag open questions.
|
||||
|
||||
**5. Empty states**: Does every data-dependent element have an empty state defined?
|
||||
Flag any that don't.
|
||||
|
||||
Present the check results:
|
||||
> **Cross-Reference Check: [Screen Name]**
|
||||
> - GDD requirements: [N of M covered / all covered]
|
||||
> - New patterns to add to library: [list or "none"]
|
||||
> - Navigation mismatches: [list or "none"]
|
||||
> - Accessibility gaps: [list or "none"]
|
||||
> - Missing empty states: [list or "none"]
|
||||
|
||||
---
|
||||
|
||||
## 6. Handoff
|
||||
|
||||
When all sections are approved and written:
|
||||
|
||||
### 6a: Update Session State
|
||||
|
||||
Update `production/session-state/active.md` with:
|
||||
- Task: [screen-name] UX spec
|
||||
- Status: Complete (or In Review)
|
||||
- File: design/ux/[filename].md
|
||||
- Sections: All written
|
||||
- Next: [suggestion]
|
||||
|
||||
### 6b: Suggest Next Step
|
||||
|
||||
Before presenting options, state clearly:
|
||||
|
||||
> "This spec should be validated with `/ux-review` before it enters the
|
||||
> implementation pipeline. The Production gate (`/gate-check production`)
|
||||
> requires all key screen specs to have passed `/ux-review` at `workflow: full`
|
||||
> (recommended at `standard`)."
|
||||
|
||||
Then use `AskUserQuestion`:
|
||||
- "Run `/ux-review [filename]` now, or do something else first?"
|
||||
- Options:
|
||||
- "Run `/ux-review` now — validate this spec"
|
||||
- "Design another screen first, then review all specs together"
|
||||
- "Update the interaction pattern library with new patterns from this spec"
|
||||
- "Stop here for this session"
|
||||
|
||||
If the user picks "Design another screen first", add a note: "Reminder: run
|
||||
`/ux-review` on all completed specs before running `/gate-check production`."
|
||||
|
||||
### 6c: Cross-Link Related Specs
|
||||
|
||||
If other UX specs link to or from this screen, note which ones should reference
|
||||
this spec. Do not edit those files without asking — just name them.
|
||||
|
||||
---
|
||||
@@ -3,6 +3,13 @@
|
||||
|
||||
# Section Guidance — HUD Design Mode
|
||||
|
||||
**In this file:**
|
||||
|
||||
- Section A: HUD Philosophy
|
||||
- Section B: Information Architecture
|
||||
- Section C: Layout Zones
|
||||
- Section D: HUD Element Specifications
|
||||
- Sections E–L: HUD States, Information Hierarchy, Visual Budget, Feedback & Notification, Platform Adaptation, Accessibility, Tuning Knobs, Acceptance Criteria
|
||||
|
||||
HUD design follows a different order from UX spec mode. Begin with philosophy;
|
||||
do not touch layout until the information architecture is complete.
|
||||
|
||||
@@ -3,6 +3,22 @@
|
||||
|
||||
# Section Guidance — UX Spec Mode
|
||||
|
||||
**In this file:**
|
||||
|
||||
- Section A: Purpose & Player Need
|
||||
- Section B: Player Context on Arrival
|
||||
- Section B2: Navigation Position
|
||||
- Section B3: Entry & Exit Points
|
||||
- Section C: Layout Specification
|
||||
- Section D: States & Variants
|
||||
- Section E: Interaction Map
|
||||
- Section E2: Events Fired
|
||||
- Section E3: Transitions & Animations
|
||||
- Section F: Data Requirements
|
||||
- Section F2: Input Method Completeness Checklist
|
||||
- Section G: Accessibility
|
||||
- Section H: Localization Considerations
|
||||
- Section I: Acceptance Criteria
|
||||
|
||||
#### Section A: Purpose & Player Need
|
||||
|
||||
|
||||
Reference in New Issue
Block a user