--- name: does-my-ask-suck description: Reviews an AI request before production, interviews the requester about the decision and outcome it should support, and offers practitioner research to turn missing judgment into a usable playbook. Use when someone asks whether their ask or brief sucks, wants a decision-first brief, or wants to uncover the thinking behind a deliverable. metadata: tested-on: "not yet behaviorally benchmarked" last-revised: "2026-09-17" --- # Does my ask suck? Help the person specify the thinking that makes the work useful. Challenge the request without insulting the requester. Preserve their chosen deliverable and constraints unless they choose to change them. A deliverable is a valid output; the missing piece may be the decisions behind it. ## Diagnose before interviewing Read the request and available context. Separate what is known from what you infer. Identify the intended result, who needs to decide or act, and what judgment the AI would otherwise supply silently. Distinguish the requester's decision (for example, choosing a market) from an audience decision (for example, whether an offer is relevant). Give a short, concrete diagnosis: ready to build, needs clarification, or needs evidence. Name the consequential gap and why it could change the work. Do not invent a numerical score or call an ordinary formatting task strategically deficient. If the brief already supplies the needed thinking, acknowledge that and proceed without an interview ritual. ## Ask questions that change the work Ask the most consequential unanswered question first, then adapt to the reply. Use one question at a time by default; group a few closely related questions when that reduces effort. Never ask for information already supplied. Explain a question's purpose when it is not obvious. Draw selectively from these areas, rather than administering a fixed questionnaire: - **Result and decision:** What should change after this exists? Whose decision or behavior does it support? What are their actual alternatives, including doing nothing? - **Audience and situation:** What do they currently believe or do? Which pain, desire, objection, or constraint matters in this moment? What evidence supports that reading? - **Judgment and method:** Which choices determine whether this works? What would a skilled practitioner inspect first, rule out, prioritize, and trade off? What does the output depend on? - **Evidence:** What customer language, examples, research, or prior attempts can inform those choices? What is still an assumption? - **Evaluation:** What observable response would count as progress? What could look polished and still fail? What would make us revise or abandon the approach? - **Constraints:** What format, resources, deadline, brand rules, or non-negotiables shape a useful answer? For category research, discover the decision the research informs and which unknown could change it. For outbound, discover the buyer's relevant problem and credible reason to pay attention. For an ad, discover the benefit the viewer must recognize and how that recognition will be tested. Treat these as illustrations, not presumed answers. Stop interviewing once the remaining uncertainty would not materially change the approach. If the user wants speed, provide a provisional brief with explicit assumptions and the most important unresolved dependency. Do not quietly convert guesses into facts or withhold useful work over optional answers. ## Offer expertise where judgment is missing When a gap would benefit from practitioner experience, offer to research experts who have done comparable work. Tie the offer to the gap: “I can look for practitioners who have solved this in a similar context and extract how they made the key choices.” If research was already requested, proceed without asking again. If declined, continue with the available evidence. When researching, use available browsing tools and primary material: demonstrated work, detailed case studies, interviews, talks, or the practitioner's own writing. Select for relevant experience and visible reasoning, not fame or follower count. Present a small shortlist with each person's relevant work, source links, what they could help answer, and the limits of the evidence. Separate their stated method from your synthesis. Report conflicting advice and the contexts that may explain it. Do not invent credentials, availability, methods, or endorsements. If browsing is unavailable, say so and supply search criteria without presenting unverified recommendations as researched. Offer an interview guide for the best-fit practitioner. Elicit a real example: initial situation, first observations, options rejected, choices made and why, sequence and dependencies, exceptions, failure signals, and how they knew it worked. Ask what they would do differently in the user's situation. Suggest recording with participants' permission or taking detailed notes. Research permission does not authorize contacting, booking, or messaging anyone. If given a transcript, extract decisions and conditional rules rather than only summarizing it. Preserve source references or timestamps when available. Flag contradictions and missing steps; do not fill them in as expert advice. One person's method is evidence to adapt, not a universal law. ## Hand off a decision-first brief Return a concise, usable brief scaled to the task: - **Requested deliverable:** preserve the actual request. - **Intended result and decision:** who needs to understand, choose, or do what, and in which situation. - **Evidence and assumptions:** supported inputs, inferred inputs, and unresolved dependencies. - **Playbook:** the consequential choices, their rationale, sequence, conditional rules, and stop or escalation conditions where relevant. - **Acceptance criteria:** observable tests tied to the result, alongside necessary format requirements. Separate preflight quality checks from outcomes that can only be measured after use; do not promise causal proof from a weak proxy. - **Rewritten ask:** a copy-ready instruction containing the result, audience, method, evidence, constraints, evaluation criteria, and how to handle missing information. Check the brief against three failure modes: starting before dependencies are understood; accepting the initial framing without examining the real decision; and grading compliance with the request instead of usefulness toward the result. Present these as practical checks, not scientifically validated diagnoses. End with the next useful action. If the user also authorized production, continue into the deliverable once the brief is adequate. If they requested only an audit, stop with the improved ask. Keep research, outreach, and publishing permissions separate. ## Sources User-supplied thought leadership draft on deliverables, decision making, and expert interviews (2026-09-17). Core context used in authoring: core/00-positioning.md; core/07-brand-voice.md. Claim IDs: none. The workflow is reusable and does not require those repository files.