Starter prompts
for your library.

Review this pull request for correctness, edge cases, and maintainability. Call out risky assumptions before suggesting changes.

[PASTE_DIFF_OR_CODE_HERE]

Explain what this code does and how it works. Cover the intent, the approach, and any non-obvious decisions. Then call out anything that looks fragile or could be improved.

[PASTE_CODE_HERE]

Write unit tests for this function. Cover the happy path, edge cases, and error conditions. Use the same testing framework already visible in the file.

[PASTE_FUNCTION_HERE]

I'm getting this error. Explain what's causing it, where the most likely source is, and what to check first.

Error: [PASTE_ERROR_HERE]

Context: [BRIEFLY_DESCRIBE_WHAT_YOU_WERE_DOING]

Review this code and suggest how to simplify or improve it. Focus on readability and maintainability. Don't refactor for hypothetical future requirements — only what's clearly better now.

[PASTE_CODE_HERE]

Write a clear commit message for this change. Lead with the type (feat/fix/refactor/chore) and a one-line summary. Add a short body paragraph explaining why this change was made if it's not obvious from the diff.

[PASTE_DIFF_HERE]

Help me write a clear, non-technical explanation of this for a PM or executive. Skip the jargon. Lead with the impact or decision needed, then explain the background.

Topic: [DESCRIBE_WHAT_YOU_NEED_TO_EXPLAIN]

Summarize these meeting notes into clear action items, decisions made, and open questions. Group by topic if the meeting covered multiple subjects. Each action item should include who owns it if mentioned.

[PASTE_NOTES_HERE]

Write clear technical documentation for this. Cover what it does, how to use it, the key parameters or options, and at least one usage example. Audience: engineers onboarding to this codebase.

[DESCRIBE_OR_PASTE_WHAT_NEEDS_DOCUMENTATION]

Write a concise status update based on these notes. Cover: what's done, what's in progress, what's blocked, and what's next. Keep it to the point — this is for a team or manager, not a detailed report.

[PASTE_YOUR_PROGRESS_NOTES_HERE]

Explain [CONCEPT] clearly. Start with a one-sentence definition, then give me the intuition behind it, then a practical example. Assume I'm a software engineer who knows the basics but hasn't worked with this specific thing.

Compare [OPTION_A] and [OPTION_B] for [USE_CASE]. What does each do well, where does each fall short, and what should I ask myself before choosing? Don't just list features — explain the real tradeoffs.

I'm planning to [DESCRIBE_YOUR_APPROACH]. What's the biggest risk? What am I missing? What would you do differently and why?

Summarize this. Pull out the key points and what I should actually take away from it. If there's something I should act on or remember, call that out separately at the end.

[PASTE_CONTENT_HERE]

Help me think through this clearly before I start building or writing. I'll describe the problem and my current thinking — you point out what I'm missing, where I'm making assumptions, and what I should clarify first.

Problem: [DESCRIBE_THE_PROBLEM]
My current thinking: [DESCRIBE_YOUR_APPROACH]

Write a short technical spec for this. Cover: the problem being solved, the proposed approach, key constraints or assumptions, and open questions. Keep it to what's needed to get alignment — not a novel.

Feature or change: [DESCRIBE_WHAT_YOU_RE_BUILDING]

Break this down into concrete, sequenced steps I can work through. Each step should be small enough to complete in one sitting. Call out any dependencies between steps.

Goal: [DESCRIBE_WHAT_YOU_RE_TRYING_TO_DO]