Бібліотека промптів: готові промпти для роботи в ChatGPT і Claude

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.

Prepares a table of players in a segment with sources and dates.

Do a market scan for a segment.

Conditions:
- Use Perplexity / web search if available
- Under each item — a link to the source
- Mark estimated/unconfirmed numbers as [estimate]
- Don't make up ARR, revenue, headcount
- Mark the last-updated date of each source

Input:
- Segment: <…>
- Geography: <…>
- What we want to understand: <…>

Output: a markdown table with columns — Player | Description | Price | Strengths | Weaknesses | Source.

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>:
<…>

Produces a structured summary of a paper / preprint.

Produce a summary of an academic paper for a busy reader: short and in the structure below.

Structure:
1. The research question (1 sentence)
2. What's new compared to prior work
3. Methodology (3-5 lines)
4. The main result
5. Limitations the authors acknowledge
6. How it's useful to a practitioner (if applicable)
7. What you'd want to verify further / what the authors don't insist on

Input: the text or a link to the paper.

Prepares a newsletter issue with a single focus, without 'let's talk about'.

Prepare an email newsletter issue.

Conditions:
- One main point per email
- Subject ≤55 characters, without the words "exclusive", "secret"
- The first paragraph must show why to read on
- Length 250-450 words
- 1 link / CTA, no more
- At the end — a PS line with one useful tidbit

Input:
- Topic: <…>
- Context: <…>

Prepares a set of slides / talking points for a board meeting from rough data.

Play the role of chief of staff. Prepare a 60-minute board meeting agenda.

Input:
- Meeting goal: <…>
- Attendees: <…>
- Context of the last quarter: <…>
- Open questions: <…>

Output:
1. An agenda with timings (minutes)
2. For each block: 3 key talking points
3. A list of decisions to extract from the board
4. A list of appendices (metrics, contracts, reports) to prepare

Don't write "we are pleased to present" etc. — a neutral operational tone.

Breaks customer feedback into clusters by topic and sentiment.

Break customer feedback into clusters.

Steps:
1. Read the input (an array of reviews)
2. Identify 5-8 topics
3. Under each topic: a short description, volume (how many reviews fell into it), sentiment (positive/negative/neutral)
4. 2-3 quotes in each cluster (verbatim)
5. At the end — the top 3 actions the product could take

Don't make up reviews. If there's little data, say so.

Prepares a competitor profile: product, price, marketing, weak spots.

Do a deep dive on the company <name>.

Cover:
1. Business model and segments
2. Price and tiers (if public)
3. Key products and features
4. Positioning on the site / in marketing
5. Weak spots: what they do NOT do (from their own UX and materials)
6. What they lean on in sales (cases, integrations, brand)
7. A list of their clients / case studies — a list + links
8. Their public moves over the last 6 months

Sources: public only. Mark "[unverified]" if you didn't find confirmation.

Prepares an interview guide for the JTBD / Mom Test methodology without leading questions.

Prepare a customer interview guide using the JTBD + The Mom Test method.

Conditions:
- 10-12 questions, moving from past experience to context, to pain, to alternatives
- Leading "would you want X?" questions are banned
- Every question must extract a fact, not an opinion
- Add a hint for the interviewer about an escape hatch ("tell me how it went the last time")

Input:
- Segment: <…>
- Pain hypothesis: <…>
- What needs to be tested: <…>

Prepares a discovery call structure using the MEDDIC / SPIN methodology.

Prepare a plan for a 30-minute discovery call with a lead.

Structure:
1. 2 min: context and agreement on the format
2. 5 min: the current situation (how they solve the task now)
3. 10 min: the pain and its cost (ask for concrete numbers)
4. 5 min: decision criteria, the process, who else is involved
5. 5 min: timeline and budget
6. 3 min: the next step

Under each block — 2-3 good open questions via SPIN/MEDDIC.

Input:
- Lead: <…>
- What we're selling: <…>

Translates a document and adapts it to another jurisdiction and culture.

Localize a document.

Steps:
1. First translate literally
2. Then go through again and adapt: units of measurement, currency, legal terms, cultural references, names, and date formats
3. Mark decisions where localization conflicts with a literal translation — leave comments in [brackets]

Input:
- Document: <…>
- Target language / market: <…>
- Document type: <…>

Turns meeting notes into a follow-up email with next steps.

Write a follow-up email after a meeting.

It must contain:
- 1 line: thanks without fluff
- 3-5 bullets: what we heard
- 2-3 bullets: what we'll do on our side
- 1-2 bullets: what's needed from the client
- The date of the next step

Input (meeting notes):
<…>

Writes unit tests: edge cases first, then 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.

Helps phrase a search string for Sales Navigator and ICP filters.

Help me build ICP filters for LinkedIn Sales Navigator.

Give:
- 5-7 boolean strings (with AND / OR) for the search
- At least 3 "trigger" indicators (recent events, hiring, investments, laws) — where to look for them
- 3-5 negative filters (companies we exclude)
- Alternative titles that mean the same role

Input:
- Segment: <…>
- What we're selling: <…>

Prepares a draft of an internal policy (e.g., an AI-use policy).

Prepare a draft of an internal company policy.

Structure:
- Why this policy exists
- Whom it applies to
- What's allowed / forbidden (as a list)
- The exception procedure
- Who's responsible for maintaining it
- The effective date

Style: short sentences, no legal clichés. At the end — an "FAQ for employees" section.

Input:
- Policy topic: <…>
- Company context: <…>

Prepares a clear JD without the clichés 'a dynamic team' and 'limitless opportunities'.

Write a job description for a position based on the inputs.

Hard rules:
- No "rockstar", "ninja", "unlimited potential"
- No "we're a fast-paced team" without explaining what that means
- 3 sections: "What you'll do in the first 90 days", "What will be easy" / "What will be hard", "What you must be able to do"
- One paragraph about the salary band if given; otherwise — a note [salary band TBD]
- End with an honest "this isn't for you if…"

Input:
<role, seniority, team, key projects, hard requirements, salary>

Prepares the structure and a draft of the landing page copy.

Prepare the structure and a draft of a landing page.

Sections (in this order):
1. Hero: H1 (≤70 characters) + 1 subhero sentence + 1 CTA
2. Pain: 3 pain scenarios
3. What we do: 3 key capabilities, one line each
4. Social proof: what needs to be prepared (logos, numbers, quotes) — a list
5. How it works: 3-4 steps
6. Pricing: one sentence about the model
7. FAQ: 5 questions with answers
8. Final CTA

Banned: "transform your", "unlock your potential", "next-gen".

Turns a note about a real case into a LinkedIn post without copywriter clichés.

Write a LinkedIn post in my voice.

Hard rules:
- Don't use "Here's what I learned", "And here's the kicker", "Pro tip:"
- Don't use emoji at the start of lines as bullets
- Don't break into one word per line
- Length: 700-1100 characters
- Ending: one question to the audience or one practical tip
- Style: my live voice, no hype

Input (a note about the situation):
<…>

From a meeting transcript/notes, assembles a task list with owners and deadlines.

Turn meeting notes into tasks.

Each task:
- A title (action verb + object)
- An owner
- A deadline
- A definition of done

Also:
- A list of open questions where no decision was made
- A list of decisions that were made
- What we definitely are NOT doing (if that came up in the meeting)

If an owner or deadline isn't named — write [TBD].

Prepares a structured monthly investor update from a set of raw notes and metrics.

You are a co-founder writing a monthly investor update. Style: calm, concrete, no hype and no epithets.

Structure:
1. TL;DR (3 lines)
2. Highlights: what worked
3. Lowlights: what didn't work and what we're changing
4. Metrics: MRR, new customers, churn, runway
5. Asks for investors — maximum 3
6. What we plan for next month

Input:
<paste raw notes, metrics, wins, fails>

Make it black-and-white, no marketing phrasing. If data is missing — mark it "[need to clarify]" instead of making it up.

Gives 3 responses to an objection, each from a different angle.

I'm handling an objection from a client. Give 3 different responses.

Conditions:
- One response — via a question back
- One response — via a number or a fact
- One response — via acknowledging the risk
- No "I totally understand", "great question" at the start

Input:
- Objection: <…>
- Deal context: <…>

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.

Helps fit product positioning into a 'for whom / against whom / why' matrix.

You are a product marketer. Help fit the positioning into a table.

Fill in:
- Who the target audience is (1-2 segments)
- What concrete task we solve
- Alternatives, including "do nothing"
- What our unique promise is
- The 3 main objections and how we close them
- What we deliberately do NOT do

If the input has little data — mark "[need to clarify with the founder]". Don't make up facts about the business.

Turns strategic goals into a draft OKR with measurable key results.

You are an operations partner. Help turn strategic themes into quarterly OKRs.

Rules:
- 3-5 objectives maximum
- 3 key results per objective
- KRs are measurable (a number, a date, a binary fact)
- Don't use vague "improve", "increase" without a number
- If the input doesn't justify a KR — ask for clarification, don't make it up.

Input (strategy and context):
<paste>

Output format: a markdown table objective → KR.

Assembles a structured RFP response from company materials.

Prepare a draft RFP response.

Principles:
- Every answer must reference a source (an internal document, a case, a metric)
- If there's no data — mark [need to confirm]
- Don't use "world-class", "best-in-class"
- Structure: RFP question → short answer → expanded answer (1-2 paragraphs) → evidence

Input:
- RFP questions: <…>
- Our company context: <…>
- Cases and metrics: <…>

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.

Prepares an SEO article outline from a query and the search results.

Generate an SEO article outline.

Input:
- Target query: <…>
- ICP: <…>
- What we want to sell at the end: <…>

Output:
1. H1 + 3 meta description variants (≤155 characters)
2. An H2/H3 tree (8-12 points)
3. Under each H2: 1 sentence about "what the reader should take away"
4. A list of facts/numbers to find and confirm (don't make them up)
5. A CTA at the end of the article

Style: editorial, no fluff and no epithets.

Takes a regulatory text (a law, a guideline) and assembles a summary for the business.

Produce a practical summary of a regulatory document.

Structure:
1. What it regulates and whom it affects
2. Key requirements (5-10 points)
3. Deadlines and transitional provisions
4. Sanctions
5. What the company must do in the first 30/60/90 days
6. What to check with lawyers (explicit ambiguities)

Don't interpret disputed provisions as unambiguous. Use phrasing like "probably", "requires clarification with a lawyer".

Input:
<the document or a link>