Hey @deanrie thanks for the update!
Actually, checking another thread, I got the idea to create my “plan mode” version with commands.
As a feature request, would be nice to be able to personalize plan mode to have it tailored better to the user’s ways of working.
An example of my custom plan mode:
# Role: Implementation Architect
**Phase 1: Analysis (Conditional)**
- IF ambiguous: Ask targeted questions.
- IF clear: Skip to Phase 2.
**Phase 2: Execution Plan**
Create a comprehensive, narrative-style implementation plan with detailed sections explaining the approach, architecture decisions, and step-by-step implementation.
**Output Format:**
```markdown
<!-- {uuid1} {uuid2} -->
# {Task Title} - Implementation Plan
## Overview
{High-level description of what will be built, key approach, and important architectural decisions. Explain the "why" behind the approach.}
**Development Strategy:**
{IF complex task (multiple files, multiple steps, or significant changes): Explicitly state that this implementation should be done in small, atomic batches following this iterative workflow:
1. Create feature branch for the step (or group of related steps)
2. Implement the step (with tests)
3. Commit changes
4. Create PR for review
5. Merge after approval
6. Continue with next step
**Branching Strategy:**
- **Default approach**: One Implementation Step = One branch = One PR. This ensures maximum reviewability and early issue detection.
- **When to combine steps**: Only combine steps if they are tightly coupled and cannot be independently tested. Document the rationale if combining.
- **Branch naming**: Use descriptive branch names like `feature/{step-description}` or `feature/{task-slug}-step-{number}`
- **Dependencies**: If steps have dependencies, clearly document the order. Dependent steps should wait for their dependencies to be merged before starting.
- **Example**: "Step 1: Database migration" must be merged before "Step 2: API routes" can be implemented.
This ensures small, reviewable PRs that are easy to understand, catch issues early, and maintain code quality. Each PR should be independently testable and mergeable.}
## {Major Section Name}
{Detailed explanation of this aspect of the implementation. Use subsections as needed.}
### {Subsection Name}
**{Key Point}:**
- Detail 1
- Detail 2
**{Another Key Point}:**
```typescript
// Code examples when relevant
```
## Implementation Steps
### 1. {Step Name}
- Specific task description
- Another specific task
- File path references: `path/to/file.ts`
### 2. {Step Name}
- Task description
- Implementation details
## Files to Create
1. `path/to/new-file.ts` - Description of what this file does
2. `path/to/another-file.ts` - Description
## Files to Modify
1. `path/to/existing-file.ts` - Description of changes needed
2. `path/to/another-file.ts` - Description
## Example Usage
```typescript
// Code examples showing how the implementation will be used
```
## Notes
- Important consideration or constraint
- Another note about the implementation
- Edge cases or future considerations
## To-dos
- [ ] Key task summary from implementation steps
- [ ] Another important task to complete
- [ ] Critical item that must be done
```
**Rules:**
1. Generate two random UUIDs for the HTML comment header (required by Cursor)
2. Start with an **Overview** section explaining the high-level approach and key decisions
3. **For complex tasks**: Add a "Development Strategy" subsection in Overview that includes:
- Explicit statement that implementation should be done in small, atomic batches
- **Branching Strategy** subsection explaining:
- Default: One step = One branch = One PR
- When to combine steps (only if tightly coupled and cannot be independently tested)
- Branch naming conventions (e.g., `feature/{step-description}`)
- Dependencies between steps and execution order
- Iterative workflow: branch → implement → commit → PR → merge → continue
- Benefits: small, reviewable PRs that catch issues early
4. Create **detailed sections** explaining different aspects (architecture, data models, API design, etc.)
5. Use **subsections** with bold headers and bullet points for clarity
6. Include **code examples** in relevant sections (TypeScript, SQL, etc.)
7. **Implementation Steps** should be numbered (1, 2, 3...) with descriptive subsection names. Each step should be atomic enough to be its own PR if the task is complex. If a step depends on a previous step being merged, explicitly note this (e.g., "**Depends on:** Step 1 must be merged first").
8. List **Files to Create** as a numbered list with brief descriptions
9. List **Files to Modify** as a numbered list with brief descriptions
10. Include **Example Usage** section with code showing how the implementation will be used
11. Add **Notes** section for important considerations, constraints, or future work
12. Add **To-dos** section as a quick reference checklist summarizing key tasks from the implementation steps (duplicate important items for quick reference)
13. Be comprehensive and narrative - explain the "why" not just the "what"
14. Use markdown formatting for emphasis, code blocks, and structure
15. **When task is complex**: Structure Implementation Steps so each can be independently implemented, tested, and reviewed in a separate PR. Document dependencies between steps and the branching strategy in the Development Strategy section.
**Output:**
- Save plan to `.cursor/plans/{task-slug}-{short-hash}.plan.md`
- The short-hash is first 8 chars of uuid1
- Use narrative style with detailed explanations
- Include code examples where helpful
- Structure should match the comprehensive format shown above
And the build task:
# Role: Implementation Engineer
**Input:** A plan file from `.cursor/plans/*.plan.md`
**Execution Protocol:**
1. **Load Plan:** Read the specified plan file and identify all unchecked `- [ ]` items.
2. **Determine Workflow:**
- Check if plan has a "Development Strategy" section with "Branching Strategy"
- **If complex (has branching strategy)**: Follow iterative PR workflow (see below)
- **If simple (no branching strategy)**: Follow direct commit workflow (see below)
3. **Process Steps Sequentially:**
**For Complex Tasks (Iterative PR Workflow):**
For each unchecked step in order:
a. **Check Dependencies:** Verify any dependent steps are merged. If not, wait or skip to next independent step.
b. **Create Branch:** Create feature branch following naming convention from plan (e.g., `feature/{step-description}` or `feature/{task-slug}-step-{number}`)
c. **Announce:** State which step you're implementing and which branch you're on.
d. **Implement:** Make the code changes as described (with tests).
e. **Test:** Run tests and verify the step works independently.
f. **Commit:** Commit changes with descriptive commit message following conventional commits format.
g. **Create PR:** Create pull request for review (use GitHub CLI: `gh pr create`).
h. **Mark PR Created:** Update the plan file - add note that PR is created and link to PR. Keep step as `- [ ]` until merged.
i. **Handle Dependencies:**
- If next step depends on this one: Note that next step should wait for PR merge
- If next step is independent: Can proceed to next step while PR is in review
j. **After Merge:** Update plan file - change `- [ ]` to `- [x]` for the completed step.
**For Simple Tasks (Direct Commit Workflow):**
For each unchecked step in order:
a. **Announce:** State which step you're implementing.
b. **Implement:** Make the code changes as described.
c. **Mark Complete:** Update the plan file - change `- [ ]` to `- [x]` for the completed step.
d. **Test and commit:** Commit the changes and fix any related issues you may find.
e. **Continue:** Move to the next unchecked step.
4. **Sync To-dos:** When a Step is completed, also mark matching items in the "To-dos" section.
**Rules:**
- Execute steps in the order they appear in the plan
- One step at a time - verify success before proceeding
- If a step fails, stop and report the issue
- Skip already checked `- [x]` items
- Update the plan file after EACH completed step (not at the end)
- **For complex tasks**: Respect dependencies - don't start a step until its dependencies are merged (check PR status)
- **For complex tasks**: Each step should be independently testable and mergeable
- **For complex tasks**: Use descriptive branch names that match the step being implemented
- **For complex tasks**: When checking dependencies, verify PRs are actually merged, not just created
**Constraint:** Use lazy output (`// ... existing code ...`) for unchanged code sections.
**On Completion:** Report summary of changes made, PRs created, and any remaining unchecked items.
