Real Gently threads, one fictional delivery product. Crosstown connects a merchant portal, operations dashboard, courier app, Rails API, and background jobs. Each thread gets an isolated environment from the same project setup. Product, design, support, and engineering can work in parallel without installing the app on their own machines. See their questions, wireframes, implementation, and testing below.
Product management asks
A new teammate wants to understand how an order gets from a shop to its customer.
Task prompt
Show me a simple diagram of how an order gets from a shop to the customer in Crosstown.
Show me a simple diagram of how an order gets from a shop to the customer in Crosstown. Follow-up: Make the diagram compact: six main steps in two rows, so it is readable at a glance.
Product and design asks
Couriers need a simple way to choose the days they can work. The team wants to compare two options.
Task prompt
Sketch two simple ways for couriers to set which days they are available to work.
Sketch two simple ways for couriers to set which days they are available to work. Follow-up: Show both as compact, rough sketches side by side so we can compare them in one view. Follow-up: Keep the two options side by side in a 650px-wide thread, with the whole sketch under 450px tall. Follow-up: The sketch clips the bottom controls. Make both cards fit fully without internal scrolling.
QA asks
A courier accepts a route, delivers one order, and cannot deliver another. QA needs to check what happens next.
Task prompt
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too.
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too. Follow-up: Re-test accepting a route, delivering one order, and marking another delivery failed in the browser. Use demo orders with customer email addresses and check both emails. Follow-up: Summarize the completed browser checks and the two verified emails in a short checklist.
Engineering asks
Couriers need to set when they can work, so operations can offer each route to someone available that day.
Task prompt
Let couriers set their availability, and only offer routes to couriers available that day.
Engineering asks
Customers need a link they can open to check their delivery and see the proof photo.
Task prompt
Build a delivery tracking page with ETA and proof photo, linked from the customer’s delivery email.
Build a delivery tracking page with ETA and proof photo, linked from the customer’s delivery email. Follow-up: The tracking link opens the marketing site’s 404 page in Preview. Fix the routing so the email link opens the tracking page.
Sales asks
A shop wants to know whether its customers can track deliveries and see proof of delivery.
Task prompt
Can customers track their delivery and see a proof photo in Crosstown today?
Can customers track their delivery and see a proof photo in Crosstown today? Follow-up: Give me the short version I can use before a sales demo.
QA asks
A courier accepts a route, delivers one order, and cannot deliver another. QA needs to check what happens next.
Task prompt
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too.
Test that a courier can accept a route, deliver an order, and mark another delivery as failed. Check the customer emails too. Follow-up: Re-test accepting a route, delivering one order, and marking another delivery failed in the browser. Use demo orders with customer email addresses and check both emails. Follow-up: Summarize the completed browser checks and the two verified emails in a short checklist.
Customer success asks
The team wants to understand merchant adoption and help each shop get more value from Crosstown.
Task prompt
Compare merchant usage in Crosstown. Who should customer success follow up with, and how can we help them get more value?
Compare merchant usage in Crosstown. Who should customer success follow up with, and how can we help them get more value? Follow-up: Show the usage comparison and the two follow-up priorities in a compact summary. Keep the demo-data caveat.
Customer support asks
A courier cannot complete a delivery. Support needs to explain the next step and what the customer will hear.
Task prompt
A courier accepted a route but cannot finish a delivery. What should they do, and what will the customer be told?
Try the same kinds of requests on your own product: ask about current behavior, explore a change, or take it through implementation and review.
Paste a screenshot, ask for wireframe directions, react in the thread, then tell the same thread to build the one you picked — the wireframe is the spec.
“Here’s a screenshot of the settings page — the tab order feels off. Give me a few wireframe options I can react to.”
Sales watches the funnel with standing threads on live account data; marketing ships site and positioning updates as reviewed pull requests.
“Which trials look shaky this week? Tag the account executive on each one with the reason.”
Ask account and billing questions from Slack, have the agent reproduce reported bugs in the real app, and hand back replies backed by screenshots.
“A customer says their export is missing fields. Is that a bug? Can you try to reproduce it?”
The Monday-morning sweeps — reading the support inbox, triaging product requests, watching releases for docs drift — run on a schedule, each as a thread you can open and audit.
“Every week, read the last 7 days of support conversations and report the top product requests.”
The safest rollout is narrow: choose one team, one complex app workflow, and one kind of request. Expand once the collaboration and review loop feels good.