A Cursor prompt library should preserve repeatable engineering workflows without preserving stale details from the repository where the prompt was first written.
The best candidates are tasks you perform across codebases: reviewing a change, investigating a bug, planning a migration, or checking a release. Save the method. Supply the current code and constraints when you run it.
Choose workflows that repeat
Good library candidates have a stable sequence of questions even when the code changes:
- review an authentication change for missing failure cases
- turn an error report into a minimal reproduction plan
- inspect a refactor for behavior drift
- prepare a release-readiness checklist
- explain an unfamiliar module from entry point to side effects
Avoid saving a one-off command that names temporary branches, local paths, or ticket numbers. Those details belong to the current run.
Give every coding prompt clear boundaries
Developer prompts can sound confident while working from incomplete context. A reusable file should say what evidence the assistant must inspect and what it must not assume.
# Review a refactor for behavior drift
Use when: implementation structure changed but intended behavior did not.
## Required input
- changed files or diff
- relevant tests
- original behavior or acceptance criteria
## Prompt
Trace each changed behavior from input to observable output. Identify any
behavioral difference, missing test, or assumption that cannot be verified
from the supplied code.
## Output contract
List findings by severity with file references. Separate verified regressions,
test gaps, and unanswered questions. If no issue is found, state what was checked.
This file does not contain the codebase. It contains the review method and the evidence requirements.
Keep repository context replaceable
Use placeholders for details that change:
<changed_files><expected_behavior><runtime_constraints><test_command>
Placeholders make missing inputs visible. They also reduce the chance that an old service name or test command silently travels into a new project.
Separate reusable prompts from repository rules
A cross-project debugging method and a repository-specific convention serve different purposes. Keep durable workflows in the prompt library. Keep rules that belong to one codebase with that codebase, where they can be reviewed alongside the implementation.
If a prompt depends on both, write the library file so it asks for the repository rules as an input. That keeps the shared method portable without pretending every project works the same way.
Do not store secrets in prompt files
Prompts should name the kind of evidence they need, not include production tokens, customer data, or copied environment files. Replace sensitive values with descriptions or sanitized examples before saving.
Retrieve by task, then paste with context
Promptlight indexes Markdown prompts in a local vault and lets you copy the reusable instructions into Cursor or another editor. It does not read the repository for you or connect directly to Cursor. You choose the relevant code and context at run time.
That separation keeps the library useful across projects: Promptlight handles the local prompt source and retrieval; the coding tool handles the code context you provide.
See Prompt Manager for Developers for the product workflow and Markdown Prompt Library for the underlying file model. For a review method that stays honest about missing evidence, continue with Run a Prompt Review Workflow.
