ccstart 2.0.1 → 2.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -1
- package/template/claude/CLAUDE.md +14 -1
- package/template/claude/agents/backend.md +0 -1
- package/template/claude/agents/blockchain.md +0 -1
- package/template/claude/agents/checker.md +0 -1
- package/template/claude/agents/coder.md +0 -1
- package/template/claude/agents/frontend.md +0 -1
- package/template/claude/agents/planner.md +0 -1
- package/template/claude/agents/researcher.md +0 -1
- package/template/claude/agents/shadcn.md +0 -1
- package/template/claude/skills/commit/SKILL.md +97 -0
- package/template/claude/skills/create-pr/SKILL.md +84 -0
- package/template/claude/skills/create-ticket/SKILL.md +102 -0
- package/template/claude/skills/design-feature/SKILL.md +111 -0
- package/template/claude/skills/design-principles/skill.md +237 -0
- package/template/claude/skills/skill-creator/SKILL.md +356 -0
- package/template/.claude/commands/README.md +0 -70
- package/template/.claude/commands/update-claude-md.md +0 -23
- package/template/.claude/hooks/README.md +0 -65
- package/template/.claude/hooks/workflow-detector.sh +0 -61
- package/template/.claude/settings.json.example +0 -18
- package/template/claude/plans/README.md +0 -53
package/package.json
CHANGED
|
@@ -140,8 +140,21 @@ After adding the agents you want to in `./claude/agents` folder, setup the workf
|
|
|
140
140
|
## Custom Commands
|
|
141
141
|
|
|
142
142
|
Custom slash commands are available in `.claude/commands/`:
|
|
143
|
+
|
|
144
|
+
**Git Workflow:**
|
|
145
|
+
- **/commit** - Generate and execute git commits following conventional commit format
|
|
146
|
+
- **/create-pr** - Create GitHub pull requests with structured descriptions
|
|
147
|
+
- **/review-pr** - Review pull requests with systematic quality checks
|
|
148
|
+
|
|
149
|
+
**Project Management:**
|
|
150
|
+
- **/create-ticket** - Create task tickets with proper numbering and update ticket-list.md
|
|
151
|
+
- **/design-feature** - Guide feature development through requirements and design phases
|
|
152
|
+
- **/create-plan** - Create timestamped planning documents
|
|
153
|
+
|
|
154
|
+
**Utilities:**
|
|
143
155
|
- **/update-claude-md** - Automatically updates this file with project-specific information
|
|
144
|
-
|
|
156
|
+
|
|
157
|
+
See `.claude/commands/README.md` for creating your own commands
|
|
145
158
|
|
|
146
159
|
## Tickets
|
|
147
160
|
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: backend
|
|
3
3
|
description: Backend development specialist. Use PROACTIVELY for API design, database architecture, authentication, microservices, and server-side optimization. Invoke when building APIs, services, or backend infrastructure.
|
|
4
|
-
tools: Read, Write, Edit, Grep, Glob, Bash, WebSearch, WebFetch
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a senior backend engineer with expertise in server-side technologies and distributed systems. Your role is to design and implement scalable, secure, and performant backend services.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: blockchain
|
|
3
3
|
description: Blockchain and Web3 specialist. Use PROACTIVELY for smart contract development, DeFi protocols, blockchain architecture, security audits, and Web3 integrations. Invoke when working with Ethereum, Solana, or other blockchain platforms.
|
|
4
|
-
tools: Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Bash
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a blockchain and Web3 expert specializing in smart contract development, decentralized applications, and blockchain architecture. Your expertise spans multiple blockchain platforms and the entire Web3 ecosystem.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: checker
|
|
3
3
|
description: Quality assurance and code review specialist. Use PROACTIVELY for testing, debugging, security analysis, and code quality verification. Invoke after code implementation or when you need thorough quality validation.
|
|
4
|
-
tools: Read, Grep, Glob, Bash, TodoRead
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a senior quality assurance engineer and security specialist. Your role is to thoroughly review, test, and validate code and systems to ensure they meet quality, security, and performance standards.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: coder
|
|
3
3
|
description: Expert software developer and implementation specialist. Use PROACTIVELY for writing, refactoring, and optimizing code. Invoke when you need to implement features, fix bugs, or improve code quality.
|
|
4
|
-
tools: Read, Edit, Write, Grep, Glob, Bash, TodoRead
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a senior software engineer with expertise across multiple programming languages and frameworks. Your role is to implement high-quality, maintainable code based on specifications and plans.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: frontend
|
|
3
3
|
description: Frontend development specialist. Use PROACTIVELY for UI/UX implementation, responsive design, state management, and frontend performance optimization. Invoke when building user interfaces, SPAs, or frontend features.
|
|
4
|
-
tools: Read, Write, Edit, Grep, Glob, Bash, WebSearch, WebFetch
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a senior frontend engineer with expertise in modern web technologies and user interface development. Your role is to create beautiful, performant, and accessible user interfaces.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: planner
|
|
3
3
|
description: Strategic planning specialist. Use PROACTIVELY for breaking down complex problems, creating implementation roadmaps, and architectural planning. Invoke when you need to plan a feature, design system architecture, or break down large tasks.
|
|
4
|
-
tools: Read, Grep, Glob, TodoWrite
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a strategic planning and system architecture expert. Your primary role is to analyze requirements, break down complex problems into manageable tasks, and create clear implementation roadmaps.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: researcher
|
|
3
3
|
description: Research and investigation specialist for both online sources and local codebases. Use PROACTIVELY for researching documentation, APIs, best practices online AND deep-diving into local code. Invoke when you need comprehensive information from multiple sources.
|
|
4
|
-
tools: Read, Grep, Glob, LS, WebSearch, WebFetch
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a research and investigation specialist with expertise in both online research and local codebase analysis. Your primary role is to gather comprehensive information from all available sources to support informed decision-making.
|
|
@@ -1,7 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: shadcn
|
|
3
3
|
description: shadcn/ui component library specialist. Use PROACTIVELY for building beautiful, accessible React interfaces with shadcn/ui, Radix UI, and Tailwind CSS. Invoke when implementing modern UI components with best-in-class accessibility.
|
|
4
|
-
tools: Read, Write, Edit, Grep, Glob, Bash, WebSearch, WebFetch
|
|
5
4
|
---
|
|
6
5
|
|
|
7
6
|
You are a shadcn/ui specialist with deep expertise in building modern React interfaces using the shadcn/ui component library, Radix UI primitives, and Tailwind CSS. Your role is to create beautiful, accessible, and customizable user interfaces.
|
|
@@ -0,0 +1,97 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: commit
|
|
3
|
+
description: Generate and execute git commits following conventional commit format. Use when the user wants to commit changes, create a commit, or says "/commit". Analyzes staged/unstaged changes and creates properly formatted commit messages with type, optional scope, and descriptive subject.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Commit Skill
|
|
7
|
+
|
|
8
|
+
Generate conventional commit messages and execute commits automatically.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
1. Run `git status` (never use `-uall` flag) and `git diff` to analyze changes
|
|
13
|
+
2. Run `git log --oneline -5` to see recent commit style
|
|
14
|
+
3. Determine the appropriate commit type and scope from the changes
|
|
15
|
+
4. Stage all relevant changes with `git add`
|
|
16
|
+
5. Create the commit with a properly formatted message
|
|
17
|
+
|
|
18
|
+
## Commit Format
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
<type>(<scope>): <subject>
|
|
22
|
+
|
|
23
|
+
<body>
|
|
24
|
+
|
|
25
|
+
<footer>
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### Types
|
|
29
|
+
|
|
30
|
+
| Type | Use for |
|
|
31
|
+
|------|---------|
|
|
32
|
+
| `feat` | New feature or functionality |
|
|
33
|
+
| `fix` | Bug fix |
|
|
34
|
+
| `docs` | Documentation only |
|
|
35
|
+
| `style` | Formatting, semicolons, no code change |
|
|
36
|
+
| `refactor` | Code change that neither fixes nor adds |
|
|
37
|
+
| `test` | Adding or modifying tests |
|
|
38
|
+
| `chore` | Maintenance, deps, build process |
|
|
39
|
+
| `perf` | Performance improvements |
|
|
40
|
+
|
|
41
|
+
### Scope
|
|
42
|
+
|
|
43
|
+
Optional. Include when it adds clarity about what area is affected:
|
|
44
|
+
- `feat(auth):` - authentication related
|
|
45
|
+
- `fix(api):` - API related
|
|
46
|
+
- `docs:` - scope omitted when obvious
|
|
47
|
+
|
|
48
|
+
### Subject
|
|
49
|
+
|
|
50
|
+
- Imperative mood ("add" not "added" or "adds")
|
|
51
|
+
- No period at end
|
|
52
|
+
- Max 50 characters
|
|
53
|
+
- Focus on the "why" not the "what"
|
|
54
|
+
|
|
55
|
+
### Body (optional)
|
|
56
|
+
|
|
57
|
+
Add when the subject alone doesn't fully explain the change. Wrap at 72 characters.
|
|
58
|
+
|
|
59
|
+
### Footer (optional)
|
|
60
|
+
|
|
61
|
+
- Breaking changes: `BREAKING CHANGE: description`
|
|
62
|
+
- Issue references: `Closes #123`
|
|
63
|
+
|
|
64
|
+
## Commit Message Construction
|
|
65
|
+
|
|
66
|
+
Use a HEREDOC for proper formatting:
|
|
67
|
+
|
|
68
|
+
```bash
|
|
69
|
+
git commit -m "$(cat <<'EOF'
|
|
70
|
+
<type>(<scope>): <subject>
|
|
71
|
+
|
|
72
|
+
<body if needed>
|
|
73
|
+
EOF
|
|
74
|
+
)"
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## Examples
|
|
78
|
+
|
|
79
|
+
Single file change:
|
|
80
|
+
```
|
|
81
|
+
fix(auth): handle expired tokens gracefully
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Multiple related changes:
|
|
85
|
+
```
|
|
86
|
+
feat(api): add email notifications for shipped orders
|
|
87
|
+
|
|
88
|
+
Send confirmation email when order status changes to shipped.
|
|
89
|
+
Includes tracking number and estimated delivery date.
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
Breaking change:
|
|
93
|
+
```
|
|
94
|
+
refactor(config)!: migrate to environment-based configuration
|
|
95
|
+
|
|
96
|
+
BREAKING CHANGE: config.json no longer supported, use .env files
|
|
97
|
+
```
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create-pr
|
|
3
|
+
description: Create GitHub pull requests with properly structured descriptions. Use when the user explicitly asks to create a PR, open a pull request, or says "/create-pr". Analyzes commits and changes to generate clear PR descriptions with summary, changes list, and UI changes when applicable.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Create PR Skill
|
|
7
|
+
|
|
8
|
+
Create GitHub pull requests with structured descriptions.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
1. Run `git status` to check for uncommitted changes and remote tracking
|
|
13
|
+
2. Run `git diff <base-branch>...HEAD` to see all changes since branching
|
|
14
|
+
3. Run `git log <base-branch>..HEAD --oneline` to see all commits
|
|
15
|
+
4. Analyze changes to draft PR title and description
|
|
16
|
+
5. Push branch if needed with `git push -u origin <branch>`
|
|
17
|
+
6. Create PR with `gh pr create`
|
|
18
|
+
|
|
19
|
+
## PR Format
|
|
20
|
+
|
|
21
|
+
**Title:** Use conventional commit format: `<type>(<scope>): <subject>`
|
|
22
|
+
|
|
23
|
+
**Body:**
|
|
24
|
+
```markdown
|
|
25
|
+
## Summary
|
|
26
|
+
<What this PR does and why - 1-3 sentences>
|
|
27
|
+
|
|
28
|
+
## Changes
|
|
29
|
+
- <Specific change 1>
|
|
30
|
+
- <Specific change 2>
|
|
31
|
+
- <Specific change 3>
|
|
32
|
+
|
|
33
|
+
## UI Changes
|
|
34
|
+
<Text description of visual/layout changes - omit section if no UI changes>
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
## Creating the PR
|
|
38
|
+
|
|
39
|
+
Use HEREDOC for proper formatting:
|
|
40
|
+
|
|
41
|
+
```bash
|
|
42
|
+
gh pr create --title "<type>(<scope>): <subject>" --body "$(cat <<'EOF'
|
|
43
|
+
## Summary
|
|
44
|
+
<description>
|
|
45
|
+
|
|
46
|
+
## Changes
|
|
47
|
+
- <change 1>
|
|
48
|
+
- <change 2>
|
|
49
|
+
EOF
|
|
50
|
+
)"
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## Examples
|
|
54
|
+
|
|
55
|
+
**Backend PR:**
|
|
56
|
+
```markdown
|
|
57
|
+
## Summary
|
|
58
|
+
Add email notifications when orders are shipped. Customers receive
|
|
59
|
+
an automated email with tracking information when their order status
|
|
60
|
+
changes to "shipped".
|
|
61
|
+
|
|
62
|
+
## Changes
|
|
63
|
+
- Add `ShippingNotificationService` to handle email dispatch
|
|
64
|
+
- Integrate with SendGrid API for email delivery
|
|
65
|
+
- Add email template for shipping confirmation
|
|
66
|
+
- Update `OrderController` to trigger notification on status change
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**PR with UI changes:**
|
|
70
|
+
```markdown
|
|
71
|
+
## Summary
|
|
72
|
+
Add dark mode toggle to application settings.
|
|
73
|
+
|
|
74
|
+
## Changes
|
|
75
|
+
- Add `ThemeContext` for managing theme state
|
|
76
|
+
- Create `DarkModeToggle` component in settings page
|
|
77
|
+
- Update CSS variables for dark theme colors
|
|
78
|
+
- Persist theme preference to localStorage
|
|
79
|
+
|
|
80
|
+
## UI Changes
|
|
81
|
+
- New toggle switch in Settings > Appearance section
|
|
82
|
+
- Toggle positioned right-aligned with "Dark Mode" label on left
|
|
83
|
+
- Switch uses primary brand color when enabled
|
|
84
|
+
```
|
|
@@ -0,0 +1,102 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: create-ticket
|
|
3
|
+
description: Create task tickets with proper numbering, template structure, and ticket-list.md updates. Use when the user wants to create a ticket, add a task, or says "/create-ticket". Automatically finds the next ticket number, creates the ticket file, and updates the centralized ticket list.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Create Ticket Skill
|
|
7
|
+
|
|
8
|
+
Create properly numbered tickets with consistent structure.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
1. Scan `claude/tickets/` for existing `TICKET-XXX-*.md` files
|
|
13
|
+
2. Determine next ticket number (highest + 1, or 001 if none)
|
|
14
|
+
3. Create ticket file at `claude/tickets/TICKET-XXX-description.md`
|
|
15
|
+
4. Update `claude/tickets/ticket-list.md` with new entry
|
|
16
|
+
|
|
17
|
+
## Finding Next Ticket Number
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
ls claude/tickets/TICKET-*.md 2>/dev/null | grep -oE 'TICKET-[0-9]+' | sort -t'-' -k2 -n | tail -1
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
If no tickets exist, start with `TICKET-001`.
|
|
24
|
+
|
|
25
|
+
## Ticket Template
|
|
26
|
+
|
|
27
|
+
```markdown
|
|
28
|
+
# TICKET-XXX: [Title]
|
|
29
|
+
|
|
30
|
+
## Description
|
|
31
|
+
[Detailed description of the task]
|
|
32
|
+
|
|
33
|
+
## Acceptance Criteria
|
|
34
|
+
- [ ] Criterion 1
|
|
35
|
+
- [ ] Criterion 2
|
|
36
|
+
- [ ] Criterion 3
|
|
37
|
+
|
|
38
|
+
## Priority
|
|
39
|
+
High/Medium/Low
|
|
40
|
+
|
|
41
|
+
## Status
|
|
42
|
+
Todo
|
|
43
|
+
|
|
44
|
+
## Notes
|
|
45
|
+
[Any additional context or notes]
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
## Updating ticket-list.md
|
|
49
|
+
|
|
50
|
+
Add entry to appropriate priority section:
|
|
51
|
+
|
|
52
|
+
```markdown
|
|
53
|
+
### High Priority
|
|
54
|
+
- 🔴 [TICKET-XXX](./TICKET-XXX-description.md) - Title here
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
**Status emojis:**
|
|
58
|
+
| Status | Emoji |
|
|
59
|
+
|--------|-------|
|
|
60
|
+
| Todo | 🔴 |
|
|
61
|
+
| In Progress | 🟡 |
|
|
62
|
+
| Done | 🟢 |
|
|
63
|
+
| Blocked | 🔵 |
|
|
64
|
+
| Cancelled | ⚫ |
|
|
65
|
+
|
|
66
|
+
## File Naming
|
|
67
|
+
|
|
68
|
+
Convert title to kebab-case for filename:
|
|
69
|
+
- "User Authentication" → `TICKET-001-user-authentication.md`
|
|
70
|
+
- "Fix API Bug" → `TICKET-002-fix-api-bug.md`
|
|
71
|
+
|
|
72
|
+
## Example
|
|
73
|
+
|
|
74
|
+
User: "Create a ticket for adding user authentication"
|
|
75
|
+
|
|
76
|
+
Creates `claude/tickets/TICKET-001-user-authentication.md`:
|
|
77
|
+
```markdown
|
|
78
|
+
# TICKET-001: User Authentication
|
|
79
|
+
|
|
80
|
+
## Description
|
|
81
|
+
Implement user authentication system for the application.
|
|
82
|
+
|
|
83
|
+
## Acceptance Criteria
|
|
84
|
+
- [ ] Users can register with email/password
|
|
85
|
+
- [ ] Users can log in and receive session token
|
|
86
|
+
- [ ] Protected routes require authentication
|
|
87
|
+
|
|
88
|
+
## Priority
|
|
89
|
+
High
|
|
90
|
+
|
|
91
|
+
## Status
|
|
92
|
+
Todo
|
|
93
|
+
|
|
94
|
+
## Notes
|
|
95
|
+
Consider using JWT for session management.
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
Updates `claude/tickets/ticket-list.md`:
|
|
99
|
+
```markdown
|
|
100
|
+
### High Priority
|
|
101
|
+
- 🔴 [TICKET-001](./TICKET-001-user-authentication.md) - User Authentication
|
|
102
|
+
```
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design-feature
|
|
3
|
+
description: Guide feature development through contract establishment and UI design phases. Use when discussing, designing, or planning a new feature that is not yet implemented. Ensures requirements are clarified, acceptance criteria defined, and UI layouts drafted before any code is written.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Design Feature Skill
|
|
7
|
+
|
|
8
|
+
Guide new feature development through structured planning phases before implementation.
|
|
9
|
+
|
|
10
|
+
## Workflow
|
|
11
|
+
|
|
12
|
+
### Phase 1: Contract Establishment
|
|
13
|
+
|
|
14
|
+
Before any design or code, establish the feature contract:
|
|
15
|
+
|
|
16
|
+
1. **Clarify requirements** - Ask questions to fully understand the feature
|
|
17
|
+
2. **Define scope** - What is and isn't included
|
|
18
|
+
3. **Set acceptance criteria** - Specific, testable conditions for completion
|
|
19
|
+
4. **Identify constraints** - Technical limitations, dependencies, edge cases
|
|
20
|
+
|
|
21
|
+
Output a contract summary:
|
|
22
|
+
|
|
23
|
+
```markdown
|
|
24
|
+
## Feature Contract: [Feature Name]
|
|
25
|
+
|
|
26
|
+
### Scope
|
|
27
|
+
- [What's included]
|
|
28
|
+
- [What's excluded]
|
|
29
|
+
|
|
30
|
+
### Acceptance Criteria
|
|
31
|
+
- [ ] Criterion 1
|
|
32
|
+
- [ ] Criterion 2
|
|
33
|
+
- [ ] Criterion 3
|
|
34
|
+
|
|
35
|
+
### Constraints
|
|
36
|
+
- [Technical constraints]
|
|
37
|
+
- [Dependencies]
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
### Phase 2: UI Design
|
|
41
|
+
|
|
42
|
+
After contract agreement, draft the UI layout in `claude/docs/UI_LAYOUT.md`.
|
|
43
|
+
|
|
44
|
+
Include:
|
|
45
|
+
|
|
46
|
+
1. **Desktop layout** - Full-width design
|
|
47
|
+
2. **Mobile layout** - Responsive/stacked design
|
|
48
|
+
3. **Component hierarchy** - Parent-child relationships
|
|
49
|
+
4. **Interactions** - User actions and responses
|
|
50
|
+
5. **Required assets** - Icons, images, fonts
|
|
51
|
+
|
|
52
|
+
UI Layout template:
|
|
53
|
+
|
|
54
|
+
```markdown
|
|
55
|
+
# [Feature Name] - UI Layout
|
|
56
|
+
|
|
57
|
+
## Desktop Layout
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
┌─────────────────────────────────────┐
|
|
61
|
+
│ Header │
|
|
62
|
+
├─────────────────────────────────────┤
|
|
63
|
+
│ Component A │ Component B │
|
|
64
|
+
│ │ │
|
|
65
|
+
├─────────────────────────────────────┤
|
|
66
|
+
│ Footer │
|
|
67
|
+
└─────────────────────────────────────┘
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
## Mobile Layout
|
|
71
|
+
|
|
72
|
+
```
|
|
73
|
+
┌─────────────┐
|
|
74
|
+
│ Header │
|
|
75
|
+
├─────────────┤
|
|
76
|
+
│ Component A │
|
|
77
|
+
├─────────────┤
|
|
78
|
+
│ Component B │
|
|
79
|
+
├─────────────┤
|
|
80
|
+
│ Footer │
|
|
81
|
+
└─────────────┘
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
## Component Hierarchy
|
|
85
|
+
|
|
86
|
+
- ParentComponent
|
|
87
|
+
- ChildComponent1
|
|
88
|
+
- ChildComponent2
|
|
89
|
+
- GrandchildComponent
|
|
90
|
+
|
|
91
|
+
## Interactions
|
|
92
|
+
|
|
93
|
+
| Action | Response |
|
|
94
|
+
|--------|----------|
|
|
95
|
+
| Click X | Shows Y |
|
|
96
|
+
| Hover Z | Highlights |
|
|
97
|
+
|
|
98
|
+
## Required Assets
|
|
99
|
+
|
|
100
|
+
- [ ] Icon: description
|
|
101
|
+
- [ ] Image: description
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
## Process Flow
|
|
105
|
+
|
|
106
|
+
1. User describes feature idea
|
|
107
|
+
2. Ask clarifying questions (no assumptions)
|
|
108
|
+
3. Draft and agree on contract
|
|
109
|
+
4. Draft UI layout in `claude/docs/UI_LAYOUT.md`
|
|
110
|
+
5. Review UI together, adjust as needed
|
|
111
|
+
6. Only after agreement, proceed to implementation
|