5 working prompts for business, marketing, sales, coding, and research. Copy and adapt to your context.
A Good Bug Report
Coding
Turns 'it doesn't work for me' into a reportable bug with steps.
Become a QA engineer. Help the user write a good bug report.
Extract from the input:
1. What exactly broke (one sentence)
2. Steps to reproduce (a numbered list)
3. Expected behavior
4. Actual behavior
5. Environment: OS, version, browser, time
6. Logs / screenshots — a list of what would be useful to attach
If data is missing — ask 3-5 clarifying questions before composing the report.
Example: Any non-technical user can compose a proper bug report through this prompt.
Model: Claude / GPT·Difficulty: Beginner
#qa#engineering
A Strict Code Review
Coding
Does a code review with a focus on correctness, readability, and security.
Do a code review for the following diff.
Rules:
- No "looks good!" without justification
- A clear split: BLOCKERS / SHOULD-FIX / NIT
- Under each item, 1-2 sentences and, if applicable, an example fix
- Special attention: security, edge cases, error handling, mutation of shared state
- At the end — 1 line with a summary "merge as-is / merge after fixes / needs rework"
<diff>:
<…>
Example: Get a second opinion before merging a PR.
Model: Claude·Difficulty: Intermediate
#code-review#engineering
Generating Tests from Code
Coding
Writes unit tests starting from edge cases, not the happy path.
Generate unit tests for a function.
Rules:
- Start with 3 edge cases and a description of why each matters
- Then the happy path (minimum)
- Use the framework specified in the input (e.g., vitest/pytest)
- Don't invent behavior that isn't in the code — if something is unclear, ask
Input: the function code and the framework.
Example: Cover tests for a function that has none.
Model: Claude·Difficulty: Intermediate
#testing#engineering
Parsing Legacy Code
Coding
Explains a confusing piece of legacy code in layers: what, why, which dependencies.
Explain legacy code in layers.
Structure of the explanation:
1. What this function/module does (one sentence)
2. What its input/output contracts are
3. Which external dependencies (DB, network, files)
4. Which assumptions about the input data and where they may break
5. Where the "bombs" are: code that looks safe but isn't
Input: the code.
Example: Enter a new project and figure out someone else's code.
Model: Claude·Difficulty: Intermediate
#engineering#legacy
Refactoring Plan
Coding
Prepares a refactoring plan with steps, risks, and test coverage at each stage.
Prepare a refactoring plan for a module.
Structure:
- The refactoring goal (one sentence)
- What we are NOT changing (behavior, contract)
- Steps (5-10), each atomic and independently releasable
- Under each step: which tests must pass, which risks
- A roll-back plan
Input: a description of the module and the problem.