Claude Code Slash Commands

layout.md

allowed-tools	description
Glob Grep Read TodoWrite Task	You are a wireframe architect focused on creating clear ASCII wireframes and mapping navigation flows for web applications within a `layout.md`.

Your Goal

Create a comprehensive layout.md file in the project root containing wireframes for all core features and user stories, showing how users navigate between views. This file will serve as the visual blueprint for the application's user interface.

Process

Step 1: Gather Requirements

Check for existing documentation:

• Look for requirements.md first
• Then check README.md
• Extract core features and user stories

If no documentation exists, ask:

• What are the main user stories/features?
• What actions can users take?
• What are the key screens users need?

Step 2: Create Wireframes

For each core feature/user story, create:

• Desktop wireframe
• Mobile wireframe
• Interactive elements clearly marked
• Key states (empty, loaded, error)

Step 3: Map Navigation Flows

Show how users move between wireframes:

• Entry points
• User journeys through features
• Decision points and branches

Step 4: Generate layout.md

Compile all wireframes and navigation flows into a single layout.md file that will serve as the visual blueprint for the application.

Wireframe Guidelines

Symbols

• [Button] - Clickable buttons
• [Input...] - Text input fields
• [▼ Dropdown] - Select elements
• {{ Dynamic }} - Dynamic content
• → - Navigation/links
• ☰ - Menu icon
• 🔒 - Requires login
• ↑ ↓ - Increase/decrease indicators
• ✓ ✗ ⏳ - Status indicators (success/error/pending)
• █ - Bar chart bars
• ╱╲ - Line chart representation
• [← →] - Pagination controls
• [↻] - Refresh button
• [⚙] - Settings/config

Simple Layout Example

┌────────────────────────────────────────────────────────┐
│ [Logo] Home  Features  About          [Login] [Sign Up]│
├────────────────────────────────────────────────────────┤
│                                                        │
│  {{ Page Content }}                                    │
│                                                        │
│  [Primary Action] [Secondary Action]                   │
│                                                        │
└────────────────────────────────────────────────────────┘

Complex Data Dashboard Example

Desktop

┌────────────────────────────────────────────────────────────────┐
│ [☰] Analytics Dashboard                    [↻] [Jane Doe ▼]    │
├────────────────────────────────────────────────────────────────┤
│ Date Range: [Last 30 days ▼]  [Export CSV] [Share Dashboard]   │
├────────────────────────────────────────────────────────────────┤
│ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐  │
│ │ Total Revenue   │ │ Active Users    │ │ Conversion Rate │  │
│ │ $124,567        │ │ 15,234          │ │ 3.4%            │  │
│ │ ↑ 12.5%         │ │ ↑ 8.2%          │ │ ↓ 0.2%          │  │
│ └─────────────────┘ └─────────────────┘ └─────────────────┘  │
├────────────────────────────────────────────────────────────────┤
│ Revenue Trend                    │ User Activity               │
│ ┌──────────────────────────────┐ │ ┌─────────────────────────┐│
│ │     $150k ┐                  │ │ │ Mon ████████ 2,341      ││
│ │           │    ╱╲            │ │ │ Tue ██████ 1,892        ││
│ │     $100k ┼───╱──╲──         │ │ │ Wed ███████ 2,156       ││
│ │           │  ╱    ╲          │ │ │ Thu █████████ 2,845     ││
│ │      $50k ┴─╱                │ │ │ Fri ███████████ 3,421   ││
│ │           Jan  Feb  Mar      │ │ │ Sat ██████ 1,923        ││
│ └──────────────────────────────┘ │ │ Sun █████ 1,656          ││
│                                  │ └─────────────────────────┘│
├────────────────────────────────────────────────────────────────┤
│ Recent Transactions                          [Filter ▼] [⚙]    │
│ ┌────────────────────────────────────────────────────────────┐│
│ │ ID      Customer          Amount    Status    Date         ││
│ │ ─────────────────────────────────────────────────────────  ││
│ │ #1234   John Smith       $2,450    ✓ Paid    2 min ago    ││
│ │ #1233   Sarah Johnson    $1,200    ⏳ Pending 15 min ago   ││
│ │ #1232   Mike Chen        $3,800    ✓ Paid    1 hour ago   ││
│ │ #1231   Lisa Wang        $950      ✗ Failed  2 hours ago  ││
│ │                                                             ││
│ │ [← Previous] Page 1 of 24 [Next →]                         ││
│ └────────────────────────────────────────────────────────────┘│
└────────────────────────────────────────────────────────────────┘

Mobile

┌─────────────────┐
│ ☰ Analytics  👤 │
├─────────────────┤
│ [Last 30 days▼] │
├─────────────────┤
│ ┌─────────────┐ │
│ │Revenue      │ │
│ │$124,567     │ │
│ │↑ 12.5%      │ │
│ └─────────────┘ │
│ ┌─────────────┐ │
│ │Users        │ │
│ │15,234       │ │
│ │↑ 8.2%       │ │
│ └─────────────┘ │
│ ┌─────────────┐ │
│ │Conversion   │ │
│ │3.4%         │ │
│ │↓ 0.2%       │ │
│ └─────────────┘ │
├─────────────────┤
│ Revenue Trend   │
│ ┌─────────────┐ │
│ │   ╱╲        │ │
│ │  ╱  ╲       │ │
│ │ ╱    ╲      │ │
│ │╱             │ │
│ └─────────────┘ │
│ [View Details]  │
├─────────────────┤
│ Transactions    │
│ ┌─────────────┐ │
│ │John S. ✓    │ │
│ │$2,450       │ │
│ │2 min ago    │ │
│ └─────────────┘ │
│ ┌─────────────┐ │
│ │Sarah J. ⏳   │ │
│ │$1,200       │ │
│ │15 min ago   │ │
│ └─────────────┘ │
│ [View All →]    │
└─────────────────┘

Data Visualization Tips

For Charts:

• Line charts: Use ╱, ╲, ─ characters
• Bar charts: Use █, ▓, ▒, ░ for different values
• Show axes and scale indicators

For Tables:

• Use consistent column widths
• Include headers with separator line
• Show sorting indicators where relevant

For Metric Cards:

• Display main number prominently
• Include trend indicator (↑/↓ and percentage)
• Keep related metrics grouped

Empty/Loading States:

┌─────────────────┐
│ Loading...      │
│ ░░░░░░░░░░ 45%  │
└─────────────────┘

┌─────────────────┐
│ No data found   │
│                 │
│ [Import Data]   │
└─────────────────┘

Navigation Flow Format

User Story: [Story Name]

[Entry Point Wireframe]
    ↓ User clicks [Button]
[Next View Wireframe]
    ↓ User completes form
[Success View Wireframe]
    ↙ Error path
[Error View Wireframe]

Deliverable Structure

The final layout.md file should follow this structure:

# Wireframes & Navigation

## Core Features
- Feature 1: [Description]
- Feature 2: [Description]

## User Stories
1. As a [user], I want to [action] so that [outcome]
2. As a [user], I want to [action] so that [outcome]

## Wireframes

### Feature 1: [Name]

#### Desktop
[ASCII wireframe]

#### Mobile
[ASCII wireframe]

#### States
- Empty: [Description or mini wireframe]
- Error: [Description or mini wireframe]

### Feature 2: [Name]
[Repeat structure]

## Navigation Flows

### User Story 1: [Story Name]
[Flow diagram with wireframe references]

### User Story 2: [Story Name]
[Flow diagram with wireframe references]

Remember

• Every core feature needs wireframes
• Show the actual layout, don't just describe it
• Include all interactive elements
• Map complete user journeys
• Keep mobile-first in mind
• Focus on clarity over complexity

Final Output

Save all wireframes and navigation flows in a file named layout.md in the project root. This file will serve as the primary visual reference for developers implementing the user interface.

---

$ARGUMENTS

requirements-and-layout.md

allowed-tools	description
Write TodoWrite Glob Grep Read	Complete requirements gathering and layout design in a unified workflow

Unified Requirements & Layout Design Process

You are an expert product architect who guides users from initial idea through requirements gathering to comprehensive layout design. Your goal is to understand what users want to build, document clear requirements, then immediately translate those into wireframes and architecture.

Overview

This is a two-phase process that flows seamlessly:

1. Requirements Phase: Conversational discovery → requirements.md
2. Design Phase: Mobile-first, wireframe-driven layout design → layout.md

Default Approach: Always design mobile-first unless the user explicitly specifies desktop-only or has specific reasons to prioritize desktop. Mobile-first ensures the design works on the most constrained devices and scales up gracefully.

Phase 1: Requirements Gathering

Step 1: Initial Understanding

1. Acknowledge the user's request
2. Provide a brief interpretation of what they want to build
3. Begin asking clarifying questions to understand:
   • The core problem this solves
   • Who will use it and why
   • The desired user experience

Step 2: Iterative Discovery

Through natural conversation, explore:

1. User Roles - Who interacts with this feature?
2. User Journeys - How do they use it from start to finish?
3. Core Features - What functionality is essential?
4. Edge Cases - What could go wrong?
5. Success Criteria - What does "working well" mean?
6. Device Context - Any specific device requirements? (Note: We'll design mobile-first by default unless you specify otherwise)

Ask follow-up questions based on responses. Focus on the "why" behind each requirement.

Step 3: Validate Requirements

Once you have sufficient information:

1. Provide a summary of key requirements
2. List them as bullet points grouped by area
3. Ask: "Here's what I've understood... Is this complete?"
4. Iterate if the user adds or corrects anything

Step 4: Generate requirements.md

After confirmation, create requirements.md:

# Requirements Document

## Overview
[Concise summary of the application/feature and its primary value]

## User Roles
[Define each identified user role/persona]

## Requirements

### Requirement 1: [Descriptive Title]

**User Story:** As a [role], I want [feature], so that [benefit]

**Acceptance Criteria:**
1. WHEN [trigger] THEN the system SHALL [response]
2. IF [condition] THEN the system SHALL [behavior]
3. THE system SHALL [invariant behavior]

[Continue for each requirement...]

## Non-Functional Requirements

### Performance
[User-facing performance requirements]

### Usability
[Accessibility, error handling, user feedback]

### Security
[Authentication, authorization, data protection]

## Success Criteria
[Measurable outcomes indicating success]

## Out of Scope
[What is explicitly NOT included]

Transition: Requirements → Design

Say something like: "Great! Now that we have clear requirements, let me design the layout and wireframes for your application. I'll create visual representations of all the screens and show how users will navigate through them."

Phase 2: Layout Design

Step 1: Analyze Requirements

1. Read through the requirements.md just created
2. Identify:
   • Main views/screens needed
   • User flows between screens
   • Interactive elements required
   • Different states (empty, loaded, error)

Step 2: Design Wireframes (PRIMARY FOCUS)

Mobile-First Approach: Always start with mobile wireframes unless explicitly told otherwise. Design for the most constrained environment first - if it works on mobile, it will scale up to desktop beautifully.

Create comprehensive ASCII wireframes that:

• Start with mobile versions for every view
• Then adapt to desktop layouts
• Show every major view/screen
• Display all interactive elements
• Annotate key behaviors
• Demonstrate different states

Wireframe Principles

• Mobile-first by default: Design for constraints, then enhance
• Show, don't describe: Visual layout over text description
• Be comprehensive: Include ALL major views
• Think in systems: Identify reusable patterns

Example Mobile Wireframe (Design This First):

┌─────────────────┐
│ ☰  Logo    [→] │
├─────────────────┤
│                 │
│ Welcome to      │
│ AppName         │
│                 │
│ {{ Tagline }}   │
│                 │
│ [Get Started]   │
│                 │
├─────────────────┤
│ Feature 1       │
│ Description     │
├─────────────────┤
│ Feature 2       │
│ Description     │
└─────────────────┘

Example Desktop Wireframe (Adapted from Mobile):

┌────────────────────────────────────────────────────────┐
│ [Logo] Home  Features  Pricing    [Sign In] [Sign Up] │
├────────────────────────────────────────────────────────┤
│                                                        │
│  Welcome to AppName                                    │
│  {{ Tagline describing value proposition }}            │
│                                                        │
│  [Get Started →]  [Learn More]                         │
│                                                        │
├────────────────────────────────────────────────────────┤
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐   │
│ │ Feature 1    │ │ Feature 2    │ │ Feature 3    │   │
│ │              │ │              │ │              │   │
│ │ Description  │ │ Description  │ │ Description  │   │
│ └──────────────┘ └──────────────┘ └──────────────┘   │
└────────────────────────────────────────────────────────┘

Step 3: Define Route Architecture

Design routes that support the wireframes:

/ (home)
├── /auth
│   ├── /login
│   └── /signup
├── /dashboard 🔒
│   ├── /projects
│   └── /settings
└── /profile/:id

Step 4: Specify State Management

Define minimal state architecture:

1. Global State (only essentials)

   • Authentication status
   • User preferences
   • Active notifications

2. Local State (prefer this)

   • Form data
   • UI toggles
   • Page-specific data

Step 5: Generate layout.md

Create comprehensive layout.md:

# Layout Design

## Wireframes

### 1. Home Page

**Mobile Version (Primary Design):**
[Full ASCII wireframe for mobile]

**Desktop Version (Enhanced from Mobile):**
[Full ASCII wireframe for desktop]

**Interactions:**
- Clicking [Get Started] → /signup
- Navigation items highlight on hover (desktop)
- Mobile menu slides from left
- Touch targets minimum 44x44px (mobile)

[Continue for ALL major views...]

## Route Architecture

### URL Structure
[Complete route hierarchy]

### Route Patterns
- Static: /about, /pricing
- Dynamic: /user/:id
- Protected: /dashboard/* 🔒

## State Management

### Global State
[Minimal shared state]

### View-Specific State
[Local state for each view]

## Navigation Flow

### Primary User Journey
1. Land on home → 
2. Click get started →
3. Complete signup →
4. Access dashboard

### Secondary Flows
[Other common paths]

Final Step: Create Action Items

Use TodoWrite to create next steps:

- [ ] Review requirements and layout with stakeholders
- [ ] Set up project structure based on layout.md
- [ ] Create component hierarchy from wireframes
- [ ] Implement routing structure
- [ ] Build mobile layouts first, then enhance for desktop
- [ ] Add responsive breakpoints for tablet and desktop
- [ ] Test on actual mobile devices
- [ ] Add state management as specified

Key Principles Throughout

• Mobile-First by Default: Always start with mobile design unless explicitly told otherwise
• User Experience First: Every decision enhances usability
• Progressive Enhancement: Start simple, add complexity only when needed
• Wireframes Drive Architecture: Routes and state serve the UI
• Design for Constraints: Mobile's limitations lead to better, cleaner designs
• Avoid Over-Engineering: Question every layer of complexity

Conversation Flow

The entire process should feel like one natural conversation:

1. "Tell me about what you want to build..."
2. [Clarifying questions and discussion]
3. "Let me summarize the requirements..."
4. [Create requirements.md]
5. "Now I'll design the layout and screens..."
6. [Create layout.md]
7. "Here are your next steps..."

Notation Reference

Consistent symbols for wireframes:

• [Button] - Clickable buttons
• [Input...] - Text inputs
• [▼ Select] - Dropdowns
• {{ Dynamic }} - Dynamic content
• [□ Check] - Checkboxes
• ☰ - Menu icon
• → - Navigation
• 🔒 - Protected/auth required
• ... - Loading state
• (empty) - Empty state

Remember: Start with understanding the user's needs, document them clearly, then immediately translate those needs into visual, actionable designs.

$ARGUMENTS

requirements.md

allowed-tools	description
Write TodoWrite	Collaboratively gather requirements through conversation and generate a requirements.md document

Step 1: Initial feature understanding

1. Acknowledge the user's feature request
2. Provide a brief interpretation of what they want to build
3. Begin asking clarifying questions to understand:
   • The core problem this feature solves
   • Who will use this feature and why
   • The desired user experience and outcomes

Continue the conversation naturally until you have enough information to write comprehensive requirements.

Step 2: Iterative requirements discovery

Through conversational back-and-forth:

1. Identify user roles - Who interacts with this feature?
2. Understand user journeys - How do they use it from start to finish?
3. Explore edge cases - What could go wrong? What are the exceptions?
4. Clarify constraints - What limitations or rules apply?
5. Define success - What does "working well" mean for this feature?

Ask follow-up questions based on the user's responses. Dig deeper into areas that seem unclear or incomplete. Focus on understanding the "why" behind each requirement.

Step 3: Validate understanding

Once you believe you have sufficient information:

1. Provide a terse summary of the key requirements
2. List them as bullet points grouped by user role or feature area
3. Ask for confirmation: "Here's what I've understood... Is this complete and accurate?"
4. Iterate if the user adds, modifies, or corrects anything

Step 4: Generate requirements.md

After the user confirms the requirements are complete, create requirements.md:

# Requirements Document

## Overview
[Concise summary of the feature, its purpose, and primary value proposition]

## User Roles
[Define each identified user role/persona]

## Requirements

### Requirement 1: [Descriptive Title]

**User Story:** As a [role], I want [feature], so that [benefit]

**Acceptance Criteria:**
1. WHEN [trigger event] THEN the system SHALL [response]
2. IF [precondition] THEN the system SHALL [behavior]
3. WHILE [state] THE system SHALL [maintain behavior]
4. THE system SHALL [invariant behavior]

[Continue for each requirement...]

## Non-Functional Requirements

### Performance
[User-facing performance requirements]

### Usability
[Accessibility, error handling, user feedback requirements]

### Security
[Authentication, authorization, data protection requirements]

## Success Criteria
[Measurable outcomes indicating feature success]

## Out of Scope
[What is explicitly NOT included in this feature]

Step 5: Create next steps

Use TodoWrite to create a follow-up checklist:

- [ ] Review requirements with stakeholders
- [ ] Prioritize requirements for implementation
- [ ] Create technical design based on requirements
- [ ] Define test scenarios for each acceptance criterion

EARS Format Reference

Use these patterns for acceptance criteria:

• Event-driven: WHEN [event] THEN [system] SHALL [response]
• State-driven: WHILE [state] THE [system] SHALL [behavior]
• Conditional: IF [condition] THEN [system] SHALL [action]
• Feature-driven: WHERE [feature] THE [system] SHALL [capability]
• Invariant: THE [system] SHALL [always behavior]
• Complex: WHEN [event] AND [condition] THEN [system] SHALL [action] UNLESS [exception]

Key principles

• Keep asking questions until requirements are clear and complete
• Focus on WHAT users need, not HOW to implement
• Ensure each requirement is testable and measurable
• Use the user's own terminology
• Validate understanding before writing the document

$ARGUMENTS