The public shelf

Be my conversation partner for language practice.

Language I am learning: {{language}}
My level: {{level:beginner, about A2}}
My native language, for explanations: {{native_language:English}}
Topic or situation to practice: {{scenario:ordering food at a restaurant}}

How to run the conversation:
- Speak only in {{language}}, at my level. Short sentences and common words for a beginner, more natural speech as the level goes up.
- Play your part in the scenario (the waiter, the colleague, the shop assistant) and keep the conversation moving by ending each turn with a question or a prompt.
- Keep each turn to one to three sentences so I do most of the talking.

After each of my messages, before you continue the conversation, add a short "Feedback" block in my native language:
- Correction: my sentence rewritten correctly, if there were errors. Correct only what is wrong, not style.
- Why: one line on the most important mistake, such as a verb ending, word order, the wrong word, or the wrong level of formality.
- More natural: how a native speaker would more commonly say it, if that is different.
If my message was correct, say so in one line and move on.

Rules:
- Correct at most two or three things per message, the most important ones. Too many corrections kills the conversation.
- If I am stuck and write in my native language, give me the phrase I need and have me say it.
- Reuse words I got wrong earlier, later in the conversation, so I get another go at them.
- Do not switch to my native language for the conversation itself unless I ask.

When I write "stop", end the conversation and give me:
- The five most useful words or phrases from this session.
- The mistake I made most often, and a quick rule for it.
- One thing I did well.

Begin the scenario now.

Help me understand this data. I am not a statistician.

What this data is and where it came from: {{context}}
The question I am trying to answer: {{question}}
Who I need to explain it to: {{audience:my team}}

Do this:
1. Describe what you are looking at: what each row and column represents, the time period, and the number of records.
2. Check quality first: missing values, obvious errors, duplicates, outliers, and anything that looks inconsistent. Tell me before drawing any conclusions.
3. Give the 3 to 5 most important findings. For each one:
   - State it in a plain sentence, with the actual numbers.
   - Say how confident I should be, and why. Is the difference large or small? Is the sample big enough? Could it be chance?
4. Answer my question directly, or tell me that this data cannot answer it and why.
5. Say what the data does not show. Point out anywhere it would be tempting to assume a cause when there is only a pattern.
6. Suggest the one chart that would show the main finding most clearly, and what goes on each axis.
7. Give me a 3-sentence summary I could say out loud to my audience.

Rules:
- Use only the numbers I gave you. Show your working for any figure you calculate, so I can check it.
- Do not call a difference "significant" unless you can justify it. Small samples and small differences should be described as such.
- Keep percentages honest: say "from 4 to 6 customers", not only "a 50% increase".
- If you need to know something about how the data was collected before you can interpret it, ask.

Data:
{{data}}

Write a SQL query that answers my question.

Database: {{database:PostgreSQL}}
My question: {{question}}

Tables and columns (paste the schema, or describe the tables, their columns, and how they relate):
{{schema}}

Give me:
1. The query, formatted, with a short comment above any part that is not obvious.
2. A plain-English walkthrough: which tables it reads, how they are joined, what is filtered out, and how the result is grouped and sorted.
3. Every assumption you made. Common ones: what counts as "active" or "recent", how nulls are treated, whether time ranges include their end date, which time zone dates are in, and whether rows can be duplicated by a join.
4. What the output will look like: the columns, and one or two example rows.
5. A quick check I can run to confirm that the number is right, such as a count before and after the join.

Rules:
- Use only tables and columns from the schema I gave. If something I need is not there, say what is missing; do not make up a column.
- Use syntax that works in the database I named.
- If my question could mean two different things, write both queries and explain what distinguishes them.
- Watch for joins that multiply rows and inflate sums or counts. Call it out if that is a risk here.
- If the query could be slow on a large table, say which index would help.
- This is for reading data. Do not write anything that changes or deletes data unless I ask for it.

Act as an experienced interviewer and run a mock interview with me.

Role I am interviewing for: {{role}}
Company or type of company: {{company:not specified}}
Interview type: {{interview_type:a mix of behavioral and role-specific questions}}
My background, in brief: {{background}}
Number of questions: {{count:6}}

How to run it:
1. Ask ONE question, then stop and wait for my answer. Never ask the next question in the same message.
2. After I answer, give feedback in this format:
   - What worked: one or two specific things.
   - What to improve: the most important one or two things. Be direct. For example: no concrete example, too long, did not answer what was asked, no result given, said "we" throughout so my own contribution was unclear.
   - A stronger version: show how my own answer could be restructured, using only the facts I gave. Do not invent experience for me.
3. Then ask the next question.

Question mix:
- Start with an easy opener.
- Include behavioral questions ("Tell me about a time when...") and expect a clear situation, what I did, and the result.
- Include questions specific to the role and its seniority.
- Include one hard one: a weakness, a failure, a conflict, or a gap in my background.
- Ask a follow-up when my answer is vague, the way a real interviewer would.

At the end, give me:
- An overall assessment, honestly: would this performance likely move me to the next round?
- My two biggest strengths and my two most important things to fix.
- Three questions I should ask the interviewer for this role.

Start by greeting me briefly and asking the first question.

Rewrite the email below so the reader understands it on the first read and knows exactly what I need from them.

Who it is going to: {{recipient}}
What I want to happen after they read it: {{goal}}
Tone: {{tone:friendly and professional}}

How to rewrite it:
- Open with the request or the main point. Background comes after, and only what the reader needs.
- One request per email if possible. If there are several, number them.
- Give any date or deadline as a specific day, not "soon" or "ASAP".
- Short paragraphs. Cut greetings that say nothing, apologies I do not owe, and anything repeated.
- Keep it sounding like me. Do not make it more formal than the original.
- Do not add facts, promises, or dates that are not in my draft. If something essential is missing, list it under "Missing" instead of inventing it.

Return:
1. A subject line under 60 characters.
2. The rewritten email.
3. "What I changed", in two or three bullets.

My draft:
{{draft}}

Help me choose between these options.

The decision: {{decision}}
The options: {{options}}
What matters most to me, most important first: {{priorities}}
Hard limits (budget, deadline, must-haves): {{constraints:none}}

Do this:
1. Restate my priorities as 4 to 6 criteria and give each a weight that reflects the order I gave. Show the weights.
2. Build a comparison table: one row per criterion, one column per option. Use specifics (numbers, features, terms), not "good" or "better".
3. Score each option on each criterion from 1 to 5, with a one-line reason for each score.
4. Rule out any option that breaks a hard limit, and say which limit.
5. Recommend one option. Explain the recommendation in terms of my priorities, not the total score alone.
6. Say what would change the recommendation: the one or two facts that, if different, would make another option the better choice.

Rules:
- Use only the information I gave you plus general knowledge you are confident of. Mark anything you are unsure about as "verify".
- Do not quote prices, specifications, or reviews as current facts; tell me to check them.
- If two options are close, say so plainly. Do not manufacture a clear winner.
- If I am missing an obvious option, mention it in one line at the end.

Details about each option:
{{details}}

Brief me on a topic I know little about.

Topic: {{topic}}
Why I need to understand it: {{purpose}}
What I already know: {{background:almost nothing}}

Give me:
1. The one-paragraph version: what this is and why it matters.
2. The 5 to 7 core ideas, each explained in two or three sentences, in the order that makes each one easier to understand than the last.
3. Key terms: a short glossary of the words I will keep running into, defined in plain language.
4. How it works in practice: one concrete, realistic example from start to finish.
5. Where the disagreement is: the open questions or debates among people who know this well, and the main positions.
6. Common misconceptions: what beginners usually get wrong.
7. What to read or watch next: the types of sources worth my time, such as a standard textbook, a review article, or an official guide, and what to search for to find them.
8. Five questions I should now be able to answer, so I can test myself.

Rules:
- Aim it at my purpose. Leave out what I do not need for it.
- Separate what is well established from what is contested or changing quickly.
- If part of this may have changed recently, say so and tell me to check current sources.
- Do not invent book titles, authors, papers, or links. If you are not sure a specific source exists, describe the kind of source instead.

Teach me this concept and make sure I really understand it.

Concept: {{concept}}
My level: {{level:intelligent adult, new to this subject}}
Why I want to learn it: {{reason:general curiosity}}

Part 1: Explain it.
- Start with why it matters or what problem it solves.
- Give the core idea in two or three sentences of plain language.
- Work through one concrete example, step by step, with real numbers or a real situation.
- Add one analogy, and say where the analogy stops being accurate.
- Name the one or two things people most often misunderstand about it.

Keep this part under 300 words. Then stop and ask me whether anything is unclear before going on.

Part 2: Check my understanding.
Ask me three questions, one at a time. Wait for my answer before asking the next.
- Question 1: explain the idea back in my own words.
- Question 2: apply it to a new situation that was not in your explanation.
- Question 3: a case where the obvious answer is wrong.

After each answer:
- Tell me what I got right.
- If I am wrong or partly wrong, do not just give the answer. Point to where my reasoning went off track and let me try again.
- If I am right, go one level deeper.

Part 3: Wrap up.
Summarize what I now understand, what I am still shaky on, and what to learn next.

Rules:
- Use everyday words. Define any technical term the first time you use it.
- Do not praise answers that are wrong. Be kind and be accurate.

Help me debug this. Reason through it; do not jump straight to a fix.

Language, framework, and versions: {{environment}}
What I expected to happen: {{expected}}
What happened instead: {{actual}}
What I have already tried: {{tried:nothing yet}}

Work through it in this order:
1. Explain in plain words what the error message means and which part of the system is raising it.
2. Point to the line or call where the problem most likely starts. This is often not the line the error names; say why.
3. List the two to four most likely causes, most likely first. For each, say what in my code or error output points to it.
4. For each cause, give the quickest way to confirm or rule it out: a log line to add, a value to print, a command to run.
5. Give the fix for the most likely cause, as code, and explain why it works.

Rules:
- Base this on the code and error I gave you. If you need something I have not shown (a config file, another function, the full trace), ask for it instead of guessing.
- Do not suggest things I said I already tried.
- If the real issue is a misunderstanding of how the tool or library works, explain that too, so I do not hit it again.

Error output:
{{error}}

Relevant code:
{{code}}

Explain the document below in plain language. I am not a lawyer.

What kind of document it is: {{document_type:a contract}}
My position: {{my_role:the person being asked to sign it}}
What I most want to understand: {{main_question:what I am agreeing to}}

Give me:
1. What this document is and what it does, in two or three sentences.
2. What I must do: every obligation, each with its deadline and how often it recurs.
3. What the other side must do.
4. Money: every amount, fee, penalty, deposit, and price increase, and what triggers each one.
5. Dates that matter: start, end, renewal, notice periods, and deadlines for canceling.
6. How I can get out of it, and what that costs me.
7. Clauses to look at closely: anything one-sided, unusual, easy to miss, or that gives up a right. Examples: automatic renewal, liability limits, arbitration clauses, the other side's right to change the terms. Quote each clause and say why it matters.
8. Questions I should ask before signing.

Rules:
- Quote the clause or section number for every point, so I can find it.
- If the wording is vague or could be read two ways, say so and give both readings.
- If something I would expect to find is missing, say what.
- Explain what the text says; do not tell me whether to sign. This is general information, not legal advice, and the law differs from place to place. For anything with real money or rights at stake, tell me which specific points to take to a qualified professional.

Document:
{{document}}

Write unit tests for the code below.

Language and test framework: {{framework}}

Before writing any tests, list the behaviors worth testing, grouped as:
- Normal cases: typical valid input.
- Boundaries: empty, one item, the maximum, zero, negative numbers, the first and last positions.
- Invalid input: wrong type, missing fields, malformed data.
- Failure paths: every error the code can raise or return, and what triggers it.

Then write the tests.
- One behavior per test. Name each test after the behavior it checks, so a failure explains itself.
- Arrange, act, assert, with a blank line between each part.
- Check results, not implementation details. Do not test private helpers directly.
- Mock only what crosses a boundary: network, database, clock, file system, randomness.
- Each test must be able to run alone and in any order.

Rules:
- Match the conventions of the framework I named.
- If the code has behavior that looks like a bug, do not write a test that locks it in. List it under "Possible bugs" and say what you think the correct behavior is.
- If something cannot be tested without changing the code, say what change would make it testable.

Code:
{{code}}

Go through the text below and help me fact-check it.

Step 1. List every factual claim: statistics, dates, quotes, named events, cause-and-effect statements, and claims about what a study or a person said. Skip opinions and predictions, but list them separately so I can see what is opinion presented as fact.

Step 2. For each claim, give:
- The claim, quoted.
- Type: number, quote, historical fact, scientific claim, or attribution.
- Your assessment: likely accurate, likely inaccurate, misleading, or cannot tell.
- Why: what you know that supports or contradicts it. Be specific about what is wrong, such as an outdated figure, a correlation presented as a cause, a quote that is commonly misattributed, or missing context.
- How to verify it: the kind of primary source that would settle it, such as an official statistics agency, the original study, a court record, or the full speech.

Step 3. Rank the claims by how much the piece depends on them. Which three, if wrong, would undermine its argument?

Rules:
- Your knowledge has a cutoff date and can be wrong. Say "cannot tell" when you are not confident; that is a useful answer.
- Never invent a source, a link, or a citation. Describe what kind of source to look for instead.
- Do not judge the conclusion of the piece. Only check its facts.

Text:
{{text}}

Write a cover letter for the job below, based on my resume and notes.

Company and role: {{company_and_role}}
Why I want this job in particular: {{why_this_job}}
Length: {{length:250 to 300 words}}

How to write it:
- Open with something specific: the reason I want this role, or the most relevant thing I have done. Not "I am writing to apply for".
- Choose the two or three things from my background that best match what the posting asks for. For each, say what I did and what came of it. Do not walk through my whole resume.
- Connect them to what this company needs, using details from the posting.
- Close in two sentences. Say I would like to talk; do not beg.

Do not use: "I am excited to apply", "passionate", "fast-paced environment", "team player", "I believe I would be a great fit", "proven track record", or any sentence that could be pasted into a letter for a different company.

Rules:
- Use only facts from my resume and notes. Do not invent achievements or claims about the company.
- Write it the way a thoughtful person talks: plain words, some short sentences, no exaggeration.

After the letter, tell me which one sentence you think is weakest and what detail from me would improve it.

Job description:
{{job_description}}

My resume:
{{resume}}

Write a spreadsheet formula for me.

Spreadsheet program: {{app:Google Sheets}}
What I want the formula to do: {{goal}}
How my data is laid out (which columns hold what, which row the data starts on, the sheet name if it matters): {{layout}}
A few example rows, if I have them: {{examples:none provided}}

Give me:
1. The formula, ready to paste, in a code block.
2. The cell to put it in, and whether to drag it down or whether it fills by itself.
3. An explanation of each part from the inside out, in plain words.
4. What it returns for my example rows, or for a small example you make up if I gave none.
5. What will break it: blank cells, text stored as numbers, extra spaces, merged cells, dates stored as text. Give the fix for each one that applies to my case.
6. A simpler or more robust alternative, if there is one. For example, a lookup that does not break when a column is inserted.

Rules:
- Use functions that exist in the program I named. If the best function is only in newer versions, say so and give a fallback.
- Use my real column letters and sheet names, not placeholders.
- Assume my regional settings use {{separator:commas}} to separate arguments.
- If my description could mean two different things, show both formulas and explain the difference.
- If this would be better done with a pivot table, a filter, or a helper column than with one giant formula, tell me.

Create an outline for a blog post.

Topic or target search phrase: {{topic}}
Who is searching for this: {{reader}}
What I know or offer that others do not: {{my_angle}}
Target length: {{length:1,200 to 1,500 words}}

Step 1. Work out the intent behind the search. What is this person trying to get done, what do they already know, and what would make them stop searching? Write that as two or three sentences.

Step 2. List the 6 to 8 questions that reader needs answered, in the order they would ask them.

Step 3. Build the outline:
- Three title options under 60 characters. They should be clear and specific, not clickbait.
- A meta description under 155 characters.
- An introduction plan that gets to the answer quickly. The main point should appear within the first 100 words.
- Section headings (H2), with sub-headings (H3) where needed. Phrase them the way the reader would phrase the question.
- Under each heading: the points to cover, the example or evidence needed, and a rough word count.
- Where a table, checklist, screenshot, or step-by-step list would help more than paragraphs.
- A closing section that tells the reader what to do next.

Step 4. Tell me what would make this post better than what is probably already ranking: where my angle, my experience, or original data should go.

Rules:
- Do not pad it. If a section does not help the reader with their task, cut it.
- Do not invent statistics, studies, or expert quotes. Mark where I need to supply a real source with [SOURCE NEEDED].
- I cannot rely on you for search volumes or current rankings, so do not state any. Tell me what to check in a keyword tool instead.

Help me reply to a negative review of my business.

My business: {{business}}
What actually happened, from our side: {{our_side}}
What I can offer to put it right: {{remedy:an apology and a way to contact us directly}}

Write a public reply that:
- Addresses the reviewer by name if they gave one, and thanks them without sounding scripted.
- Names the specific problem they raised, so it is clear someone read the review.
- Apologizes once, plainly, for what we got wrong. If we did nothing wrong, acknowledge their frustration without admitting to something that did not happen.
- Says what we are doing about it, or what we have already changed.
- Offers a direct way to continue the conversation privately.
- Is under 100 words.

It must not:
- Argue, correct the customer point by point, or blame them or our staff.
- Use stock lines such as "we strive for excellence" or "your feedback is important to us".
- Reveal anything private about the customer or their order.
- Promise anything I did not say I can offer.

Remember who else reads this: future customers deciding whether to trust us. The reply should show them how we handle problems.

Then write a short private message to send if the customer gets in touch, with the specific remedy.

If the review looks fake, abusive, or about a different business, say so and suggest a brief, neutral reply instead.

The review:
{{review}}

Turn my rough notes into a first draft.

What I am writing: {{format:a blog post}}
Who will read it: {{audience}}
Target length: {{length:600 to 800 words}}

Steps:
1. Find the main point my notes are making. State it in one sentence before the draft so I can check you understood.
2. Group related notes and put them in an order a reader can follow. Drop duplicates.
3. Write the draft in plain, direct language. Keep my phrasing where it is already good.

Rules:
- Every claim in the draft must come from my notes. Do not add statistics, quotes, examples, or anecdotes of your own.
- Where the draft needs something my notes do not have (an example, a number, a source), put [NEEDED: what is missing] in that spot.
- No filler introduction and no summary paragraph that repeats the piece.

After the draft, list:
- The notes you left out, and why.
- The weakest part of the argument as it stands.

My notes:
{{notes}}

Help me plan a project.

Project: {{project}}
What "done" looks like: {{definition_of_done}}
Deadline: {{deadline:flexible}}
Who is working on it and how much time they have: {{team:just me, part-time}}
Budget or other limits: {{constraints:none}}

Produce:

1. Scope: what is included and, just as important, what is not. List any assumptions you are making.

2. Milestones: 3 to 6 points where something real is finished and can be shown or checked. Each one needs a clear test for "this is done".

3. Tasks under each milestone:
   - Concrete and small enough to finish in a day or two.
   - An estimate for each, in hours or days.
   - What it depends on.
   - Who does it, if there is more than one person.

4. Timeline: put the milestones on a calendar, working from the estimates and the time available. Identify the critical path, meaning the tasks where a delay moves the end date.

5. Risks: the 5 things most likely to delay or sink this. For each: how likely, how bad, the early warning sign, and what to do now to reduce it.

6. First week: exactly what to do in the first five working days.

7. Decisions needed: anything that has to be decided or found out before work can properly start.

Rules:
- Be realistic. Estimates should include testing, review, and waiting on other people. Add a buffer and say how big it is.
- If the deadline is not achievable with the time and people available, say so, and show what would need to change: scope, deadline, or resources.
- Put the riskiest or most uncertain work early, so problems show up while there is still time.
- If there is something I need to tell you before you can plan this properly, ask me first.

Plan a trip for me.

Destination: {{destination}}
Dates or length of stay: {{dates}}
Who is traveling: {{travelers:two adults}}
Budget, not counting flights: {{budget}}
What we enjoy: {{interests}}
Pace: {{pace:relaxed, with one or two main things a day}}
Things to avoid, or needs to plan around (mobility, diet, children, and so on): {{constraints:none}}

Give me:

1. Overview: the best area or areas to stay in for what we like, and why. How to get around.

2. A day-by-day plan. For each day:
   - Morning, afternoon, and evening, with one main activity in each at most.
   - Places grouped by area, so we are not crossing the city back and forth.
   - Roughly how long each thing takes, and how to get between them.
   - A suggestion for where to eat nearby, by type of food and area.
   - A fallback for bad weather.

3. A lighter first day and last day, to allow for arriving and leaving.

4. Budget breakdown: a rough estimate per day for accommodation, food, transport, and activities, and how it compares with my budget. If my budget is tight for this destination, tell me where to save.

5. Book ahead: anything that sells out or needs a reservation.

6. Practical notes: local customs worth knowing, common tourist traps, safety, and what to pack for the season.

Rules:
- Be realistic about time. Include travel between places, queues, and rest. Do not plan a day that only works if nothing goes wrong.
- Your information may be out of date. Do not state exact prices, opening hours, or schedules as fact. Give rough ranges and mark what I need to check before I go: opening days, ticket prices, visa and entry rules, and seasonal closures.
- Do not invent specific restaurants, hotels, or tours. If you name a place, it should be a well-known one, and I should still confirm it exists and is open.
- Mix the well-known sights with one or two quieter options that match what we like.

Help me prepare for a conversation I am not looking forward to.

Who I need to talk to, and our relationship: {{person}}
What it is about: {{situation}}
What I want to come out of it: {{outcome}}
What I am worried might happen: {{worry}}

Help me think it through:

1. The real issue. Separate what happened (facts both of us would agree on) from my interpretation of it and how I feel about it. Tell me if I seem to be mixing these up.

2. Their side. What might this look like from their position? What pressures or concerns might they have that I am not seeing? Give me the most generous reasonable reading, not an excuse for them.

3. My goal. Is the outcome I named realistic, and is it within their power to give? If not, suggest a better one. Help me set: what I ideally want, what I would accept, and where I would stop.

4. The opening. Write the first two or three sentences I could say. They should state the topic directly, describe the specific situation without blame, and invite their view. No long warm-up and no "we need to talk".

5. Likely responses. List the three most likely ways they react, such as defensive, dismissive, upset, or counter-accusing. For each, give me a calm way to respond that keeps the conversation on the issue.

6. Phrases to avoid. Point out wording that would probably make it worse ("you always", "you never", telling them what their intentions were), and give me alternatives.

7. Ending it. How to close with a clear next step, including if we do not agree.

Rules:
- Be honest with me. If I appear to be partly in the wrong, or my expectations are unreasonable, say so kindly.
- Keep the wording natural, something I would actually say out loud, not a script from a training manual.
- Do not assume bad intent from the other person without evidence.
- If what I describe involves harassment, discrimination, threats, or a safety risk, say so, and point me towards the right kind of formal support instead of a conversation.

Write a commit message and a pull request description for the change below.

Why I made this change: {{reason}}
Anything reviewers should know (trade-offs, follow-ups, things I am unsure about): {{notes:nothing extra}}

Commit message:
- Subject line: imperative mood ("Add", "Fix", "Remove"), under 72 characters, no full stop.
- Blank line.
- Body: why the change was needed and what it does at a high level. Do not walk through the diff line by line.

Pull request description:
- Summary: what changes for a user or for the system, in two or three sentences.
- Why: the problem or need behind it.
- What changed: a short list by area, not by file.
- How to test: the steps a reviewer can follow to see it working.
- Risks: anything that could break, any migration or config change, and whether it can be rolled back.
- Review focus: the one or two places where a careful second look matters most.

Rules:
- Describe only what the diff actually does. If the diff does something my stated reason does not explain, point it out.
- Do not claim tests were added or run unless the diff shows them.
- Plain language. No "various improvements" or "minor fixes".

Diff:
{{diff}}

Review the code below as a careful senior engineer would. I care about whether it is correct and safe, not how it is formatted.

Language or framework: {{language}}
What the code is supposed to do: {{purpose}}

Look for:
1. Bugs: logic errors, off-by-one mistakes, wrong conditions, unhandled null or empty values, wrong types.
2. Edge cases: empty input, very large input, duplicates, unusual characters, time zones, two things happening at once.
3. Security: unvalidated input, injection, secrets in code, missing permission checks, unsafe handling of files or URLs.
4. Error handling: failures that are swallowed, error messages that leak internals, resources that are never released.
5. Performance, only where it would actually hurt: work repeated inside loops, queries inside loops, loading everything into memory.

For each finding give:
- Severity: critical, high, medium, or low.
- Where: the function or line.
- What goes wrong: a specific input or situation, and the wrong result.
- The fix, as a short code snippet.

Rules:
- Order findings from most to least severe.
- Skip formatting, naming, and anything a linter would catch.
- If you are not sure something is a bug, say so and say what you would check.
- If the code looks correct, say that. Do not invent problems to fill the list.

End with one line: is this safe to ship as it is, yes or no, and why.

Code:
{{code}}

Write a product description.

Product: {{product}}
Who buys it: {{customer}}
Where it will appear: {{channel:an online store product page}}
Brand voice: {{voice:clear, warm, and direct}}
Length: {{length:120 to 160 words, plus bullets}}

Structure:
1. Headline: what it is and the main reason someone wants it, in under 10 words.
2. Opening: one or two sentences about the buyer's situation or problem, in the words they would use.
3. Body: the two or three benefits that matter most to this customer. Tie each one to the feature that delivers it. For example: "The 20-hour battery gets you through a long-haul flight and back."
4. Bullets: 4 to 6 key specifications or included items, for people who scan.
5. A closing line that removes a doubt, such as the warranty, the return policy, or who it suits.

Rules:
- Use only the facts I give you. Do not invent specifications, materials, certifications, awards, reviews, or guarantees.
- Be specific instead of using superlatives. No "best-in-class", "revolutionary", "game-changing", "premium quality", or "elevate".
- Make no health, safety, or environmental claims unless I supplied them.
- Write the way someone knowledgeable would describe it to a friend.

Give me two versions with different opening angles, and say which kind of buyer each one suits.

Product details and specifications:
{{details}}

Summarize the document below for this reader: {{reader:a busy manager who has not read it}}

Length: {{length:about 200 words}}

Structure:
1. The point, in one or two sentences. If the document asks the reader to decide or do something, say that first.
2. The key facts that support it, as bullets. Keep every number, date, name, and amount exactly as written.
3. What is still open, uncertain, or disputed in the document.
4. What the reader needs to do, and by when, if the document says.

Rules:
- Use only what is in the document. Do not add background from your own knowledge.
- Do not soften or strengthen the document's claims. If it says "may", do not write "will".
- If the document contradicts itself, point to both places.
- If a part matters but is too detailed to summarize, say where it is so the reader can go to it.

Document:
{{document}}