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.
@@ -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 **coder** agent for implementing features, fixing bugs, and optimizing code
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, coder, and checker agents
49
- - Establish docs, plans, and tickets directories
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. **Researcher Agent** → Gather requirements and understand existing codebase
13
- 2. **Planner Agent** → Create detailed implementation plan and architecture
14
- 3. **Coder Agent** → Implement the feature following the plan
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 researcher agent to understand the current architecture, then the planner to design the auth system, coder to implement it, and checker to validate."
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. **Researcher Agent** → Investigate the bug and find root cause
27
- 2. **Coder Agent** → Implement the fix
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. **Researcher Agent** → Analyze current implementation and identify improvements
35
- 2. **Planner Agent** → Design refactoring approach
36
- 3. **Coder Agent** → Execute refactoring
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. **Frontend Agent** → Design and implement UI components
53
- 2. **Shadcn Agent** → Apply shadcn/ui styling (if using React)
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. Blockchain Development Workflow
57
- **Purpose**: Develop Web3 features and smart contracts
62
+ ### 6. QA Workflow
63
+ **Purpose**: Comprehensive quality assurance for code changes
58
64
 
59
65
  **Flow**:
60
- 1. **Planner Agent** → Design smart contract architecture
61
- 2. **Blockchain Agent** → Implement contracts and Web3 integration
62
- 3. **Checker Agent** → Security audit and testing
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
- ### 1. Always Start with Understanding
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
- ### 2. Plan Before Implementation
72
- - Use Planner Agent for complex features
73
- - Create detailed plans in `/plans` directory
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
- ### 3. Sequential Execution
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
- ### 4. Validation is Mandatory
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
- ### 5. Documentation Updates
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 Blockchain Workflow:
119
- - Smart contract development
120
- - DeFi integrations
121
- - Web3 features
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 researcher agent to understand your current architecture and any existing payment-related code."
130
- [Uses Researcher Agent]
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
- 3. "With the plan ready, I'll use the backend agent to implement the server-side payment processing."
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
- 4. "Now I'll use the frontend agent to create the payment UI components."
148
+ 3. "Now I'll use the frontend agent to create the payment UI components."
139
149
  [Uses Frontend Agent]
140
150
 
141
- 5. "Finally, let me use the checker agent to verify the implementation and ensure security."
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