MCPs:
- `server-sequential-thinking` (MVP)
- `memory` (2nd MVP, needs custom rules for config)
- `context7`
- `filesystem`
- `fetch`
- `postgres`
- `git`
- `time`
Example rules file for ticketing system:
```
# Ticket Management Guidelines
This document outlines the standardized approach to ticket management in the project. All team members should follow these guidelines when creating, updating, or completing tickets.
## Ticket Organization
Tickets are organized by status and area in the following structure:
TICKETS/
COMPLETED/ - Finished tickets
BACKEND/ - Backend-related tickets
FRONTEND/ - Frontend-related tickets
IN_PROGRESS/ - Tickets currently being worked on
BACKEND/
FRONTEND/
BACKLOG/ - Tickets planned but not yet started
BACKEND/
FRONTEND/
## Ticket Status Indicators
All tickets must use consistent status indicators:
- *BACKLOG* - Planned but not yet started
- *IN_PROGRESS* - Currently being implemented
- *COMPLETED* - Implementation is finished
- *ABANDONED* - Work was stopped and will not continue
## Required Ticket Files
Each ticket directory must contain these files:
1. *Main Ticket File* (TICKET_.md):
- Problem statement and background
- Detailed analysis
- Implementation plan
- Acceptance criteria
2. *Implementation Plan* (IMPLEMENTATION_PLAN.md):
- Detailed breakdown of tasks
- Timeline estimates
- Success metrics
3. *Implementation Progress* (IMPLEMENTATION_PROGRESS.md):
- Status updates
- Issues encountered
- Decisions made
4. *Design Documentation* (DESIGN_RECOMMENDATIONS.md), when relevant:
- Architecture recommendations
- Code patterns and examples
- Error handling strategies
5. *API Documentation* (API_DOCUMENTATION.md), when applicable:
- Interface definitions
- Usage examples
- Configuration options
## Ticket Workflow Rules
### Creating Tickets
1. Create tickets in the appropriate BACKLOG directory
2. Use standard templates from .templates/ticket_template.md
3. Set status to *Status: BACKLOG*
4. Update the TICKET_INDEX.md file
### Updating Tickets
1. Move tickets to the appropriate status directory when status changes
2. Update the status indicator in the main ticket file
3. Update the "Last Updated" date when making significant changes
4. Document progress in IMPLEMENTATION_PROGRESS.md
5. Check off completed tasks in IMPLEMENTATION_PLAN.md
### Completing Tickets
1. Ensure all acceptance criteria are met
2. Move the ticket to the COMPLETED directory
3. Set status to *Status: COMPLETED*
4. Update the TICKET_INDEX.md file
5. Create a completion summary in the main ticket file
### Abandoning Tickets
1. Document reasons for abandonment
2. Move to COMPLETED/ABANDONED directory
3. Set status to *Status: ABANDONED*
4. Update the TICKET_INDEX.md file
## Ticket Linking
When referencing other tickets, use relative links with appropriate paths:
markdown
@TICKET_NAME
Ensure all links are updated when tickets change status.
## Ticket Cleanup and Streamlining
### When to Streamline Tickets
Tickets should be streamlined and cleaned up at major transition points to maintain focus on remaining work:
1. *Major Phase Transitions* - When moving between phases (e.g., from implementation to testing)
2. *Milestone Achievements* - After completing significant portions of work (e.g., 80%+ complete)
3. *Infrastructure Readiness* - When moving from setup/building to operational phases
4. *Team Handoffs* - When different team members will be taking over the work
### What to Streamline
*Replace Historical Implementation Details With:*
- Brief completed tasks checklist ( high-level achievements)
- Current status summary
- Forward-focused remaining work
*Remove or Simplify:*
- Detailed session-by-session progress logs
- Extensive implementation decision histories
- Verbose research findings documentation
- Historical status updates and coordination notes
### Why Streamline Tickets
1. *Git History Preservation* - All detailed progress, decisions, and implementation details are preserved in git commits
2. *Clarity for Future Work* - Makes it easier to quickly understand "what needs to be done next"
3. *Team Efficiency* - Anyone picking up the work can immediately see current state and next steps
4. *Maintainability* - Shorter, focused tickets are easier to read, understand, and keep updated
### How to Streamline
1. *Archive Detailed Progress* - Historical implementation details are preserved in git history
2. *Create Completion Summary* - Replace detailed progress with a brief "What's Complete" checklist
3. *Focus on Remaining Work* - Make current and future phases the primary content
4. *Update Status Sections* - Keep status concise and action-oriented
5. *Preserve Essential Context* - Keep architectural decisions, constraints, and key requirements
*Goal*: Transform tickets from "implementation logs" into "actionable work plans" while preserving essential context.
## Maintenance Requirements
1. Keep the TICKET_INDEX.md file up to date
2. Update "Last Updated" dates when making significant changes
3. Ensure all ticket files follow the standardized format
4. Include links between related tickets in both directions
## Complete Documentation
For detailed instructions on working with tickets, refer to:
- @Ticket Workflow Guide
- @Ticket Index
- @Tickets README
```