What this prompt does
This prompt builds a library of reusable Cursor Notepads your team runs daily. You set [notepad_count] and the [framework], and the AI creates an API Endpoint notepad using [api_pattern] with validation, error handling, and tests; a Component notepad that scaffolds a [component_type] with a props interface, state management, and a Storybook story; a Database Migration notepad that generates a migration with indexes, foreign keys, and rollback from a plain-English table description; a structured Bug Fix notepad that collects error info, reproduction steps, and file references before asking for a fix; and a Refactor notepad that turns a code-smell description into a step-by-step safe refactoring plan.
The structure works because Notepads stop you rewriting the same scaffolding prompts on every project. Each template bakes in your standards — validation, error handling, tests — so AI output starts from your conventions rather than generic defaults you then have to correct. Every notepad includes which @-mentions to add and how to customize the placeholder values, because the same template performs far better with the right context attached. Organizing the whole set by category (backend, frontend, devops, debugging) with naming conventions is what actually drives adoption: a pile of unnamed notepads goes unused, while a categorized, predictably named set is easy for the whole team to find and run on a busy day.
When to use it
- You keep rewriting the same scaffolding prompts across projects and want them saved as reusable templates
- Your team should generate endpoints, components, and migrations from one shared standard
- You want AI output to start from your conventions rather than generic boilerplate you correct each time
- A structured Bug Fix template would make your team's debugging requests more consistent
- You want a repeatable, safe Refactor plan generated from a code-smell description
- You need the notepads organized by category so the team will actually adopt and use them
Example output
You get [notepad_count] notepad templates: an API Endpoint notepad built on [api_pattern], a Component notepad for a [component_type] with props interface and Storybook story, a Database Migration notepad driven by plain-English descriptions, a structured Bug Fix notepad, and a Refactor notepad. Each includes its recommended @-mentions, placeholder customization notes, and a category label with naming conventions.
Pro tips
- Bake your real standards into each template — validation, error handling, tests — so generated output needs less rework
- Keep placeholders obvious and documented so teammates customize them correctly rather than guessing
- Specify the
@-mentions per notepad; the same template performs far better with the right context attached - Organize by category and naming convention from the start, or the library quietly will not get used
- Start with the notepads you reach for most — endpoint, component, migration — before adding niche ones
- Revisit templates when your
[framework]conventions change so the scaffolding does not drift stale over time
