ccstart 2.0.1 → 2.2.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/README.md +55 -53
- package/bin/create-project.js +6 -9
- package/package.json +2 -2
- package/template/claude/CLAUDE.md +20 -15
- package/template/claude/agents/README.md +4 -7
- package/template/claude/agents/backend.md +231 -76
- package/template/claude/agents/checker.md +76 -51
- package/template/claude/agents/frontend.md +295 -69
- package/template/claude/agents/planner.md +86 -32
- package/template/claude/docs/ROADMAP.md +3 -5
- package/template/claude/docs/agent-orchestration.md +72 -41
- 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/agents/blockchain.md +0 -81
- package/template/claude/agents/coder.md +0 -46
- package/template/claude/agents/researcher.md +0 -56
- package/template/claude/agents/shadcn.md +0 -106
- package/template/claude/plans/README.md +0 -53
|
@@ -9,7 +9,6 @@ High-level overview of the project, what it does, the main features
|
|
|
9
9
|
1. **Task Planning**
|
|
10
10
|
- Study the existing codebase and understand the current state
|
|
11
11
|
- Use the **planner** agent to break down complex problems and create implementation roadmaps
|
|
12
|
-
- Create a plan document in the `/plans` directory for complex features
|
|
13
12
|
- Update `ROADMAP.md` to include the new task under Development
|
|
14
13
|
- Priority tasks should be inserted after the last completed task
|
|
15
14
|
|
|
@@ -23,7 +22,7 @@ High-level overview of the project, what it does, the main features
|
|
|
23
22
|
- For new tickets, use empty checkboxes and no summary section
|
|
24
23
|
|
|
25
24
|
3. **Task Implementation**
|
|
26
|
-
- Use the **
|
|
25
|
+
- Use the **backend** or **frontend** agent for implementing features, fixing bugs, and optimizing code
|
|
27
26
|
- Follow the specifications in the ticket file
|
|
28
27
|
- Implement features and functionality following project conventions
|
|
29
28
|
- Update step progress within the ticket file after each step
|
|
@@ -38,15 +37,14 @@ High-level overview of the project, what it does, the main features
|
|
|
38
37
|
5. **Roadmap Updates**
|
|
39
38
|
- Mark completed tasks with ✅ in the roadmap
|
|
40
39
|
- Add reference to the ticket file (e.g., `See: /tickets/TICKET-001-user-auth.md`)
|
|
41
|
-
- Update related plan documents if applicable
|
|
42
40
|
|
|
43
41
|
## Development
|
|
44
42
|
|
|
45
43
|
### Project Setup and Boilerplate
|
|
46
44
|
- [x] Create Claude Code boilerplate structure ✅
|
|
47
45
|
- Set up CLAUDE.md with project instructions
|
|
48
|
-
- Create agents directory with planner,
|
|
49
|
-
- Establish docs,
|
|
46
|
+
- Create agents directory with planner, checker, backend, and frontend agents
|
|
47
|
+
- Establish docs, skills, and tickets directories
|
|
50
48
|
- Add README files to all directories
|
|
51
49
|
|
|
52
50
|
### [Add your project tasks here]
|
|
@@ -3,38 +3,44 @@
|
|
|
3
3
|
## Overview
|
|
4
4
|
This document defines the standard workflows for orchestrating multiple agents in Claude Code to complete complex tasks efficiently. Follow these patterns to ensure consistent and thorough task execution.
|
|
5
5
|
|
|
6
|
+
## Available Agents
|
|
7
|
+
|
|
8
|
+
- **Planner Agent** - Strategic planning and task breakdown
|
|
9
|
+
- **Checker Agent** - Quality assurance and code review
|
|
10
|
+
- **Backend Agent** - FastAPI and Python backend development
|
|
11
|
+
- **Frontend Agent** - React and TypeScript frontend development
|
|
12
|
+
|
|
6
13
|
## Core Agent Workflows
|
|
7
14
|
|
|
8
15
|
### 1. Feature Development Workflow
|
|
9
16
|
**Purpose**: Implement new features from conception to completion
|
|
10
17
|
|
|
11
18
|
**Flow**:
|
|
12
|
-
1. **
|
|
13
|
-
2. **
|
|
14
|
-
3. **
|
|
19
|
+
1. **Planner Agent** → Create detailed implementation plan and architecture
|
|
20
|
+
2. **Backend Agent** → Implement server-side logic (if needed)
|
|
21
|
+
3. **Frontend Agent** → Implement client-side components (if needed)
|
|
15
22
|
4. **Checker Agent** → Test, review, and validate the implementation
|
|
16
23
|
|
|
17
24
|
**Example Prompt**:
|
|
18
25
|
```
|
|
19
|
-
"I need to add user authentication to the app. First use the
|
|
26
|
+
"I need to add user authentication to the app. First use the planner to design the auth system, backend to implement the API, frontend for the UI, and checker to validate."
|
|
20
27
|
```
|
|
21
28
|
|
|
22
29
|
### 2. Bug Fix Workflow
|
|
23
30
|
**Purpose**: Systematically identify and fix bugs
|
|
24
31
|
|
|
25
32
|
**Flow**:
|
|
26
|
-
1. **
|
|
27
|
-
2. **
|
|
33
|
+
1. **Planner Agent** → Investigate the bug and plan the fix
|
|
34
|
+
2. **Backend Agent** or **Frontend Agent** → Implement the fix
|
|
28
35
|
3. **Checker Agent** → Verify fix and check for regressions
|
|
29
36
|
|
|
30
37
|
### 3. Refactoring Workflow
|
|
31
38
|
**Purpose**: Improve code quality without changing functionality
|
|
32
39
|
|
|
33
40
|
**Flow**:
|
|
34
|
-
1. **
|
|
35
|
-
2. **
|
|
36
|
-
3. **
|
|
37
|
-
4. **Checker Agent** → Ensure functionality remains intact
|
|
41
|
+
1. **Planner Agent** → Analyze current implementation and design refactoring approach
|
|
42
|
+
2. **Backend Agent** or **Frontend Agent** → Execute refactoring
|
|
43
|
+
3. **Checker Agent** → Ensure functionality remains intact
|
|
38
44
|
|
|
39
45
|
### 4. API Development Workflow
|
|
40
46
|
**Purpose**: Design and implement APIs
|
|
@@ -49,41 +55,46 @@ This document defines the standard workflows for orchestrating multiple agents i
|
|
|
49
55
|
**Purpose**: Create user interface components
|
|
50
56
|
|
|
51
57
|
**Flow**:
|
|
52
|
-
1. **
|
|
53
|
-
2. **
|
|
58
|
+
1. **Planner Agent** → Design component architecture
|
|
59
|
+
2. **Frontend Agent** → Implement UI components
|
|
54
60
|
3. **Checker Agent** → Test accessibility and responsiveness
|
|
55
61
|
|
|
56
|
-
### 6.
|
|
57
|
-
**Purpose**:
|
|
62
|
+
### 6. QA Workflow
|
|
63
|
+
**Purpose**: Comprehensive quality assurance for code changes
|
|
58
64
|
|
|
59
65
|
**Flow**:
|
|
60
|
-
1. **Planner Agent** →
|
|
61
|
-
2. **
|
|
62
|
-
3. **
|
|
66
|
+
1. **Planner Agent** → Analyze changes and identify test requirements
|
|
67
|
+
2. **Checker Agent** → Run automated tests and static analysis
|
|
68
|
+
3. **Backend Agent** or **Frontend Agent** → Fix any issues found during QA
|
|
69
|
+
4. **Checker Agent** → Verify fixes and perform final validation
|
|
70
|
+
|
|
71
|
+
**Activities**:
|
|
72
|
+
- Unit and integration testing
|
|
73
|
+
- Code coverage analysis
|
|
74
|
+
- Performance testing
|
|
75
|
+
- Security vulnerability scanning
|
|
76
|
+
- Accessibility compliance (for UI changes)
|
|
77
|
+
- Cross-browser/platform testing
|
|
63
78
|
|
|
64
|
-
## Orchestration Best Practices
|
|
65
79
|
|
|
66
|
-
|
|
67
|
-
- Use Researcher Agent first for non-trivial tasks
|
|
68
|
-
- Understand existing code before making changes
|
|
69
|
-
- Document findings in plans directory
|
|
80
|
+
## Orchestration Best Practices
|
|
70
81
|
|
|
71
|
-
###
|
|
72
|
-
- Use Planner Agent for
|
|
73
|
-
- Create detailed plans
|
|
82
|
+
### 1. Plan Before Implementation
|
|
83
|
+
- Use Planner Agent first for non-trivial tasks
|
|
84
|
+
- Create detailed plans before making changes
|
|
74
85
|
- Break down large tasks into smaller tickets
|
|
75
86
|
|
|
76
|
-
###
|
|
87
|
+
### 2. Sequential Execution
|
|
77
88
|
- Complete each agent's task before moving to the next
|
|
78
89
|
- Use TodoWrite to track progress through the workflow
|
|
79
90
|
- Don't skip agents unless explicitly instructed
|
|
80
91
|
|
|
81
|
-
###
|
|
92
|
+
### 3. Validation is Mandatory
|
|
82
93
|
- Always end with Checker Agent
|
|
83
94
|
- Run tests and linting
|
|
84
95
|
- Verify all acceptance criteria
|
|
85
96
|
|
|
86
|
-
###
|
|
97
|
+
### 4. Documentation Updates
|
|
87
98
|
- Update ROADMAP.md after completing workflows
|
|
88
99
|
- Mark tickets as complete with summaries
|
|
89
100
|
- Keep plans updated with outcomes
|
|
@@ -115,10 +126,12 @@ This document defines the standard workflows for orchestrating multiple agents i
|
|
|
115
126
|
- Updating existing interfaces
|
|
116
127
|
- Implementing design changes
|
|
117
128
|
|
|
118
|
-
### When to use
|
|
119
|
-
-
|
|
120
|
-
-
|
|
121
|
-
-
|
|
129
|
+
### When to use QA Workflow:
|
|
130
|
+
- After completing any feature implementation
|
|
131
|
+
- Before merging code to main branch
|
|
132
|
+
- When addressing production issues
|
|
133
|
+
- After major refactoring
|
|
134
|
+
- Before releases or deployments
|
|
122
135
|
|
|
123
136
|
## Example Multi-Agent Execution
|
|
124
137
|
|
|
@@ -126,22 +139,40 @@ This document defines the standard workflows for orchestrating multiple agents i
|
|
|
126
139
|
User: "I need to add a payment processing feature"
|
|
127
140
|
|
|
128
141
|
Claude's Response Flow:
|
|
129
|
-
1. "I'll help you add payment processing. Let me start by using the
|
|
130
|
-
[Uses
|
|
131
|
-
|
|
132
|
-
2. "Based on my research, I'll now use the planner agent to design the payment processing system."
|
|
133
|
-
[Uses Planner Agent, creates plan in /plans]
|
|
142
|
+
1. "I'll help you add payment processing. Let me start by using the planner agent to design the payment processing system."
|
|
143
|
+
[Uses Planner Agent, creates plan]
|
|
134
144
|
|
|
135
|
-
|
|
145
|
+
2. "With the plan ready, I'll use the backend agent to implement the server-side payment processing."
|
|
136
146
|
[Uses Backend Agent]
|
|
137
147
|
|
|
138
|
-
|
|
148
|
+
3. "Now I'll use the frontend agent to create the payment UI components."
|
|
139
149
|
[Uses Frontend Agent]
|
|
140
150
|
|
|
141
|
-
|
|
151
|
+
4. "Finally, let me use the checker agent to verify the implementation and ensure security."
|
|
142
152
|
[Uses Checker Agent]
|
|
143
153
|
```
|
|
144
154
|
|
|
155
|
+
### QA Workflow Example
|
|
156
|
+
|
|
157
|
+
```
|
|
158
|
+
User: "Can you run QA on the authentication feature we just implemented?"
|
|
159
|
+
|
|
160
|
+
Claude's Response Flow:
|
|
161
|
+
1. "I'll perform comprehensive QA on the authentication feature. Let me start with the planner agent to analyze what was changed and what needs testing."
|
|
162
|
+
[Uses Planner Agent to review changes]
|
|
163
|
+
|
|
164
|
+
2. "Now I'll use the checker agent to run automated tests and perform security analysis."
|
|
165
|
+
[Uses Checker Agent - finds issues with password validation]
|
|
166
|
+
|
|
167
|
+
3. "I found some issues with password validation. Let me use the backend agent to fix these."
|
|
168
|
+
[Uses Backend Agent to implement fixes]
|
|
169
|
+
|
|
170
|
+
4. "Now let me run the checker agent again to verify all issues are resolved."
|
|
171
|
+
[Uses Checker Agent - all tests pass]
|
|
172
|
+
|
|
173
|
+
5. "QA complete! All tests are passing, security checks are clean, and the authentication feature is ready for deployment."
|
|
174
|
+
```
|
|
175
|
+
|
|
145
176
|
## Workflow Customization
|
|
146
177
|
|
|
147
178
|
You can create custom workflows by:
|
|
@@ -149,4 +180,4 @@ You can create custom workflows by:
|
|
|
149
180
|
2. Adding conditional paths based on findings
|
|
150
181
|
3. Creating specialized workflows for your project
|
|
151
182
|
|
|
152
|
-
Remember: The goal is systematic, thorough task completion with proper validation at each step.
|
|
183
|
+
Remember: The goal is systematic, thorough task completion with proper validation at each step.
|
|
@@ -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
|