Task Master Cursor Project Rule (expanded)

gistfile1.txt

When a user asks "please prepare my tasks" break down a provided PRD into tasks. 

- Create an implementation plan, save to “instructions” as a .md file with a checklist
- Break the implementation into phases, save each phase numerically as a .md file to a subfolder of “instructions”
- For each phase list out tasks with a checklist and save to a .md file , save the task list to the phase folder
- For each task, list out subtasks and create a checklist, save the subtask list to the phase folder
- For each subtask list the functions, types, classes, or otherwise that needs to be created
- For each function, type, class or otherwise write a spec for the function, define the input types and the return types
- For each function, type, class or otherwise define a test
- For each function, type, class or otherwise write the code, iterate until the test passes
- Confirm that the function and test are correct for the tasks
- Make a commit after each test passes

- Never work on the main branch
- Always work only on the task at hand
- Always refer to the checklist and update the checklist of the subtask, task, and phase as you work
- For each phase make a new branch named after the phase
- For each task make a new branch as a subbranch of the phase
- For each subtask make a new branch as a subbranch of the task
- After each subtask is completed merge up. Do not delete the branch
- After each task is completed merge up. Do not delete the branch
- After each phase is completed merge up. Do not delete the branch.


# Project Breakdown and Test-Driven Development Guide for LLM

## Project Decomposition Methodology

### Phase 1: Comprehensive Project Analysis
1. Project Scope Definition
   - [ ] Identify core project objectives
   - [ ] List all major functional requirements
   - [ ] Create high-level system architecture diagram

2. Granular Decomposition Process
   - Break down project into hierarchical components:
     a. Major Functional Modules
     b. Specific Features
     c. Discrete Tasks
     d. Atomic Subtasks

### Task Breakdown Strategy

#### Task Decomposition Principles
- Every task must be:
  - Specific
  - Measurable
  - Achievable
  - Relevant
  - Time-bound (SMART criteria)

#### Decomposition Workflow
1. Start with High-Level Objectives
   - List all major system capabilities
   - Identify distinct functional domains

2. Decomposition Levels
   ```
   Project
   ├── Module 1
   │   ├── Feature 1.1
   │   │   ├── Task 1.1.1
   │   │   │   └── Subtask 1.1.1.1
   │   │   ├── Task 1.1.2
   │   │   └── ...
   │   └── Feature 1.2
   └── Module 2
   ```

### Test-Driven Development (TDD) Workflow

#### Test Specification Precedence
1. Test Definition Requirements
   - [ ] Define test BEFORE implementation
   - [ ] Specify success criteria explicitly
   - [ ] Create comprehensive test cases covering:
     * Normal use cases
     * Edge cases
     * Error scenarios
     * Performance expectations

2. Test Specification Template
   ```markdown
   ## Test Specification for [Task Name]

   ### Objectives
   - Precise description of expected behavior

   ### Input Specifications
   - Types
   - Constraints
   - Valid/Invalid input ranges

   ### Expected Outputs
   - Exact return types
   - Expected value ranges
   - Error handling specifications

   ### Test Cases
   1. Standard Scenario
      - Input: [detailed input]
      - Expected Output: [detailed output]
      - Pass Criteria: [exact specifications]

   2. Edge Case Scenario
      - Input: [boundary condition]
      - Expected Behavior: [precise specification]

   3. Error Scenario
      - Input: [invalid input]
      - Expected Error: [specific error type/message]

   ### Success Criteria
   - [ ] All test cases pass
   - [ ] 100% input validation
   - [ ] No unexpected side effects
   ```

#### Implementation Constraints
1. Development Flow
   ```
   [Test Specification] 
   → [Write Failing Test]
   → [Implement Minimal Code]
   → [Run Tests]
   → [Refactor If Needed]
   → [Confirm All Tests Pass]
   ```

2. Progression Rules
   - Do NOT move to next task until:
     * All tests for current task pass
     * Code meets all specified criteria
     * No remaining known issues

### Documentation Requirements
- Each task must have:
  1. Detailed test specification
  2. Implementation code
  3. Passing test results
  4. Explanation of approach

### Commit and Branch Strategy
- Create branch for each task
- Commit after:
  - Test specification creation
  - Initial implementation
  - Passing all tests
- Merge only when:
  - All tests pass
  - Code review complete
  - No pending issues

## Example Task Breakdown Process

### Project: Code Editor with AI Assistance

1. Module: File Management
   - Feature: File Open/Save
     * Task 1: Implement File Opening
       - Subtask: Parse file paths
       - Subtask: Read file contents
       - Subtask: Handle file encoding
     * Task 2: Implement File Saving
       - Subtask: Validate save location
       - Subtask: Write file contents
       - Subtask: Handle save errors

2. Module: AI Code Assistance
   - Feature: Code Completion
     * Task 1: Implement Completion Trigger
     * Task 2: Context Analysis
     * Task 3: Suggestion Generation

### Execution Guidance
- Start with most fundamental tasks
- Complete lower-level subtasks before moving up
- Validate each component in isolation
- Ensure predictable, testable implementations

## Key Reminders for LLM
- ALWAYS define tests first
- Break down into smallest possible tasks
- Validate each component thoroughly
- Maintain clear, traceable progress
- Do NOT proceed without passing tests