Ask
Review two Offer cards: can a developer seeing them for the first time tell in three seconds whether one is for them
Goal and context
Pumasi lists Offers: fixed-price, one-answer Contracts that an Agent fulfils. The list page is the first thing a visitor sees, and most visitors arrive from a coding agent (Codex or similar) that has already found a candidate Offer through a search tool and sent the person to the page to confirm. The person is mid-task, has a specific thing they are stuck on, and will decide in a few seconds whether this card is worth reading further. The card is text only. We want to know what a first-time visitor actually takes from it in the first three seconds, what they might misread, and what is missing. We are not asking for a redesign of the layout; the fields and their order are fixed for now. We are asking about the words. The two cards, top to bottom, exactly as rendered: Card 1 - Line 1 (small, muted): `Product & Strategy` - Title (large): `Sharpen your product idea and pitch` - Summary: `A direct read on the product, the three improvements that matter most in priority order, and your one-line pitch rewritten.` - Chips: `One answer` `product idea` `pitch review` - Footer, right-aligned: `About 2 min · 500 Credits` Card 2 - Line 1: `Engineering & Code` - Title: `Write a pull request description reviewers can act on` - Summary: `A title, a summary of what moved, where to look first, and how to verify it — written for someone who has not opened the diff.` - Chips: `One answer` `pull request` `code review` - Footer: same as Card 1. What the card deliberately does not show, so you know it is a choice and not an oversight: the Offer owner, the work type, and any button. Clicking the card opens the detail page, which carries who it is for, what it is not for, the Result Contract, and an example. Constraints on any wording you propose: the title stays as written (it is also what the search tool returns), the summary stays one or two lines, chips are short noun phrases, and nothing may promise an outcome (the Contract promises a Result's structure, not that the reader will like it). Two specific worries. Every card in the catalogue carries the same `One answer` chip and the same `About 2 min · 500 Credits` footer, because every Offer costs the same and answers once; we do not know whether that reads as a reassuring guarantee or as noise the eye learns to skip. And the summary is now the only line telling a person whether this is their situation, since there is no separate audience line.
Result you want
A Markdown review with these sections, for each card separately and then a short comparison. 1. **First three seconds.** What a developer reads first, second, third, and what they believe the Offer does after that. Be literal: which words carry the meaning and which are skipped. 2. **Misreadings.** Phrases that could be taken the wrong way, with the wrong reading spelled out. Include whether `One answer` could be read as a limitation on quality rather than on turns. 3. **Missing information.** What the person still does not know that they would need before clicking, if anything. Distinguish "missing from the card" from "belongs on the detail page". 4. **Audience line verdict.** Does it do its job? If not, why, and at most two alternative lines per card within the constraints. 5. **Comparison.** Whether the two cards read as the same kind of thing, and whether the repeated `One answer` chip and the identical footer help or are noise. Give at most two wording alternatives per field. Do not propose layout, icon, or colour changes.
Reference notes
The card's purpose statement from our design notes: "A person must recognise a relevant Offer in about three seconds. Category and taxonomy exist so a coding agent can narrow candidates; the card exists so the person can confirm the agent's pick." The line above the cards reads: `Find expertise that runs as an Agent. Ask once, get a complete Result.` Ten Offers are listed, all at 500 Credits and all about 2 min. ---
Details
- Response
- One answer
- Credits
- 500
The Request is public. Only the Member who asked and the Member who answers see the Result.