Use when the user asks for competitive analysis, landscape analysis, desk research, market research, or a UX design brief on any topic. Triggers on: "research X", "competitive analysis of X", "landscape of X", "desk research on X", "what's out there for X", "brief on X".
Run structured web research and save a reviewable design brief to skills/secondary-research/outputs/.
The brief serves two readers: the PM (strategic review before approving) and the prototype-agent (execution). Both need different content. Produce all sections — PM-oriented sections provide strategic grounding; prototype-specific sections provide the parsed inputs the prototype-agent reads directly.
The brief must do two things: document what exists and interrogate whether the framing is correct. A brief that only documents findings is incomplete. Apply pressure to the opportunity — name what the evidence actually supports, where the window is closing, and what must be resolved before building anything.
Ask the user for these if not already provided:
competitive | landscape | desk (required)quick | standard | deep (default: standard)Topic scope check — do this before searching: If the topic is a single generic word or broad category (e.g. "fintech", "healthcare", "technology", "payments"), stop and ask:
"That topic is quite broad. Can you specify a segment, geography, user group, or product type? For example, instead of 'fintech', try 'remittance apps in Southeast Asia'." Only proceed once the topic is specific enough to surface actionable findings.
| Depth | Searches | Use when |
|---|---|---|
| quick | 3 | Fast scan, early exploration |
| standard | 6 | Typical research brief |
| deep | 10 | High-stakes design decision |
Run searches one at a time. After each, assess: do you have enough to answer the research question, or does the next search still add value?
Recency: Prioritize sources from the last 2 years. If you use an older source, note its year explicitly in the citation. Avoid presenting dated findings as current without flagging them.
Thin results check: After the first 3 searches, if findings are sparse, too generic, or mostly opinion with no data, stop and tell the user:
"Research on this topic returned limited results. The brief may be too shallow to inform design decisions. Options: (1) narrow the topic, (2) switch mode, or (3) proceed with a caveat flagged in Open Questions." Do not silently produce a shallow brief.
competitive — Who are the key players? What UX patterns and interaction conventions do they use? What do users love/hate (reviews, forums)? Where are the gaps? What is the consistent structural gap across all players — the thing nobody has built?
Useful query types: product names, "[product] UX review", "[product] alternatives", "[product] complaints", "[category] design patterns"
landscape — What is the full shape of this problem space? Who are the user segments? What mental models exist? What trends are emerging? Who are the institutional players (government, NGOs, major corps) already moving in this space?
Useful query types: "[topic] industry trends", "[topic] user research", "jobs to be done [topic]", "future of [topic]", "[topic] market segments"
desk — What existing research, data, and reports exist? What behavioral patterns and constraints affect design decisions? What standards or regulations apply?
Useful query types: "[topic] research report", "[topic] UX case study", "[topic] user behavior study", "[topic] statistics", "[topic] accessibility standards"
Apply these rules throughout research and writing. They are non-negotiable.
Before drafting the brief, compile a private source ledger:
Every factual claim — statistics, product descriptions, user behavior findings, market data — must be traceable to a ledger source. If you cannot bind a claim to a source:
[unverified — flag for primary research]Never write a percentage, figure, or numeric statistic without the exact source URL inline. If a stat appears in your memory but was not returned in search results this session, it must not appear in the brief. Write instead: [stat not retrieved this session — verify before use]
Before finalizing the Sources section, run this check internally:
"For each
[^n]footnote in the brief: was this URL returned in my search results this session? If no → remove the footnote and replace the claim with [unverified]."
No footnote may exist without a corresponding retrieved URL.
Use these inline markers when certainty varies:
| Marker | When to use |
|---|---|
[verified] | Directly supported by a retrieved source |
[inferred] | Reasonable inference from retrieved sources — not stated directly |
[unverified] | Cannot be bound to a retrieved source — must not drive design decisions |
If a section has no retrieved signal, write:
"No clear signal found — recommend primary research before making design decisions in this area."
Do not fill gaps with plausible-sounding content. Silence is more useful than confident fabrication.
Produce the design brief in this exact structure. Start directly with the frontmatter — no preamble. There is no word count cap — be comprehensive. A thorough analytical brief is more valuable than a short one.
---