ui-spec

$npx mdskill add tranhieutt/software_development_department/ui-spec

Translate PRDs and prototypes into detailed UI specifications.

  • Maps acceptance criteria to UI screens and interactions.
  • Reads existing prototype code to understand components and states.
  • Defines component trees and identifies reusable vs. new components.
  • Outputs a structured UI spec with state matrix and EARS interactions.

SKILL.md

.github/skills/ui-specView on GitHub ↗
---
name: ui-spec
type: workflow
description: "Guidelines and procedures for creating comprehensive UI Specifications from PRDs and prototypes."
user-invocable: true
allowed-tools: Read, Glob, Grep, Write
effort: 3
argument-hint: "[prd, prototype, or feature name]"
when_to_use: "Use when translating a PRD, prototype, or feature brief into a concrete UI specification with components, states, and interactions."
---

# Skill: /ui-spec

Use this skill when moving from a PRD (Requirements) to a technical UI design. This skill bridges the gap between wireframes and code.

## The UI Spec Lifecycle

### 1. Analysis Phase
- **Map ACs**: Map every Acceptance Criterion from the PRD to a UI screen or interaction.
- **Prototype Ingestion**: If prototype code exists (e.g., from `prototyper`), read it to understand components and states.

### 2. Decomposition Phase
- Define the **Component Tree**.
- Identify which components can be reused from the existing codebase vs. which need to be new.

### 3. Specification Phase
Fill out the `ui-spec-template` including:
- **State Matrix**: Explicitly define what the user sees during `Loading`, `Error`, and `Empty` states.
- **Interactions**: Use EARS format (Condition-Trigger-Response) for all interactive elements.

### 4. Integration Phase
- Link the UI Spec in the feature's [Design Doc].
- Use the UI Spec as the checklist for the `frontend-developer`.

## The State x Display Matrix
Every component MUST define behavior for these 5 states:
1. **Default**: The "Happy Path".
2. **Loading**: Bone skeletal screens or spinners.
3. **Empty**: Context-aware messages when no data exists.
4. **Error**: User-friendly error messages with recovery actions (Retry/Reset).
5. **Partial**: Behavior when some data is missing or loading.

## Accessibility (A11y) Rules
- Every interaction must have a keyboard equivalent.
- Every interactive element must have an ARIA role and label.
- Color contrast ratios must meet WCAG 2.1 Level AA (4.5:1 for normal text).

## Output

Save UI spec to `design/specs/ui-[feature-name].md`:

\`\`\`markdown
# UI Spec: [Feature Name]

## Component Tree
[Hierarchical list of components]

## State Matrix
| Component | Default | Loading | Empty | Error | Partial |
|-----------|---------|---------|-------|-------|---------|

## Interactions
[Component] -> [Trigger] -> [Response]

## Responsive Behavior
[Breakpoint-specific layout changes]

## Accessibility
[Keyboard nav, ARIA labels, contrast requirements]

## Open Questions
[Items needing design decision]
\`\`\`

## Related Skills

- `design-review` — review implemented UI against spec
- `frontend-design` — aesthetic direction and design system
- `design-system` — reusable component library
- `review-spec` — general spec review workflow

More from tranhieutt/software_development_department

SkillDescription
agent-healthReads production/traces/agent-metrics.jsonl and displays a per-agent performance summary table for the current or a specified session. Highlights agents with high error rates or OPEN circuit breaker state.
agent-styleProvides the vendored agent-style v0.3.5 prose rule pack as a portable Claude skill. Use when installing, syncing, applying, or auditing SDD Agent-Style support in another project, or when a style-review workflow needs the bundled rules.
angular-best-practicesProvides Angular best practices for components, modules, services, and reactive patterns. Use when working with Angular TypeScript files, component templates, NgModules, RxJS observables, or when the user mentions Angular, ng, or Angular CLI.
annotateRecords unexpected API behaviors, undocumented caveats, version bugs, or non-obvious workarounds into .claude/memory/annotations.md. Use immediately when an undocumented behavior or surprising caveat is discovered during development.
aws-serverlessProvides AWS serverless architecture patterns for Lambda, API Gateway, DynamoDB, SQS, and SAM/CDK. Use when working with AWS serverless files (serverless.yml, CDK stacks) or when the user mentions Lambda, API Gateway, serverless, or AWS SAM.
backend-architectDesigns scalable backend architectures covering microservices, event-driven systems, API gateways, and data stores. Use when designing a backend system or when the user mentions backend architecture, scalability, or distributed systems.
cloud-run-puppeteerDeploys Puppeteer browser automation on Google Cloud Run with Docker. Use when running headless browser tasks on Cloud Run, or when the user mentions Cloud Run, Puppeteer, headless Chrome, or serverless browser automation.
codex-sddAdapts SDD for Codex while preserving Claude Code behavior. Use when working in Codex, setting up Codex compatibility, mapping Claude tools to Codex tools, or explaining how SDD should run outside Claude Code.
database-architectDesigns relational and NoSQL database schemas, indexing strategies, migration plans, and data modeling patterns. Use when designing a database or when the user mentions database architecture, schema design, or data modeling.
db-reviewReviews database schemas, queries, and migrations for correctness, performance, security, and best practices. Use when reviewing SQL migration files or when the user mentions database review, schema review, or query audit.