What this prompt does
This prompt turns the AI into a recipe author rather than a one-off assistant. Instead of asking for a single change, you ask it to produce eight reusable, copy-paste Cursor prompts for the routine engineering tasks you hit every day: tests, refactors, types, JSDoc, hooks migration, lint fixes, error-copy rewrites, and folder READMEs. Each recipe is constrained to 3-5 lines, must reference the file in context, and must state its expected output, so the recipes themselves stay actionable instead of vague.
The structure works because the four context variables tune the recipes to your actual project rather than leaving you with generic boilerplate. [stack] decides whether the type recipe talks TypeScript or something else, [test_framework] makes the test recipe name the right runner and assertions, [style_rules] keeps the lint recipe inside your linter's conventions, and [priority_tasks] nudges the model to sharpen the recipes your team runs most. The constraint that every recipe stays 3-5 lines, references the file in context, and states its expected output is what keeps each one self-contained instead of drifting into vague suggestions. Because the output is a numbered Markdown list, you can paste the whole thing into a pinned recipe file and reuse it keystroke by keystroke, then refine individual recipes over time as your conventions shift.
When to use it
- You want a pinned recipe file so routine Cursor work is one paste away.
- You keep rewriting the same loose prompts for tests and refactors.
- You are onboarding a team to Cursor and want shared, consistent prompts.
- You need recipes that reference the current file rather than generic snippets.
- You are standardising how your team writes types, docs, and error copy.
- You want self-contained prompts that state their expected output up front.
Example output
You get a numbered Markdown list of eight short recipes, each a tight block of 3-5 lines naming the task, referencing the file in context, and stating what it should return. For example, the test recipe names your runner and asks for coverage of the current file's happy path and edge cases, while the README recipe asks for a folder overview scoped to the files present. It reads like a cheat sheet you drop into a cursor-recipes.md file and copy from, not prose explaining how to write recipes.
Pro tips
- Set
[stack]precisely (language plus framework) so the type and hooks recipes target the right syntax. - Match
[test_framework]to what is actually installed, or the test recipe will reference the wrong assertions. - Put your real linter and formatter in
[style_rules]so the lint-fix recipe respects your config. - Use
[priority_tasks]to push the model to refine the recipes you run most, not all eight equally. - Pin the test recipe first; sloppy test prompts cost the most rework.
- Iterate by pasting one recipe back and asking the model to tighten it after a real run.
