Cline rules

1# Ticketing System
2 
3## Overview
4This project uses a lightweight, file-based ticketing system inspired by Jira.
5 
6* Epics are stored as Markdown files in `epics/` with a unique epic number and brief title with the following format `EPIC-$number-$title` (eg. `epics/EPIC-01-setup-project.md`)
7* Tickets are stored as Markdown files in `tickets/EPIC-$number-$title/` (when ticket is linked to an epic) or simply `tickets/` (when no linked epic) with a unique ticket number and brief title with the following format `TICKET-$number-$title` (eg. `tickets/EPIC-01-setup-project/TICKET-01-configure-monorepo.md` or `tickets/TICKET-01-configure-monorepo.md`)
8 
9This approach keeps all project management artifacts within the repository, providing a single source of truth for both code and tasks.
10 
11## Epic Structure
12Epics are larger bodies of work that group related tickets.
13 
14```markdown
15# Epic Title
16 
17**ID**: EPIC-XXX
18**Status**: Open | In Progress | Done
19**Reporter**: @username
20**Created**: YYYY-MM-DD
21**Updated**: YYYY-MM-DD
22 
23## Description
24A high-level description of the epic, including its goals and success criteria.
25 
26## Tickets
27- TICKET-XXX: Ticket Title
28- TICKET-YYY: Ticket Title
29```
30 
31## Ticket Structure
32Each ticket is a Markdown file with the following structure:
33 
34```markdown
35# Ticket Title
36 
37**ID**: TICKET-XXX
38**Epic**: EPIC-XXX
39**Status**: Open | In Progress | In Review | Done
40**Complexity**: 1-5 (1=trivial, 5=very complex)
41**Assignee**: @username
42**Reporter**: @username
43**Created**: YYYY-MM-DD
44**Updated**: YYYY-MM-DD
45 
46## Description
47A clear and concise description of the task, including acceptance criteria.
48 
49## Related Tickets
50- **Blocks**: TICKET-YYY
51- **Is Blocked By**: TICKET-ZZZ
52- **Relates To**: TICKET-AAA
53 
54## Comments
55- **@username (YYYY-MM-DD)**: Comment text...
56```
57 
58## Workflow
59 
60### Ticket Creation
611. **Identify Task**: A new task is identified from the implementation roadmap or as a bug/feature request.
622. **Create Epic (if needed)**: If the task is part of a larger body of work, first create a new Markdown file for the epic in the `epics/` folder and its related `tickets/EPIC-$number-$title` folder to store its linked tickets.
633. **Create Ticket**: Create a new Markdown file in `tickets/$EPIC-$number-$title/` (when ticket is linked to an epic) or simply `tickets/` (when no linked epic) with a unique ID.
644. **Fill Details**: Add a title, description, epic, complexity, and any related tickets.
655. **Assign**: Assign the ticket to a team member.
66 
67### Ticket Lifecycle
681. **Not Started**: The ticket has been planned but not yet started.
692. **Open**: The ticket is ready to be worked on.
702. **In Progress**: A developer has started working on the ticket.
713. **In Review**: The work is complete and waiting for code review.
724. **Done**: The code has been merged and the task is complete.
73 
74### Tagging and Linking
75- **Epics**: All tickets should be linked to an epic.
76- **Dependencies**: Use `Blocks` and `Is Blocked By` to manage dependencies.
77- **Relationships**: Use `Relates To` for other related tickets.
78 
79## Best Practices
80- **Atomic Tickets**: Each ticket should represent a single, well-defined task.
81- **Clear Acceptance Criteria**: Define what "done" means for each ticket.
82- **Regular Updates**: Keep ticket statuses and comments up-to-date.
83- **Link Commits**: Reference ticket IDs in commit messages (e.g., `feat: Implement feature [TICKET-123]`).
84- **Consistent Naming**: Use the format `TICKET-XXX` for tickets and `EPIC-XXX` for epics.
85