.cursorrules

# PRD and Task Generation Rules

## Triggers
- `/prd [feature-name]` - Creates PRD document
- `/create-to-dos [feature-name]` - Creates implementation to-dos breakdown document
- `/process-to-do [feature-name] [phase]` - Process specific to-dos from a feature
- `/wrap-to-do [feature-name]` - Create implementation notes for completed work

## Goals
- **PRD**: Guide the AI assistant in creating detailed Product Requirements Documents (PRDs) in Markdown format based on user prompts. PRDs should be clear, actionable, and suitable for junior developers to understand and implement.
- **To-dos**: Break down a feature into specific, actionable implementation to-dos.
- **Process To-do**: Execute specific to-dos from a feature's implementation plan.
- **Wrap To-do**: Document completed implementation work and maintain feature context.

## Process

### For `/prd [feature-name]`:
1. **Receive Initial Prompt**: User provides a brief description or request for a new feature
2. **Ask Clarifying Questions**: MUST ask clarifying questions before writing PRD to understand the "what" and "why" (not the "how"). Provide options in letter/number lists for easy responses
3. **Generate PRD**: Create PRD using the specified structure below
4. **Save PRD**: Save as `[feature-name]/prd.md` in `/specs` directory

### For `/create-to-dos [feature-name]`:
1. **Check for existing PRD**: Look for `/specs/[feature-name]/prd.md` first
2. **Create to-dos breakdown**: Generate specific, actionable implementation to-dos based on the PRD
3. **Structure to-dos**: Break down into logical phases (Backend, Frontend, Testing, Documentation)
4. **Make to-dos specific**: Each to-do should be concrete, measurable, and assignable to a developer
5. **Include acceptance criteria**: Each to-do should have clear completion criteria
6. **Save to-dos**: Save as `[feature-name]/to-dos.md` in `/specs` directory (same folder as PRD)

### For `/process-to-do [feature-name] [phase]`:
1. **Read documentation**: Read relevant files from `/docs/` folder for project context and guidelines
2. **Read to-dos file**: Look for `/specs/[feature-name]/to-dos.md`
3. **Parse phase parameter**:
   - `[phase]` = entire phase (e.g., "1" or "backend")
   - `[phase.number]` = specific to-do (e.g., "1.2" or "backend.3")
4. **Open relevant files**: Automatically read files listed in "Relevant Files" for context
5. **Execute to-do(s)**: Implement the specified to-do(s) following acceptance criteria
6. **Provide next steps**: Suggest next to-dos or phase to work on

### For `/wrap-to-do [feature-name]`:
1. **Maintain feature context**: Remember the current feature being worked on throughout the session
2. **Document completed work**: Create implementation notes for what was accomplished
3. **Update to-dos status**: Mark completed to-dos in the `to-dos.md` file with ✅ status and note any changes or discoveries
4. **Determine phase name**: Use the phase that was most recently worked on (e.g., "database-migration", "comment-collection", "ai-summarization")
5. **Save implementation notes**: Save as `[feature-name]/notes-[phase-name].md` in `/specs` directory
6. **Suggest next actions**: Recommend next to-dos or phases based on current progress

## Clarifying Questions to Ask
Adapt questions based on the prompt, covering these areas:
- **Problem/Goal**: "What problem does this feature solve for the user?"
- **Target User**: "Who is the primary user of this feature?"
- **Core Functionality**: "What key actions should users be able to perform?"
- **User Stories**: "Can you provide user stories? (As a [user], I want to [action] so that [benefit])"
- **Acceptance Criteria**: "How will we know when this feature is successfully implemented?"
- **Scope/Boundaries**: "What should this feature NOT do (non-goals)?"
- **Data Requirements**: "What data does this feature need to display or manipulate?"
- **Design/UI**: "Any existing mockups or UI guidelines to follow?"
- **Edge Cases**: "Any potential edge cases or error conditions to consider?"

## PRD Structure
1. **Introduction/Overview**: Brief description of feature and problem it solves
2. **Goals**: Specific, measurable objectives
3. **User Stories**: Detailed user narratives with usage and benefits
4. **Functional Requirements**: Numbered list of specific functionalities (e.g., "The system must allow users to upload a profile picture")
5. **Non-Goals (Out of Scope)**: What the feature will NOT include
6. **Design Considerations (Optional)**: UI/UX requirements, mockups, components
7. **Technical Considerations (Optional)**: Known constraints, dependencies, suggestions
8. **Success Metrics**: How success will be measured
9. **Open Questions**: Remaining questions or areas needing clarification

## Target Audience
Write for **junior developers** - be explicit, unambiguous, avoid jargon, provide enough detail for understanding purpose and core logic.

## Output Requirements

### For `/prd [feature-name]`:
- **Format**: Markdown (.md)
- **Location**: `/specs/` directory
- **Structure**: `[feature-name]/prd.md` (create folder if needed)

### For `/create-to-dos [feature-name]`:
- **Format**: Markdown (.md)
- **Location**: `/specs/` directory
- **Structure**: `[feature-name]/to-dos.md` (in same folder as PRD)
- **Content**: Structured breakdown of implementation to-dos organized by phase

#### To-dos Structure Format:
```markdown
# [Feature Name] - Implementation To-dos

## Phase 1: Backend Development
1. **To-do Title** - Brief description
   - **Acceptance Criteria**: What defines completion
   - **Relevant Files**: List of files that need to be opened/modified
   - **Dependencies**: Other to-dos that must complete first

## Phase 2: Frontend Development
[Similar structure...]

## Phase 3: Testing & Quality Assurance
[Similar structure...]

## Phase 4: Documentation & Deployment
[Similar structure...]
```

### For `/process-to-do [feature-name] [phase]`:
- **Format**: Execute implementation work
- **Phase Options**:
  - `1` or `backend` = Process entire Phase 1
  - `1.2` or `backend.2` = Process specific to-do #2 in Phase 1
  - `testing` = Process entire Testing phase
  - `testing.1` = Process specific to-do #1 in Testing phase
- **Behavior**: Automatically opens relevant files listed in to-dos for context

### For `/wrap-to-do [feature-name]`:
- **Format**: Markdown (.md)
- **Location**: `/specs/` directory
- **Structure**: `[feature-name]/notes-[phase-name].md` (in same folder as PRD and to-dos)
- **Content**: Documentation of completed work, discoveries, and next steps
- **To-dos Update**: Mark completed to-dos in `[feature-name]/to-dos.md` by adding ✅ at the beginning of completed items

#### To-dos Marking Format:
```markdown
## Phase 1: Database Schema & Migration

✅ 1. **Add status field to News model** - Update News schema to include status tracking
   - **Acceptance Criteria**: News model includes status enum with all required states
   - **Relevant Files**: `packages/hacker-news-ingest/src/models/News.ts`
   - **Dependencies**: None

2. **Create NewsComments model** - New model for storing Hacker News comments
   - **Acceptance Criteria**: NewsComments model created with proper fields and indexes
   - **Relevant Files**: `packages/hacker-news-ingest/src/models/NewsComments.ts` (new file)
   - **Dependencies**: None
```

#### Implementation Notes Structure Format:
```markdown
# [Feature Name] - [Phase Name] Implementation Notes

## Session Summary
- **Date**: [Current date]
- **Completed To-dos**: List of finished items
- **Current Status**: Overall progress summary

## Implementation Details
### [To-do Title]
- **What was implemented**: Detailed description
- **Files modified**: List of changed files
- **Key decisions**: Important choices made
- **Discoveries**: Unexpected findings or learnings
- **Challenges**: Issues encountered and how they were resolved

## Next Steps
- **Recommended next to-dos**: Specific items to work on next
- **Dependencies**: What needs to be done before proceeding
- **Notes**: Any important considerations for future work
```

## Feature Context Awareness
When any of these commands are used, the AI should:
1. **Read documentation first**: Always read relevant files from `/docs/` folder before starting work to understand project guidelines and patterns
2. **Remember the feature-name** throughout the entire chat session
3. **Maintain context** of the current feature being worked on
4. **Reference existing files** in the feature folder (`/specs/[feature-name]/`)
5. **Auto-suggest related commands** based on current progress
6. **Track implementation progress** across multiple interactions

## Critical Instructions
1. **DO NOT** start implementing the PRD immediately
2. **ALWAYS** ask clarifying questions first
3. Use the user's answers to improve and complete the PRD
4. **Maintain feature context** once established through any command
5. **Reference existing feature documentation** when available
6. Provide options in lists for easy user responses
7. Focus on "what" and "why", not "how"