Name: create-design-doc
Author: wghglory

Prompt file imported from wghglory/ngx-lift-workspace (.cursor/commands/create-design-doc.md). Copyright stays with the author.

Create UI Design Document

Generates UI design documents from requirements. Analyzes codebase, gathers context, and produces detailed design + overview following templates.

Input

Feature Name: [FEATURE_NAME] (kebab-case)
Requirements: Path to design/requirements/[FILE].md, PRD path, or inline description
JIRA ID: [JIRA-ID] (optional)
Stakeholders: List (optional)

Steps

Validate & Setup
- Verify feature name format (kebab-case)
- Check requirement file exists or prompt for inline
- Check if design doc exists (ask: update/new version/cancel)
- Load templates: design-template.md, design-overview-template.md
- Set output paths: [FEATURE_NAME].md, [FEATURE_NAME]-overview.md
Gather Requirements
- Read requirement file/PRD/inline description
- Extract: problem statement, user stories, acceptance criteria, user roles, mockups
- Identify: use cases, success criteria, dependencies, constraints
Analyze Codebase
- Search for similar features/components
- Review tsconfig.base.json for available libraries
- Check apps/ and libs/ structure
- Read rules: .cursor/rules/nx.mdc, .cursor/rules/angular.mdc, .cursor/rules/clarity.mdc, .cursor/rules/rxjs.mdc, .cursor/rules/general.mdc
- Identify reusable components (forms, grids, modals, wizards)
Design Architecture
- Components: List new components (name, purpose, inputs/outputs, state approach)
- Services: Data access, business logic, state (NGXS), utilities
- Data Models: Request/response, view models, form models, enums
- State Management: Component-local (signals) vs feature (NGXS) vs global
- Routing: Paths, guards, lazy loading, navigation flow
- API Integration: Endpoints, request/response, auth, error handling, mocks
Design Patterns & Reuse
- Find similar implementations in codebase
- Map requirements to Clarity components
- Document accessibility considerations per UI element
Estimate Complexity
- Complexity: Low (single component) / Moderate (multiple) / High (complex workflows)
- Breakdown: Components, services, stores, APIs, tests
- SWAG:
  - Design & Prototyping: X-Y weeks
  - Development: X-Y weeks
  - Testing & Deployment: X-Y weeks
  - Total: X-Y weeks (Z months)
- Team Size: Number and skill levels needed
Dependencies & Risks
- Critical Dependencies: Table with owner, status, risk level, mitigation
- Technical Risks: Impact, probability, mitigation
- Scope Risks: Out-of-scope items that might creep
Generate Design Documents

Detailed Design ([FEATURE_NAME].md):
- Header (title, JIRA, stakeholders)
- Problem Statement, Glossary, Goals, Non-Goals
- Big Picture (release scope, user flow, screens)
- Diagram/Mockup (ASCII art, layouts, navigation)
  - Formatting Requirements: See ASCII Art Formatting Requirements section
- New Design Elements (components, patterns, accessibility)
- New Requirements from UI Platform
- DSM UI Integration (build, CI/CD, scalability, security, lifecycle, errors, VCF)
- Implementation Plan (phases, order, testing)
- API Contracts (endpoints, examples, errors, mocks)
- State Management Details (NGXS state, actions, selectors, effects)
- Component Specifications (purpose, inputs/outputs, state, accessibility, testing)
- Localization Strategy (i18n keys, translation files)
- Testing Strategy (unit, E2E, accessibility, performance)
- Success Criteria (functional, quality, performance, accessibility)
Overview ([FEATURE_NAME]-overview.md):
- Header (tech lead, UI dev, eng mgr, VGL)
- Overview (2-3 paragraph summary)
- High-Level Requirements Table (role, use case, UI, description)
- Mockup/Screenshot reference
  - Formatting Requirements: See ASCII Art Formatting Requirements section
- SWAG (complexity, team size, time estimates, dependencies/risks summary)
- Implementation Status (if work started)
- Success Criteria summary
- Related Documentation links
Review & Validate
- Completeness: All template sections filled, no placeholders
- Technical Accuracy: Component names, paths, imports, Clarity components, state management
- Architectural Alignment: Nx boundaries, standalone, OnPush, signals, NGXS, Transloco, accessibility
- Quality: Measurable goals, success criteria, testing strategy, realistic estimates
- Formatting: All ASCII art diagrams, flow charts, and mockups must follow ASCII Art Formatting Requirements
Generate Output
- Write design documents to design/
- Provide summary report with documents, architecture, dependencies, next steps

ASCII Art Formatting Requirements

All ASCII art boxes, diagrams, flow charts, and mockups in design documents must follow these formatting requirements:

Box Alignment: All vertical borders (│) must align perfectly - use fixed-width boxes with consistent character count
Right Border: Right-side borders (│┐┘) must align vertically in the same column
Left Border: Left-side borders (│┌└) must align vertically in the same column
Label Alignment: Left-side labels must use consistent spacing after colons (e.g., "Label: " with fixed width for alignment)
Input Fields: Input fields [________________] must be aligned within their sections with consistent spacing
Buttons/Actions: Buttons and actions aligned to the right must start at the same column position
Box Characters: Use consistent box-drawing characters (┌─┐│├┤└┘) - never mix with ASCII characters
Spacing: Use consistent spacing (2-4 spaces) for indentation and padding within boxes
Flow Charts: Arrows (→ ↓ ↑ ←) and connectors must align with box borders
Multi-line Content: Multi-line text within boxes must maintain consistent left padding
Radio/Checkboxes: Radio buttons (○ ●) and checkboxes must be indented consistently (2-4 spaces)

Important Notes

Do NOT:

Generate code (design only)
Assume backend APIs without evidence
Invent requirements
Skip codebase analysis
Use generic examples

DO:

Analyze codebase for reusable patterns
Follow all architectural rules
Provide specific, actionable recommendations
Identify concrete dependencies and risks
Give realistic time estimates
Reference existing similar features
Consider accessibility and i18n from start

Design Quality Standards

Specific: Reference actual components/services in codebase
Actionable: Engineers can implement from design
Realistic: Time estimates account for testing/polish/bugs
Complete: All aspects covered (UI, state, API, testing, i18n, a11y)
Aligned: Follows all architectural rules

Related Rules

.cursor/rules/nx.mdc - Module boundaries and Nx workspace
.cursor/rules/general.mdc - Core standards and service patterns
.cursor/rules/angular.mdc - Component patterns and Angular
.cursor/rules/clarity.mdc - UI components and Clarity Design System
.cursor/rules/rxjs.mdc - RxJS patterns and observable management
.cursor/rules/testing.mdc - Testing approach with Vitest and Playwright

Install create-design-doc and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Create UI Design Document Generates UI design documents from requirements. Analyzes codebase, gathers context, and produces detailed design + overview following templates. ## Input - **Feature Name**: `[FEATURE_NAME]` (kebab-case) - **Requirements**: Path to `design/requirements/[FILE].md`, PRD path, or inline description - **JIRA ID**: `[JIRA-ID]` (optional) - **Stakeholders**: List (optional) ## Steps 1. **Validate & Setup** - Verify feature name format (kebab-case) - Check requirement file exists or prompt for inline - Check if design doc exists (ask: update/new version/cancel) - Load templates: `design-template.md`, `design-overview-template.md` - Set output paths: `[FEATURE_NAME].md`, `[FEATURE_NAME]-overview.md` 2. **Gather Requirements** - Read requirement file/PRD/inline description - Extract: problem statement, user stories, acceptance criteria, user roles, mockups - Identify: use cases, success criteria, dependencies, constraints 3. **Analyze Codebase** - Search for similar features/components - Review `tsconfig.base.json` for available libraries - Check `apps/` and `libs/` structure - Read rules: `.cursor/rules/nx.mdc`, `.cursor/rules/angular.mdc`, `.cursor/rules/clarity.mdc`, `.cursor/rules/rxjs.mdc`, `.cursor/rules/general.mdc` - Identify reusable components (forms, grids, modals, wizards) 4. **Design Architecture** - **Components**: List new components (name, purpose, inputs/outputs, state approach) - **Services**: Data access, business logic, state (NGXS), utilities - **Data Models**: Request/response, view models, form models, enums - **State Management**: Component-local (signals) vs feature (NGXS) vs global - **Routing**: Paths, guards, lazy loading, navigation flow - **API Integration**: Endpoints, request/response, auth, error handling, mocks 5. **Design Patterns & Reuse** - Find similar implementations in codebase - Map requirements to Clarity components - Document accessibility considerations per UI element 6. **Estimate Complexity** - **Complexity**: Low (single component) / Moderate (multiple) / High (complex workflows) - **Breakdown**: Components, services, stores, APIs, tests - **SWAG**: - Design & Prototyping: X-Y weeks - Development: X-Y weeks - Testing & Deployment: X-Y weeks - Total: X-Y weeks (Z months) - **Team Size**: Number and skill levels needed 7. **Dependencies & Risks** - **Critical Dependencies**: Table with owner, status, risk level, mitigation - **Technical Risks**: Impact, probability, mitigation - **Scope Risks**: Out-of-scope items that might creep 8. **Generate Design Documents** **Detailed Design** (`[FEATURE_NAME].md`): - Header (title, JIRA, stakeholders) - Problem Statement, Glossary, Goals, Non-Goals - Big Picture (release scope, user flow, screens) - Diagram/Mockup (ASCII art, layouts, navigation) - **Formatting Requirements**: See [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements) section - New Design Elements (components, patterns, accessibility) - New Requirements from UI Platform - DSM UI Integration (build, CI/CD, scalability, security, lifecycle, errors, VCF) - Implementation Plan (phases, order, testing) - API Contracts (endpoints, examples, errors, mocks) - State Management Details (NGXS state, actions, selectors, effects) - Component Specifications (purpose, inputs/outputs, state, accessibility, testing) - Localization Strategy (i18n keys, translation files) - Testing Strategy (unit, E2E, accessibility, performance) - Success Criteria (functional, quality, performance, accessibility) **Overview** (`[FEATURE_NAME]-overview.md`): - Header (tech lead, UI dev, eng mgr, VGL) - Overview (2-3 paragraph summary) - High-Level Requirements Table (role, use case, UI, description) - Mockup/Screenshot reference - **Formatting Requirements**: See [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements) section - SWAG (complexity, team size, time estimates, dependencies/risks summary) - Implementation Status (if work started) - Success Criteria summary - Related Documentation links 9. **Review & Validate** - **Completeness**: All template sections filled, no placeholders - **Technical Accuracy**: Component names, paths, imports, Clarity components, state management - **Architectural Alignment**: Nx boundaries, standalone, OnPush, signals, NGXS, Transloco, accessibility - **Quality**: Measurable goals, success criteria, testing strategy, realistic estimates - **Formatting**: All ASCII art diagrams, flow charts, and mockups must follow [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements) 10. **Generate Output** - Write design documents to `design/` - Provide summary report with documents, architecture, dependencies, next steps ## ASCII Art Formatting Requirements All ASCII art boxes, diagrams, flow charts, and mockups in design documents must follow these formatting requirements: - **Box Alignment**: All vertical borders (│) must align perfectly - use fixed-width boxes with consistent character count - **Right Border**: Right-side borders (│┐┘) must align vertically in the same column - **Left Border**: Left-side borders (│┌└) must align vertically in the same column - **Label Alignment**: Left-side labels must use consistent spacing after colons (e.g., "Label: " with fixed width for alignment) - **Input Fields**: Input fields `[________________]` must be aligned within their sections with consistent spacing - **Buttons/Actions**: Buttons and actions aligned to the right must start at the same column position - **Box Characters**: Use consistent box-drawing characters (┌─┐│├┤└┘) - never mix with ASCII characters - **Spacing**: Use consistent spacing (2-4 spaces) for indentation and padding within boxes - **Flow Charts**: Arrows (→ ↓ ↑ ←) and connectors must align with box borders - **Multi-line Content**: Multi-line text within boxes must maintain consistent left padding - **Radio/Checkboxes**: Radio buttons (○ ●) and checkboxes must be indented consistently (2-4 spaces) ## Important Notes **Do NOT:** - Generate code (design only) - Assume backend APIs without evidence - Invent requirements - Skip codebase analysis - Use generic examples **DO:** - Analyze codebase for reusable patterns - Follow all architectural rules - Provide specific, actionable recommendations - Identify concrete dependencies and risks - Give realistic time estimates - Reference existing similar features - Consider accessibility and i18n from start ## Design Quality Standards - **Specific**: Reference actual components/services in codebase - **Actionable**: Engineers can implement from design - **Realistic**: Time estimates account for testing/polish/bugs - **Complete**: All aspects covered (UI, state, API, testing, i18n, a11y) - **Aligned**: Follows all architectural rules ## Related Rules - `.cursor/rules/nx.mdc` - Module boundaries and Nx workspace - `.cursor/rules/general.mdc` - Core standards and service patterns - `.cursor/rules/angular.mdc` - Component patterns and Angular - `.cursor/rules/clarity.mdc` - UI components and Clarity Design System - `.cursor/rules/rxjs.mdc` - RxJS patterns and observable management - `.cursor/rules/testing.mdc` - Testing approach with Vitest and Playwright

{ "prompt": "# Create UI Design Document\n\nGenerates UI design documents from requirements. Analyzes codebase, gathers context, and produces detailed design +\noverview following templates.\n\n## Input\n\n- **Feature Name**: `[FEATURE_NAME]` (kebab-case)\n- **Requirements**: Path to `design/requirements/[FILE].md`, PRD path, or inline description\n- **JIRA ID**: `[JIRA-ID]` (optional)\n- **Stakeholders**: List (optional)\n\n## Steps\n\n1. **Validate & Setup**\n - Verify feature name format (kebab-case)\n - Check requirement file exists or prompt for inline\n - Check if design doc exists (ask: update/new version/cancel)\n - Load templates: `design-template.md`, `design-overview-template.md`\n - Set output paths: `[FEATURE_NAME].md`, `[FEATURE_NAME]-overview.md`\n\n2. **Gather Requirements**\n - Read requirement file/PRD/inline description\n - Extract: problem statement, user stories, acceptance criteria, user roles, mockups\n - Identify: use cases, success criteria, dependencies, constraints\n\n3. **Analyze Codebase**\n - Search for similar features/components\n - Review `tsconfig.base.json` for available libraries\n - Check `apps/` and `libs/` structure\n - Read rules: `.cursor/rules/nx.mdc`, `.cursor/rules/angular.mdc`, `.cursor/rules/clarity.mdc`,\n `.cursor/rules/rxjs.mdc`, `.cursor/rules/general.mdc`\n - Identify reusable components (forms, grids, modals, wizards)\n\n4. **Design Architecture**\n - **Components**: List new components (name, purpose, inputs/outputs, state approach)\n - **Services**: Data access, business logic, state (NGXS), utilities\n - **Data Models**: Request/response, view models, form models, enums\n - **State Management**: Component-local (signals) vs feature (NGXS) vs global\n - **Routing**: Paths, guards, lazy loading, navigation flow\n - **API Integration**: Endpoints, request/response, auth, error handling, mocks\n\n5. **Design Patterns & Reuse**\n - Find similar implementations in codebase\n - Map requirements to Clarity components\n - Document accessibility considerations per UI element\n\n6. **Estimate Complexity**\n - **Complexity**: Low (single component) / Moderate (multiple) / High (complex workflows)\n - **Breakdown**: Components, services, stores, APIs, tests\n - **SWAG**:\n - Design & Prototyping: X-Y weeks\n - Development: X-Y weeks\n - Testing & Deployment: X-Y weeks\n - Total: X-Y weeks (Z months)\n - **Team Size**: Number and skill levels needed\n\n7. **Dependencies & Risks**\n - **Critical Dependencies**: Table with owner, status, risk level, mitigation\n - **Technical Risks**: Impact, probability, mitigation\n - **Scope Risks**: Out-of-scope items that might creep\n\n8. **Generate Design Documents**\n\n **Detailed Design** (`[FEATURE_NAME].md`):\n - Header (title, JIRA, stakeholders)\n - Problem Statement, Glossary, Goals, Non-Goals\n - Big Picture (release scope, user flow, screens)\n - Diagram/Mockup (ASCII art, layouts, navigation)\n - **Formatting Requirements**: See [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements) section\n - New Design Elements (components, patterns, accessibility)\n - New Requirements from UI Platform\n - DSM UI Integration (build, CI/CD, scalability, security, lifecycle, errors, VCF)\n - Implementation Plan (phases, order, testing)\n - API Contracts (endpoints, examples, errors, mocks)\n - State Management Details (NGXS state, actions, selectors, effects)\n - Component Specifications (purpose, inputs/outputs, state, accessibility, testing)\n - Localization Strategy (i18n keys, translation files)\n - Testing Strategy (unit, E2E, accessibility, performance)\n - Success Criteria (functional, quality, performance, accessibility)\n\n **Overview** (`[FEATURE_NAME]-overview.md`):\n - Header (tech lead, UI dev, eng mgr, VGL)\n - Overview (2-3 paragraph summary)\n - High-Level Requirements Table (role, use case, UI, description)\n - Mockup/Screenshot reference\n - **Formatting Requirements**: See [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements) section\n - SWAG (complexity, team size, time estimates, dependencies/risks summary)\n - Implementation Status (if work started)\n - Success Criteria summary\n - Related Documentation links\n\n9. **Review & Validate**\n - **Completeness**: All template sections filled, no placeholders\n - **Technical Accuracy**: Component names, paths, imports, Clarity components, state management\n - **Architectural Alignment**: Nx boundaries, standalone, OnPush, signals, NGXS, Transloco, accessibility\n - **Quality**: Measurable goals, success criteria, testing strategy, realistic estimates\n - **Formatting**: All ASCII art diagrams, flow charts, and mockups must follow\n [ASCII Art Formatting Requirements](#ascii-art-formatting-requirements)\n\n10. **Generate Output**\n - Write design documents to `design/`\n - Provide summary report with documents, architecture, dependencies, next steps\n\n## ASCII Art Formatting Requirements\n\nAll ASCII art boxes, diagrams, flow charts, and mockups in design documents must follow these formatting requirements:\n\n- **Box Alignment**: All vertical borders (│) must align perfectly - use fixed-width boxes with consistent character\n count\n- **Right Border**: Right-side borders (│┐┘) must align vertically in the same column\n- **Left Border**: Left-side borders (│┌└) must align vertically in the same column\n- **Label Alignment**: Left-side labels must use consistent spacing after colons (e.g., \"Label: \" with fixed width for\n alignment)\n- **Input Fields**: Input fields `[________________]` must be aligned within their sections with consistent spacing\n- **Buttons/Actions**: Buttons and actions aligned to the right must start at the same column position\n- **Box Characters**: Use consistent box-drawing characters (┌─┐│├┤└┘) - never mix with ASCII characters\n- **Spacing**: Use consistent spacing (2-4 spaces) for indentation and padding within boxes\n- **Flow Charts**: Arrows (→ ↓ ↑ ←) and connectors must align with box borders\n- **Multi-line Content**: Multi-line text within boxes must maintain consistent left padding\n- **Radio/Checkboxes**: Radio buttons (○ ●) and checkboxes must be indented consistently (2-4 spaces)\n\n## Important Notes\n\n**Do NOT:**\n\n- Generate code (design only)\n- Assume backend APIs without evidence\n- Invent requirements\n- Skip codebase analysis\n- Use generic examples\n\n**DO:**\n\n- Analyze codebase for reusable patterns\n- Follow all architectural rules\n- Provide specific, actionable recommendations\n- Identify concrete dependencies and risks\n- Give realistic time estimates\n- Reference existing similar features\n- Consider accessibility and i18n from start\n\n## Design Quality Standards\n\n- **Specific**: Reference actual components/services in codebase\n- **Actionable**: Engineers can implement from design\n- **Realistic**: Time estimates account for testing/polish/bugs\n- **Complete**: All aspects covered (UI, state, API, testing, i18n, a11y)\n- **Aligned**: Follows all architectural rules\n\n## Related Rules\n\n- `.cursor/rules/nx.mdc` - Module boundaries and Nx workspace\n- `.cursor/rules/general.mdc` - Core standards and service patterns\n- `.cursor/rules/angular.mdc` - Component patterns and Angular\n- `.cursor/rules/clarity.mdc` - UI components and Clarity Design System\n- `.cursor/rules/rxjs.mdc` - RxJS patterns and observable management\n- `.cursor/rules/testing.mdc` - Testing approach with Vitest and Playwright", "variables": [], "notes": "Generates UI design documents from requirements. Analyzes codebase, gathers context, and produces detailed design + overview following templates.", "metadata": { "source": { "provider": "github-cursor-commands", "repository": "https://github.com/wghglory/ngx-lift-workspace", "path": ".cursor/commands/create-design-doc.md", "ref": "2d7e77cc64bc938d35adad34a07ae2dc2bd162b4", "url": "https://github.com/wghglory/ngx-lift-workspace/blob/2d7e77cc64bc938d35adad34a07ae2dc2bd162b4/.cursor/commands/create-design-doc.md", "key": "wghglory/ngx-lift-workspace/.cursor/commands/create-design-doc.md" } } }

create-design-doc

About

Create UI Design Document

Input

Steps

ASCII Art Formatting Requirements

Important Notes

Design Quality Standards

Related Rules

Install create-design-doc and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews