Fix my booking form: clicking Submit creates two bookings
In this project, clicking Submit on the booking form can create two bookings. Here are the reproduction steps, relevant files and logs with secrets removed: [details]. First trace the submission flow and explain the likely cause. Make the smallest scoped fix if you have editing tools; otherwise show a patch. Cover repeated clicks and request retries without assuming a disabled button alone prevents server duplicates. Add a regression test and report what you actually ran. Do not change unrelated files or deploy.
Make it yours: Provide the framework version, expected behaviour and a safe test environment.
A useful follow-up
What happens if the first request succeeds but its response is lost? Add or describe a test for that case.
02
Text
Fix a bug with a reproducible acceptance case
In this repository, [steps and input] cause [observed behaviour]. Expected behaviour is [expected]. Reproduce the problem, inspect the relevant conventions and implement a focused fix. Verify the original failure and the nearest regression risk. Preserve unrelated changes. Report what was actually checked and what remains uncertain.
Make it yours: Include exact errors and relevant dependency versions without secrets.
A useful follow-up
What case would show that the fix only masks the symptom?
03
Text
Implement a feature with error and empty states
Add [feature] for [user] in this codebase. The successful flow is [flow]. Empty, loading, invalid-input and failure states should [behaviour]. Reuse the existing [pattern]. Implement a complete first version and verify persistence, keyboard interaction and recovery from the expected error.
Make it yours: State which behaviour is approved and which choices are open.
A useful follow-up
Check the flow with no existing data and with a failed save.
04
Text
Review a diff for introduced defects
Review this diff for defects introduced by the change, focusing on [risk]. For each finding explain the concrete trigger, impact, affected location and evidence. Distinguish confirmed defects from questions needing more context. Keep style preferences separate. Do not implement fixes as part of the review.
Make it yours: Name a risk such as duplicate requests, stale state or broken URLs.
A useful follow-up
Which finding has the strongest reproducible evidence? Show the smallest case.
05
Text
Refactor while preserving behaviour
Refactor [component] to address [maintainability problem]. Inspect existing tests and usage first. Preserve observable behaviour and public interfaces unless explicitly approved. Make the smallest useful structural change and verify representative consumers. Explain any behaviour difference discovered during the work.
Make it yours: Describe the actual maintenance pain, not just a preferred code style.
A useful follow-up
Which edge case is most likely to have changed because of the new structure?
06
Text
Plan a migration before changing the project
Assess migrating [system or dependency] from [version] to [target]. Check current official guidance and inspect our usage. Identify breaking changes that actually affect this repository, propose an ordered migration and define compatibility checks. Separate required changes from optional cleanup. Do not migrate until the plan is reviewed.
Make it yours: Provide the real target version and deployment constraints.
A useful follow-up
Which first step is reversible and reduces the largest uncertainty?
07
Images
Verify a UI change from the user's perspective
Compare this rendered UI with [approved reference and behaviour]. Inspect spacing, readable text, focus order, validation and narrow-screen layout. Separate visual mismatches from functional defects. Verify a representative user flow and explain what could not be checked from the screenshot alone.
Make it yours: A screenshot provides visual evidence but not persistence or interaction behaviour.
A useful follow-up
Which issue most affects completing the task rather than visual polish?
08
Text
Brief an appointment-booking interface
Design an interface specification for [service] bookings. Users choose a service, available slot and contact method. Define loading, unavailable slots, validation, failed submission and confirmation. Separate a UI prototype from real booking integration. Include keyboard access and data-minimisation requirements; do not invent available appointments.
Make it yours: Use synthetic data until a real backend is authorised.
A useful follow-up
What must happen if a slot disappears before confirmation?
09
Text
Specify a tournament organiser dashboard
Brief a dashboard for [sport] fixtures and umpire assignments. Define organiser tasks, match IDs, availability, hard constraints, draft status and publish approval. Include a conflict panel and audit history. Keep the scheduling algorithm separate from display. Never label a schedule valid without running its checks.
Make it yours: Provide actual competition rules rather than asking the UI to invent them.
A useful follow-up
Describe the flow for fixing one umpire clash without changing locked matches.
10
Text
Design a repair-request intake form
Specify a repair-request form for [workshop]. Collect item model, observed issue, contact preference and optional photos. Avoid asking users to diagnose the fault. Define upload limits, privacy notice placement, failure recovery and accessible errors. Do not promise a quote or safe-to-use assessment from the form.
Make it yours: Confirm which information the workshop really needs.
A useful follow-up
What can a customer submit if they do not know the model?
11
Text
Prototype a small-business quote builder
Create a specification for a quote-builder prototype using [approved service and pricing rules]. Show itemised amounts, exclusions, tax fields requiring supplied rules and draft status. Include invalid quantities, unavailable services and rounding tests. Do not turn the prototype into a legally binding quote or invent business rules.
Make it yours: Use supplied examples to verify arithmetic.
A useful follow-up
Which price change requires an existing draft to be recalculated?
12
Text
Design a source-checking reading interface
Specify an interface showing an answer beside its claim ledger and source passages. Include supported, partial, contradicted and unresolved states, source dates and reviewer notes. Do not use a green badge as a guarantee of truth. Define keyboard navigation and what happens when a source is inaccessible.
Make it yours: Human review must remain visible, not hidden behind a confidence score.
A useful follow-up
How can a reader report a citation that exists but does not support the claim?
13
Text
Make a party-planning checklist prototype
Brief a checklist app for [event]. Tasks need owner, due date, dependency and proposed or agreed status. Include no-owner, overdue, changed-date and offline-save failure states. Use synthetic guests, avoid private health details and keep invitations separate from task editing.
Make it yours: Do not add messaging or public sharing without approval.
A useful follow-up
What feedback tells a user their change was not saved?
14
Text
Define an accessible search-and-filter interface
Specify search and filters for [collection] with [fields]. Define combined filter behaviour, no results, clear-all, keyboard interaction and result announcements. Preserve direct links to items. Include tests for mixed case, empty search and conflicting filters before choosing implementation details.
Make it yours: Start from user tasks and actual data volume.
A useful follow-up
Which state should survive navigation back from a result?
15
Images
Review a generated interface before wiring real data
Review this prototype for [user task] using [requirements]. Separate screenshot-visible issues from interactions that need browser testing. Check labels, hierarchy, error recovery, narrow layout and empty states. Identify fake controls or invented data that could mislead users. Do not claim accessibility compliance from a screenshot alone.
Make it yours: Include intended behaviour as well as the visual.
A useful follow-up
Write three acceptance tests that a polished static mockup would fail.