|
| 1 | +--- |
| 2 | +name: 010-java-design-plans |
| 3 | +description: Use when it is creatin a plan using Plan model and enchance the creation of structured design plans in Cursor Plan mode for Java implementations. Use when the user wants to create a plan, design an implementation, structure a development plan, or use plan mode for outside-in TDD, feature implementation, or refactoring work. |
| 4 | +--- |
| 5 | + |
| 6 | +# Java Design Plan Creation |
| 7 | + |
| 8 | +Guides the process of creating a structured plan using Cursor Plan mode. Plans follow a consistent section structure suitable for Java feature implementation, refactoring, or API design. |
| 9 | + |
| 10 | +--- |
| 11 | + |
| 12 | +## Plan Mode Workflow |
| 13 | + |
| 14 | +1. **Enter Plan mode** (or use plan-related commands) before creating the plan. |
| 15 | +2. **Gather context**: Read specs, existing code, and acceptance criteria. |
| 16 | +3. **Draft the plan** using the structure below. |
| 17 | +4. **Iterate**: Refine tasks, dependencies, and file checklist as needed. |
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | +## Plan File Structure |
| 22 | + |
| 23 | +Plans use Markdown with YAML frontmatter. Save to `.cursor/plans/YYYY-MM-DD_<plan_name>.plan.md` (prefix with creation date). |
| 24 | + |
| 25 | +### YAML Frontmatter |
| 26 | + |
| 27 | +```yaml |
| 28 | +--- |
| 29 | +name: <Short Plan Name> |
| 30 | +overview: "<One-line description: what, approach, key constraints.>" |
| 31 | +todos: [] |
| 32 | +isProject: false |
| 33 | +--- |
| 34 | +``` |
| 35 | + |
| 36 | +### Required Sections |
| 37 | + |
| 38 | +| Section | Purpose | Content | |
| 39 | +|---------|---------|---------| |
| 40 | +| **Title** | Problem/feature identifier | `# Problem N: [Name] Implementation Plan` | |
| 41 | +| **Requirements Summary** | Business context | User story, key business rules, acceptance criteria | |
| 42 | +| **Approach** | Strategy and flow | Named approach (e.g., London Style TDD), diagram (Mermaid) | |
| 43 | +| **Task List** | Ordered implementation steps | Table with #, Phase, Task, TDD, Status | |
| 44 | +| **Execution Instructions** | How agents must execute | Update task Status after each task before advancing | |
| 45 | +| **File Checklist** | What files and when | Order, File path, When (TDD phase) | |
| 46 | +| **Notes** | Extra context | Package layout, conventions, edge cases | |
| 47 | + |
| 48 | +--- |
| 49 | + |
| 50 | +## Section Templates |
| 51 | + |
| 52 | +### Requirements Summary |
| 53 | + |
| 54 | +```markdown |
| 55 | +## Requirements Summary |
| 56 | + |
| 57 | +**User Story:** [One sentence describing the user goal.] |
| 58 | + |
| 59 | +**Key Business Rules:** |
| 60 | +- **[Rule name]:** [Concrete rule] |
| 61 | +- **[Filtering / Conversion / Timeout]:** [Behavior] |
| 62 | +- **Expected result:** [Specific value or behavior when applicable] |
| 63 | +``` |
| 64 | + |
| 65 | +### Approach (with Diagram) |
| 66 | + |
| 67 | +````markdown |
| 68 | +## [Approach Name] (e.g., London Style Outside-In TDD) |
| 69 | + |
| 70 | +[Brief description of the strategy.] |
| 71 | + |
| 72 | +```mermaid |
| 73 | +flowchart LR |
| 74 | + subgraph [Flow Name] |
| 75 | + A[Step 1] --> B[Step 2] |
| 76 | + B --> C[Step 3] |
| 77 | + end |
| 78 | +``` |
| 79 | +```` |
| 80 | + |
| 81 | +### Task List Table |
| 82 | + |
| 83 | +```markdown |
| 84 | +## Task List ([Approach] Order) |
| 85 | + |
| 86 | +| # | Phase | Task | TDD | Status | |
| 87 | +| --- | ------- | ------------------------------------------------------------- | ---- | ------ | |
| 88 | +| 1 | Setup | [First task] | | | |
| 89 | +| 2 | RED | [Write failing test] | Test | | |
| 90 | +| 3 | GREEN | [Implement minimal solution] | Impl | | |
| 91 | +| 4 | Refactor| [Polish, verify] | | | |
| 92 | +``` |
| 93 | + |
| 94 | +**Phases:** Setup, RED (write failing test), GREEN (pass test), Refactor. Use the **Status** column to track completion (e.g., `✔`, `Done`, or `✓` when finished). |
| 95 | + |
| 96 | +### Execution Instructions (Required) |
| 97 | + |
| 98 | +Include this section in every plan. It reminds agents to update the task list during execution: |
| 99 | + |
| 100 | +```markdown |
| 101 | +## Execution Instructions |
| 102 | + |
| 103 | +When executing this plan: |
| 104 | +1. Complete the current task. |
| 105 | +2. **Update the Task List**: set the Status column for that task (e.g., ✔ or Done). |
| 106 | +3. Only then proceed to the next task. |
| 107 | +4. Repeat for all tasks. Never advance without updating the plan. |
| 108 | +``` |
| 109 | + |
| 110 | +### File Checklist Table |
| 111 | + |
| 112 | +```markdown |
| 113 | +## File Checklist ([Approach] Order) |
| 114 | + |
| 115 | +| Order | File | When (TDD) | |
| 116 | +| ----- | ------------------------------------------------- | ----------------------- | |
| 117 | +| 1 | `path/to/File1.java` | Setup | |
| 118 | +| 2 | `path/to/Test.java` | RED — write first | |
| 119 | +| 3 | `path/to/Impl.java` | GREEN — implement | |
| 120 | +``` |
| 121 | + |
| 122 | +--- |
| 123 | + |
| 124 | +## London Style (Outside-In) TDD Pattern |
| 125 | + |
| 126 | +For feature implementation, prefer **outside-in** order: |
| 127 | + |
| 128 | +1. **Acceptance/integration test** (RED) — defines API and expected behavior. |
| 129 | +2. **Delegate/controller** (GREEN) — minimal wiring. |
| 130 | +3. **Service unit test** (RED) — business logic in isolation. |
| 131 | +4. **Service implementation** (GREEN) — with fake/stub dependencies. |
| 132 | +5. **Client test** (RED) — external calls. |
| 133 | +6. **Client implementation** (GREEN) — wire real client. |
| 134 | +7. **Refactor** — remove fakes, add error handling, verify `mvn clean verify`. |
| 135 | + |
| 136 | +--- |
| 137 | + |
| 138 | +## Plan Execution Workflow |
| 139 | + |
| 140 | +When **executing** a plan, follow this discipline for every task: |
| 141 | + |
| 142 | +1. **Run** the current task (e.g., Task 1). |
| 143 | +2. **When the task finishes**, immediately update the plan file: set the Status column for that task (e.g., ✔ or Done or ✓). |
| 144 | +3. **Then** proceed to the next task. |
| 145 | +4. Repeat steps 1–3 for all tasks in order. |
| 146 | + |
| 147 | +Never advance to the next task without updating the task list. This keeps progress visible and lets the plan file reflect the current state. |
| 148 | + |
| 149 | +--- |
| 150 | + |
| 151 | +## Plan Creation Checklist |
| 152 | + |
| 153 | +Before finalizing: |
| 154 | + |
| 155 | +- [ ] Frontmatter has `name`, `overview`, `todos`, `isProject`. |
| 156 | +- [ ] Requirements Summary includes user story and key business rules. |
| 157 | +- [ ] Approach section names the strategy and includes a Mermaid diagram. |
| 158 | +- [ ] Task list is ordered (Setup → RED → GREEN → Refactor) with Status column. |
| 159 | +- [ ] **Execution Instructions** section is included (update Status after each task before advancing). |
| 160 | +- [ ] File checklist maps files to TDD phases. |
| 161 | +- [ ] Notes cover package layout, conventions, and constraints. |
| 162 | +- [ ] Plan file path is `.cursor/plans/YYYY-MM-DD_<name>.plan.md`. |
0 commit comments