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.
- package/README.md +346 -0
- package/bin/create-project.bak.js +1062 -0
- package/bin/create-project.js +1107 -0
- package/package.json +47 -0
- package/template/claude/CLAUDE.md +104 -0
- package/template/claude/agents/README.md +35 -0
- package/template/claude/agents/backend.md +80 -0
- package/template/claude/agents/blockchain.md +81 -0
- package/template/claude/agents/checker.md +69 -0
- package/template/claude/agents/coder.md +46 -0
- package/template/claude/agents/frontend.md +73 -0
- package/template/claude/agents/planner.md +36 -0
- package/template/claude/agents/researcher.md +56 -0
- package/template/claude/agents/shadcn.md +106 -0
- package/template/claude/docs/ROADMAP.md +64 -0
- package/template/claude/docs/agent-orchestration.md +152 -0
- package/template/claude/plans/README.md +53 -0
- package/template/claude/tickets/README.md +39 -0
- package/template/claude/tickets/ticket-list.md +79 -0
@@ -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
|