Technology

I want to move notes from [app] to [app]. Here is the actual export documentation [text], my note inventory [counts/types] and destination import documentation [text]. Make a migration rehearsal checklist covering text, attachments, tags, links and dates. Mark unsupported features and unknown conversions. Use a small fictional sample first; do not delete originals, change accounts or claim a successful import without inspection. Define counts and spot checks that would show loss, including links that only work in the old app. Ask which note feature matters most to preserve.

Make it yours: Back up originals and avoid testing with private notes.

I am returning a loaned laptop managed by [organisation]. Here are its actual handover instructions [text], my authorised work locations [list] and what I must retain [requirements]. Make a checklist of questions and approved steps for the IT owner: file ownership, permitted backup, signed-in accounts and receipt of return. Do not recommend bypassing management controls, perform a reset or promise deleting a shortcut removes cloud data. Keep passwords out of the plan. Ask which files belong to the organisation before suggesting any transfer or deletion.

Make it yours: Follow the device owner's process and get guidance before deleting or copying work data.

Here is my original bug report [text], developer's questions [reply], actual device/browser versions [details], steps tried [record] and authorised screenshots [images]. Help me answer with exact observed steps, expected versus actual results and whether the issue repeats. Separate confirmed behaviour from guesses about cause. Do not invent logs, expose session tokens or claim a fix because one attempt worked. Suggest a minimal fictional test case and ask which environment detail is missing before drafting the update; do not submit it automatically.

Make it yours: Remove private content and access tokens from screenshots and error text.

We are collaborating on [project]. Here are the file groups [non-sensitive descriptions], roles and agreed tasks [roles], approved data-sharing policy [policy] and actual platform permission options [documentation]. Draft a proposed access matrix distinguishing view, comment, edit and owner authority. Do not grant permissions, invent platform controls or assume a public link is acceptable. Flag external sharing and personal material for the responsible owner to review. Ask which collaborator needs access to originals rather than a redacted copy before recommending the minimum scope.

Make it yours: Review actual permission settings and organisational policy before sharing anything.

I want to export family photographs from [service] using its actual export documentation [text]. My inventory is [counts and file types], destination requirements [text] and details I need preserved [dates, albums or captions]. Make a small authorised rehearsal and verification checklist for file counts, opening files and retained metadata. Do not delete originals, infer a complete backup from one thumbnail or promise cloud-only features export intact. Use non-sensitive samples first and ask which album information matters most before choosing checks.

Make it yours: Keep independent copies and inspect actual files before considering any deletion.

I need video calls for [purpose] in [room conditions]. Here are my devices, ports, available microphone/camera options and actual test observations [inventory]. Make two setups using only compatible confirmed equipment and a short rehearsal for sound, framing and joining the intended app. Do not invent specifications, assume an adapter works or recommend purchases before checking what I own. Use fictional call content and ask which problem matters most, such as echo or framing, before prioritising tests.

Make it yours: Test the actual app and room; a specification list cannot establish call quality.

I need to document who maintains [website]. Here are the actual services, account-owner roles, renewal dates and approved access process [non-secret inventory]. Make a handover showing responsibility, where authorised people obtain access and unresolved ownership questions. Do not request credentials, expose recovery codes or assume a collaborator owns an account because they built the site. Separate technical work from billing approval. Ask which service has no confirmed responsible owner before calling the handover complete.

Make it yours: Use provider-approved access and transfer processes, not shared passwords.

I want to change my main email from one service to another. Here is a redacted list of account types, recovery dependencies and subscriptions [inventory], plus the providers' current instructions [excerpts]. Make a staged migration checklist covering sign-in identifiers, recovery contacts, notifications and verification. Do not request passwords, change accounts or assume forwarding updates every login. Keep unknown dependencies visible. Ask which account controls recovery for other accounts before choosing the order.

Make it yours: Use placeholders for addresses and verify each provider's actual change procedure.

Here are my real printing jobs [page counts, colour needs, sizes and frequency], available space [dimensions] and candidate specifications and dated consumable prices [supplied records]. Compare suitability, missing information and costs under my stated usage, showing assumptions separately. Do not invent prices, ink yields, reliability or a guaranteed cheapest option. Return a shortlist and questions about my unusual jobs. Ask whether I mainly print text, photographs or occasional forms before weighting features.

Make it yours: Check consumable compatibility and dated prices in the actual candidate documents.

We need a family calendar for [coordination needs]. Here are calendar tools already used [list], participants' agreed visibility [rules] and example events with private details removed [examples]. Propose event naming, availability-only entries and ownership rules that help coordination without exposing unnecessary details. Do not assume the tools support a setting without supplied documentation or change permissions. Ask which scheduling conflict we most need to avoid before designing the minimum shared view.

Make it yours: Agree visibility with participants before adding their events.

Our backup process is [description and official instructions]. The site contains [pages, database, uploads and configuration]. Plan an isolated restore rehearsal: included and excluded material, access needed, prevention of test emails or payments, and checks for restored records and files. Mark provider-specific steps needing current official instructions. Do not execute commands, touch production, expose secrets or assume a backup notification proves recoverability. Return a checklist, evidence to record and questions for the hosting administrator, who must approve the isolation before any test.

Make it yours: Have the responsible administrator approve isolation and access.

Use my redacted screenshots and notes [material] to write a bug report for [website or app]. Ask for device, browser or app version, relevant settings, exact actions, expected result, actual result and whether it repeats. Separate observed facts from suspected causes. Produce a minimal reproduction sequence and a checklist of missing information; if screenshots cannot show a step, ask rather than invent it. Do not include passwords, session tokens, customer data or full diagnostic logs with secrets, and do not claim you reproduced the bug unless you actually did.

Make it yours: Use a test account where possible and record versions without exposing account details.

Use this booking form description or supplied page evidence [material] to plan a keyboard-only manual test from opening the form to reviewing a test booking. Include focus visibility, logical order, reaching each control, errors, dialogs and returning from them. Specify the expected observable result for each step and record pass, fail or not tested. Do not submit a real booking, change live settings or claim accessibility compliance from this checklist. If you cannot inspect the page, label the checklist as a plan based on my description and list details to confirm.

Make it yours: Test with fictional data in an appropriate test environment. Include the browser and the actual controls.

Design a small test-data set for this appointment website [fields, allowed values and test environment rules]. Include normal bookings, missing required fields, valid boundary times, conflicting appointments and one cancellation case according to the supplied rules. Mark every person and booking as fictional and use non-deliverable example contact details. Separate valid records from deliberately invalid inputs and explain the expected result. Do not use real customer data, payment details or credentials, or invent business rules. Do not insert records, send messages or create live appointments.

Make it yours: Disable outgoing notifications in an authorised test setup before entering any sample bookings.

I run a café and need a website with [menu, opening hours, booking needs and languages]. My budget, editing skills and maintenance time are [details]. Compare a hosted website builder with a custom-built site by content editing, total ongoing work, booking integration, accessibility and ability to move later. Do not invent current prices or promise integrations without checking documentation. Recommend what to validate in a small prototype before committing.

Make it yours: Describe who will update the menu and whether bookings must connect to an existing system.

Explain this system diagram for someone new to the project. Read the visible labels and flag anything unreadable. Describe what each box does only where the diagram or my notes [notes] support it, then show how information moves between the parts. Use plain language before technical terms. Separate documented connections from guesses and list three questions for the developer. Do not claim the system is secure or reliable from the picture alone.

Make it yours: Include the legend and explain whether the diagram shows the current system or a proposal.

We need a booking system for [business] with [appointments, deposits, staff and calendar needs]. Compare building one with paying for an existing service. Our budget is [amount], team skills [details], time [deadline] and existing tools [list]. Show setup work, ongoing maintenance, data-handling questions and the cost inputs still needed. Do not invent vendor features or prices; ask for current official sources or supplied quotes. Recommend a small next step, not an immediate purchase.

Make it yours: Include who will maintain the system after launch.

Use these website documents [files] to make a first-week handover for [colleague's role]. Cover where approved content lives, how updates are reviewed, which services the site depends on, who handles failures and where the actual recovery instructions are. Cite each source and mark missing steps. List access that needs arranging through our normal process without including passwords or access tokens. Do not invent commands or change the website.

Make it yours: Say which tasks the colleague is expected and authorised to do.

Investigate this error: [exact error]. Use the attached relevant code, dependency versions and steps to reproduce. Identify the most likely cause and competing explanations. Propose the smallest patch and a verification step that would expose the original failure. Explain any uncertainty before changing unrelated code.

Make it yours: Remove secrets from logs and include the failing input or environment difference.

Inspect this interface screenshot and produce an implementation brief for [framework]. Describe layout, typography, spacing and visible controls. Separate visible facts from assumptions about behaviour. Include mobile adaptation, keyboard interactions and empty or error states as proposed requirements for review. Do not infer backend features from the screenshot.

Make it yours: Name the target viewport and list interactions that the image does not show.

Compare these two proposed ways to build my small-business website [proposals]. I need [pages, bookings or shop features], have [budget and skills], and expect to update [content and frequency]. Explain development, hosting, editing, maintenance and moving away from the service in plain language. Use supplied facts and current official documentation where needed. Mark missing costs and features. End with questions to ask each developer, not an invented winner.

Make it yours: Include who will make ordinary content changes after launch.