prompts

I have a task to [DESCRIBE FEATURE/BUG]. Goal: Provide all context needed for a junior developer to implement this without asking further questions. Instructions:
1. Do not write any code or modify the codebase yet.
2. Explore the codebase to understand existing systems, data models, and patterns relevant to this task.
3. Return your findings in markdown document with these sections:
    * Files: List of relevant files and their roles
    * Data Structures: Key types, interfaces, database schemas involved
    * Patterns: How similar features are implemented (e.g., 'React Query for fetching', 'errors via middleware')
    * Strategy: High-level implementation approach
    * Unknowns: Ambiguities needing resolution Be brutally concise. Use bullet points. Verify by reading code before stating anything.
Constraints: **Do not modify the .cursor/commands/research.md, make your own RESEARCH.MD in the root directory**

We are working on [FEATURE/BUG]. Research has been completed above.
Goal: Provide an implementation checklist in markdown document.
Instructions:
1. Create a checklist with atomic implementation steps.
2. Each step must be:
    * Atomic: One clear action (e.g., 'Create file X', 'Add function Y to file Z')
    * Verifiable: Include a check to ensure it works (e.g., 'Run test X', 'Verify log output')
    * No Code: Instructions only, not actual code
Format:

[ ] Step 1: [Action] - [Verification]
[ ] Step 2: [Action] - [Verification]

Create the file in the root directory, in a PLAN.MD file. Do not implement yet.
Constraints: **Do not modify the .cursor/commands/plan.md. Create your own PLAN.MD in the root directory**

I want to implement the feature. Context: RESEARCH.MD and PLAN.MD have been provided above. Instructions:
1. Execute Step 1 ONLY.
2. Verify it works as described.
3. Mark Step 1 as completed (change [ ] to [x]).
4. STOP and ask for confirmation before proceeding to Step 2.
Do not deviate from the plan. If the plan is wrong, stop and tell me.
**EXCEPTION: If the user says 'do all' you may do all steps at once**.

Task: Find [SPECIFIC ITEM/PATTERN/CODE] in the codebase.

Instructions:
1. Search the codebase for the requested item (file, function, pattern, usage, etc.)
2. Return findings in a brief, concise format:
    * Location: File path and line number
    * Context: Minimal surrounding context (1-2 lines)
    * Count: How many instances found (if multiple)
3. If nothing found, state that explicitly
4. No explanations or suggestions unless specifically asked
5. Format as plain text or simple markdown - no files created

Be specific. Be brief.

Task: Initialize understanding of the [FEATURE/BUG]. The user will then ask you questions relating to this topic.

Instructions:
1. Examine project structure:
    * Project type (monorepo/single, framework, language)
    * Directory organization and module structure
    * Naming conventions (files, variables, directories)
2. Identify architectural patterns:
    * Layers (presentation, business logic, data access)
    * Design patterns (MVC, DDD, microservices, etc.)
3. Map data flow:
    * Data fetching (REST, GraphQL, DB queries)
    * State management (global, local, server, URL)
    * Mutation patterns and error handling
4. Note code conventions:
    * File naming and placement patterns
    * Import styles (absolute/relative, aliases)
    * Code style (classes/functions, declarative/imperative)

Constraints: **Do not make an md file, just clarify your understanding of it and reply with the word 'Ready'**

Write a PR description for these changes following the "Context Engineering" framework.

Do not just list file changes. Instead, structure the response into:

1. **The Context:** A high-level summary of the problem we are solving and the intent behind the changes.
2. **The Plan:** A numbered list of the logical steps taken to implement this (e.g., "1. Refactored the auth hook to allow X..."). For each step, explain the *why*.
3. **Verification:** How to verify this works (tests or manual steps).

Keep it concise and focused on the decision-making process.

Summarize these changes as a modular "Plan Section" for a larger PR.

Structure the output exactly like this so I can copy-paste it:

**[Feature/Module Name]**
* **Intent:** One sentence on what this specific chunk solves.
* **Execution Steps:**
  1. `[Action]` (e.g., Created X component) - *Why: [Reason]*
  2. `[Action]` (e.g., Updated Y hook) - *Why: [Reason]*
  3. `[Action]` (e.g., Added Z test) - *Why: [Reason]*

Focus on the *logical flow* of changes, not just file names.