ccstart 1.0.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.
@@ -0,0 +1,106 @@
1
+ ---
2
+ name: shadcn
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
+ ---
6
+
7
+ 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.
8
+
9
+ ## Core Responsibilities:
10
+ 1. **Component Implementation**: Build and customize shadcn/ui components
11
+ 2. **Theme Customization**: Implement custom themes and design systems
12
+ 3. **Accessibility**: Leverage Radix UI's built-in accessibility features
13
+ 4. **Integration**: Seamlessly integrate shadcn/ui into existing projects
14
+ 5. **Performance**: Optimize component bundles and rendering
15
+
16
+ ## Key Resources:
17
+ - **Official Repository**: https://github.com/shadcn-ui/ui
18
+ - **Documentation**: https://ui.shadcn.com
19
+ - **Radix UI**: https://www.radix-ui.com
20
+ - **Component Examples**: https://ui.shadcn.com/examples
21
+
22
+ ## Expertise Areas:
23
+
24
+ ### shadcn/ui Components:
25
+ - **Forms**: Form, Input, Select, Checkbox, Radio, Switch, Textarea
26
+ - **Overlays**: Dialog, Sheet, Popover, Tooltip, Context Menu
27
+ - **Navigation**: Navigation Menu, Command, Menubar, Dropdown Menu
28
+ - **Data Display**: Table, Data Table, Card, Badge, Avatar
29
+ - **Feedback**: Alert, Toast, Progress, Skeleton, Spinner
30
+ - **Layout**: Separator, Scroll Area, Aspect Ratio, Collapsible
31
+
32
+ ### Technical Foundation:
33
+ - **Radix UI**: Unstyled, accessible component primitives
34
+ - **Tailwind CSS**: Utility-first styling with custom configurations
35
+ - **CVA**: Class variance authority for component variants
36
+ - **TypeScript**: Full type safety for all components
37
+ - **Lucide Icons**: Comprehensive icon library integration
38
+
39
+ ## Implementation Process:
40
+ 1. Install required dependencies (Radix UI, Tailwind, class-variance-authority)
41
+ 2. Set up Tailwind configuration with shadcn/ui presets
42
+ 3. Configure component library structure (components/ui)
43
+ 4. Copy or generate components using CLI or manual installation
44
+ 5. Customize theme variables in CSS/Tailwind config
45
+ 6. Implement component variants and compositions
46
+ 7. Ensure proper TypeScript types and props
47
+
48
+ ## shadcn/ui Philosophy:
49
+ - **Copy-paste, not npm install**: Components live in your codebase
50
+ - **Full customization**: Modify any aspect of components
51
+ - **Accessibility first**: Built on Radix UI's accessible primitives
52
+ - **Modern stack**: React, TypeScript, Tailwind CSS
53
+ - **No vendor lock-in**: Own your component code
54
+
55
+ ## Customization Patterns:
56
+ ```typescript
57
+ // Component variants with CVA
58
+ const buttonVariants = cva(
59
+ "inline-flex items-center justify-center rounded-md text-sm font-medium",
60
+ {
61
+ variants: {
62
+ variant: {
63
+ default: "bg-primary text-primary-foreground hover:bg-primary/90",
64
+ destructive: "bg-destructive text-destructive-foreground",
65
+ outline: "border border-input bg-background hover:bg-accent",
66
+ },
67
+ size: {
68
+ default: "h-10 px-4 py-2",
69
+ sm: "h-9 rounded-md px-3",
70
+ lg: "h-11 rounded-md px-8",
71
+ },
72
+ },
73
+ }
74
+ )
75
+ ```
76
+
77
+ ## Theme Configuration:
78
+ - **CSS Variables**: Define colors, spacing, radii in :root
79
+ - **Dark Mode**: Built-in dark mode support with Tailwind
80
+ - **Custom Themes**: Create multiple theme variations
81
+ - **Responsive Design**: Mobile-first with Tailwind utilities
82
+
83
+ ## Best Practices:
84
+ - **Component Structure**: Keep ui components in components/ui
85
+ - **Composition**: Build complex UIs by composing primitives
86
+ - **Accessibility**: Never override Radix UI's accessibility features
87
+ - **Customization**: Extend rather than override base styles
88
+ - **Documentation**: Document custom variants and props
89
+
90
+ ## Common Integrations:
91
+ - **React Hook Form**: Form validation and management
92
+ - **Tanstack Table**: Advanced data table features
93
+ - **Zod**: Schema validation for forms
94
+ - **Next.js**: Server components and app directory
95
+ - **Framer Motion**: Animations and transitions
96
+
97
+ ## Output Format:
98
+ When implementing shadcn/ui solutions:
99
+ - **Component Setup**: Installation commands and dependencies
100
+ - **Implementation Code**: Complete component with all variants
101
+ - **Usage Examples**: How to use the component in different scenarios
102
+ - **Customization Guide**: How to modify for specific needs
103
+ - **Accessibility Notes**: Key accessibility features preserved
104
+ - **Integration Tips**: How to connect with forms, state, etc.
105
+
106
+ Remember: shadcn/ui is about owning your components. Always prioritize customization, accessibility, and developer experience.
@@ -0,0 +1,64 @@
1
+ # ROADMAP
2
+
3
+ ## Overview
4
+
5
+ High-level overview of the project, what it does, the main features
6
+
7
+ ## Development Workflow
8
+
9
+ 1. **Task Planning**
10
+ - Study the existing codebase and understand the current state
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
+ - Update `ROADMAP.md` to include the new task under Development
14
+ - Priority tasks should be inserted after the last completed task
15
+
16
+ 2. **Ticket Creation**
17
+ - Study the existing codebase and understand the current state
18
+ - Create a new ticket file in the `/tickets` directory
19
+ - Name format: `TICKET-XXX-description.md` (e.g., `TICKET-001-user-auth.md`)
20
+ - Include high-level specifications, relevant files, acceptance criteria, and implementation steps
21
+ - Refer to last completed ticket in the `/tickets` directory for examples
22
+ - Note that completed tickets show checked boxes and summary of changes
23
+ - For new tickets, use empty checkboxes and no summary section
24
+
25
+ 3. **Task Implementation**
26
+ - Use the **coder** agent for implementing features, fixing bugs, and optimizing code
27
+ - Follow the specifications in the ticket file
28
+ - Implement features and functionality following project conventions
29
+ - Update step progress within the ticket file after each step
30
+ - Stop after completing each step and wait for further instructions
31
+
32
+ 4. **Quality Assurance**
33
+ - Use the **checker** agent for testing, security analysis, and code review
34
+ - Verify all acceptance criteria are met
35
+ - Run tests and ensure code quality standards
36
+ - Document any issues found and their resolutions
37
+
38
+ 5. **Roadmap Updates**
39
+ - Mark completed tasks with ✅ in the roadmap
40
+ - Add reference to the ticket file (e.g., `See: /tickets/TICKET-001-user-auth.md`)
41
+ - Update related plan documents if applicable
42
+
43
+ ## Development
44
+
45
+ ### Project Setup and Boilerplate
46
+ - [x] Create Claude Code boilerplate structure ✅
47
+ - Set up CLAUDE.md with project instructions
48
+ - Create agents directory with planner, coder, and checker agents
49
+ - Establish docs, plans, and tickets directories
50
+ - Add README files to all directories
51
+
52
+ ### [Add your project tasks here]
53
+ - [ ] Task description
54
+ - Subtask 1
55
+ - Subtask 2
56
+ - See: /tickets/TICKET-XXX-description.md
57
+
58
+ ## Future Enhancements
59
+
60
+ [List potential future features and improvements]
61
+
62
+ ## Completed Tasks Archive
63
+
64
+ [Move completed sections here to keep the active roadmap clean]
@@ -0,0 +1,152 @@
1
+ # Agent Orchestration Guide
2
+
3
+ ## Overview
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
+
6
+ ## Core Agent Workflows
7
+
8
+ ### 1. Feature Development Workflow
9
+ **Purpose**: Implement new features from conception to completion
10
+
11
+ **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
15
+ 4. **Checker Agent** → Test, review, and validate the implementation
16
+
17
+ **Example Prompt**:
18
+ ```
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."
20
+ ```
21
+
22
+ ### 2. Bug Fix Workflow
23
+ **Purpose**: Systematically identify and fix bugs
24
+
25
+ **Flow**:
26
+ 1. **Researcher Agent** → Investigate the bug and find root cause
27
+ 2. **Coder Agent** → Implement the fix
28
+ 3. **Checker Agent** → Verify fix and check for regressions
29
+
30
+ ### 3. Refactoring Workflow
31
+ **Purpose**: Improve code quality without changing functionality
32
+
33
+ **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
38
+
39
+ ### 4. API Development Workflow
40
+ **Purpose**: Design and implement APIs
41
+
42
+ **Flow**:
43
+ 1. **Planner Agent** → Design API architecture and endpoints
44
+ 2. **Backend Agent** → Implement server-side logic
45
+ 3. **Frontend Agent** → Create client integration (if needed)
46
+ 4. **Checker Agent** → Test API functionality and security
47
+
48
+ ### 5. UI Component Workflow
49
+ **Purpose**: Create user interface components
50
+
51
+ **Flow**:
52
+ 1. **Frontend Agent** → Design and implement UI components
53
+ 2. **Shadcn Agent** → Apply shadcn/ui styling (if using React)
54
+ 3. **Checker Agent** → Test accessibility and responsiveness
55
+
56
+ ### 6. Blockchain Development Workflow
57
+ **Purpose**: Develop Web3 features and smart contracts
58
+
59
+ **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
63
+
64
+ ## Orchestration Best Practices
65
+
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
70
+
71
+ ### 2. Plan Before Implementation
72
+ - Use Planner Agent for complex features
73
+ - Create detailed plans in `/plans` directory
74
+ - Break down large tasks into smaller tickets
75
+
76
+ ### 3. Sequential Execution
77
+ - Complete each agent's task before moving to the next
78
+ - Use TodoWrite to track progress through the workflow
79
+ - Don't skip agents unless explicitly instructed
80
+
81
+ ### 4. Validation is Mandatory
82
+ - Always end with Checker Agent
83
+ - Run tests and linting
84
+ - Verify all acceptance criteria
85
+
86
+ ### 5. Documentation Updates
87
+ - Update ROADMAP.md after completing workflows
88
+ - Mark tickets as complete with summaries
89
+ - Keep plans updated with outcomes
90
+
91
+ ## Workflow Triggers
92
+
93
+ ### When to use Feature Development Workflow:
94
+ - Adding new functionality
95
+ - Implementing user stories
96
+ - Creating new modules or services
97
+
98
+ ### When to use Bug Fix Workflow:
99
+ - Fixing reported issues
100
+ - Addressing error messages
101
+ - Resolving unexpected behavior
102
+
103
+ ### When to use Refactoring Workflow:
104
+ - Improving code readability
105
+ - Optimizing performance
106
+ - Updating deprecated code
107
+
108
+ ### When to use API Development Workflow:
109
+ - Creating new endpoints
110
+ - Designing service interfaces
111
+ - Building integrations
112
+
113
+ ### When to use UI Component Workflow:
114
+ - Building new UI elements
115
+ - Updating existing interfaces
116
+ - Implementing design changes
117
+
118
+ ### When to use Blockchain Workflow:
119
+ - Smart contract development
120
+ - DeFi integrations
121
+ - Web3 features
122
+
123
+ ## Example Multi-Agent Execution
124
+
125
+ ```
126
+ User: "I need to add a payment processing feature"
127
+
128
+ 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]
134
+
135
+ 3. "With the plan ready, I'll use the backend agent to implement the server-side payment processing."
136
+ [Uses Backend Agent]
137
+
138
+ 4. "Now I'll use the frontend agent to create the payment UI components."
139
+ [Uses Frontend Agent]
140
+
141
+ 5. "Finally, let me use the checker agent to verify the implementation and ensure security."
142
+ [Uses Checker Agent]
143
+ ```
144
+
145
+ ## Workflow Customization
146
+
147
+ You can create custom workflows by:
148
+ 1. Combining agents in different sequences
149
+ 2. Adding conditional paths based on findings
150
+ 3. Creating specialized workflows for your project
151
+
152
+ Remember: The goal is systematic, thorough task completion with proper validation at each step.
@@ -0,0 +1,53 @@
1
+ # Plans
2
+
3
+ This directory contains project plans and architectural documents.
4
+
5
+ ## Purpose
6
+ Store detailed implementation plans, architectural decisions, and strategic roadmaps created by the planner agent or during project planning sessions.
7
+
8
+ ## Plan Structure
9
+ Each plan should be a markdown file with:
10
+ - Clear objectives and goals
11
+ - Detailed implementation steps
12
+ - Technical architecture decisions
13
+ - Risk analysis and mitigation strategies
14
+ - Success metrics
15
+
16
+ ## Example Plan Format
17
+ ```markdown
18
+ # PLAN-XXX: [Plan Title]
19
+
20
+ ## Executive Summary
21
+ [High-level overview]
22
+
23
+ ## Objectives
24
+ - [ ] Objective 1
25
+ - [ ] Objective 2
26
+
27
+ ## Architecture
28
+ [Technical approach and design]
29
+
30
+ ## Implementation Phases
31
+ ### Phase 1: Foundation
32
+ - Task 1
33
+ - Task 2
34
+
35
+ ### Phase 2: Core Features
36
+ - Task 3
37
+ - Task 4
38
+
39
+ ## Risks & Mitigations
40
+ | Risk | Impact | Mitigation |
41
+ |------|--------|------------|
42
+ | Risk 1 | High | Strategy 1 |
43
+
44
+ ## Success Metrics
45
+ - Metric 1
46
+ - Metric 2
47
+ ```
48
+
49
+ ## Plan Naming Convention
50
+ Use format: `PLAN-XXX-brief-description.md`
51
+
52
+ ## Current Plans
53
+ [List active plans here]
@@ -0,0 +1,39 @@
1
+ # Tickets
2
+
3
+ This directory contains task tickets and issues.
4
+
5
+ ## Ticket Format
6
+ Each ticket should be a markdown file with:
7
+ - Clear title
8
+ - Description of the task
9
+ - Acceptance criteria
10
+ - Priority level
11
+ - Status
12
+
13
+ ## Example Ticket Structure
14
+ ```markdown
15
+ # TICKET-001: [Title]
16
+
17
+ ## Description
18
+ [Detailed description of the task]
19
+
20
+ ## Acceptance Criteria
21
+ - [ ] Criterion 1
22
+ - [ ] Criterion 2
23
+ - [ ] Criterion 3
24
+
25
+ ## Priority
26
+ High/Medium/Low
27
+
28
+ ## Status
29
+ Todo/In Progress/Done
30
+
31
+ ## Notes
32
+ [Any additional context or notes]
33
+ ```
34
+
35
+ ## Ticket Naming Convention
36
+ Use format: `TICKET-XXX-brief-description.md`
37
+
38
+ ## Current Tickets
39
+ [List active tickets here]
@@ -0,0 +1,79 @@
1
+ # Ticket List
2
+
3
+ ## Overview
4
+ This file maintains a centralized list of all tickets in the project. Update this file whenever you create, update, or complete tickets.
5
+
6
+ **Note**: Individual ticket files are stored in this same `/tickets` folder with the naming convention `TICKET-XXX-description.md` (e.g., `TICKET-001-user-authentication.md`, `TICKET-002-api-integration.md`)
7
+
8
+ ## Ticket Status Legend
9
+ - 🔴 **Todo** - Not started
10
+ - 🟡 **In Progress** - Currently being worked on
11
+ - 🟢 **Done** - Completed
12
+ - 🔵 **Blocked** - Waiting on dependencies or external factors
13
+ - âš« **Cancelled** - No longer needed
14
+
15
+ ## Active Tickets
16
+
17
+ ### High Priority
18
+ _No high priority tickets yet_
19
+
20
+ ### Medium Priority
21
+ _No medium priority tickets yet_
22
+
23
+ ### Low Priority
24
+ _No low priority tickets yet_
25
+
26
+ ## Completed Tickets
27
+ _No completed tickets yet_
28
+
29
+ ## Cancelled/Archived Tickets
30
+ _No cancelled tickets yet_
31
+
32
+ ---
33
+
34
+ ## How to Use This File
35
+
36
+ 1. **When creating a new ticket**:
37
+ - Create the ticket file in `/tickets` folder (e.g., `TICKET-001-user-authentication.md`)
38
+ - Use the template structure from `/tickets/README.md` for the ticket content
39
+ - Add it to the appropriate priority section in this list
40
+ - Include ticket number, title, and status emoji
41
+ - Link to the full ticket file
42
+
43
+ 2. **Format for ticket entries**:
44
+ ```
45
+ - 🔴 [TICKET-001](./TICKET-001-user-authentication.md) - User Authentication System
46
+ ```
47
+
48
+ 3. **File organization**:
49
+ ```
50
+ tickets/
51
+ ├── ticket-list.md # This file (centralized index)
52
+ ├── TICKET-001-user-auth.md # Individual ticket file
53
+ ├── TICKET-002-api-docs.md # Individual ticket file
54
+ └── TICKET-003-testing.md # Individual ticket file
55
+ ```
56
+
57
+ 4. **When updating ticket status**:
58
+ - Change the status emoji
59
+ - Move completed tickets to "Completed Tickets" section
60
+ - Add completion date for completed tickets
61
+
62
+ 4. **Example of a populated list**:
63
+ ```markdown
64
+ ### High Priority
65
+ - 🟡 [TICKET-001](./TICKET-001-user-authentication.md) - User Authentication System
66
+ - 🔴 [TICKET-003](./TICKET-003-api-rate-limiting.md) - Implement API Rate Limiting
67
+
68
+ ### Medium Priority
69
+ - 🔵 [TICKET-002](./TICKET-002-email-notifications.md) - Email Notification Service (blocked: waiting for SMTP credentials)
70
+
71
+ ### Completed Tickets
72
+ - 🟢 [TICKET-000](./TICKET-000-project-setup.md) - Initial Project Setup (Completed: 2024-01-15)
73
+ ```
74
+
75
+ 5. **Best Practices**:
76
+ - Keep this file updated in real-time
77
+ - Review weekly to ensure accuracy
78
+ - Use consistent naming conventions
79
+ - Archive old completed tickets quarterly