Interleave parallel background research agents with brainstorming so design decisions are continuously fed by verified, up-to-date technical knowledge instead of assumptions. Use during the design/brainstorming phase of any non-trivial feature where the prompt embeds claims, feasibility questions, or "is this even possible?" assumptions (e.g. "the buttons should morph", "this should sync in real time", "reuse the existing X"). Triggers on "research while we design", "verify the assumptions in this prompt", "spin up research agents as we clarify", "ground this design in the real APIs/codebase", "is this technically feasible", or whenever brainstorming a feature that depends on unfamiliar APIs, framework limits, or existing code you have not yet read.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
research-augmented-design
description
Interleave parallel background research agents with brainstorming so design decisions are continuously fed by verified, up-to-date technical knowledge instead of assumptions. Use during the design/brainstorming phase of any non-trivial feature where the prompt embeds claims, feasibility questions, or "is this even possible?" assumptions (e.g. "the buttons should morph", "this should sync in real time", "reuse the existing X"). Triggers on "research while we design", "verify the assumptions in this prompt", "spin up research agents as we clarify", "ground this design in the real APIs/codebase", "is this technically feasible", or whenever brainstorming a feature that depends on unfamiliar APIs, framework limits, or existing code you have not yet read.
Most design dialogue fails one of two ways: you ask every clarifying question
serially and only research afterward (so the design is built on unverified
assumptions and gets re-litigated once reality intrudes), or you research
everything upfront blindly (so you waste effort on aspects the user will rule
out in one sentence).
This skill is the third way: interleave verification with clarification. As
each aspect of the request gets clarified, dispatch parallel background
research agents that verify the assumptions and gather the technical knowledge
embedded in the prompt and your clarifying questions. The design conversation is
then continuously fed by verified, current knowledge — and the same research
reports get reused in the planning and implementation phases instead of thrown
away.
Core principle: A prompt is full of claims ("the buttons should morph", "it
should sync across devices", "reuse the existing sheet"). Treat each as a
hypothesis to verify you design, not a fact to discover is false during
implementation. Surface the binding constraints early, when changing course is
free.
while
This skill is an overlay on brainstorming (it does not replace it) and applies
dispatching-parallel-agents to the design phase. Use all three together.
When to use
flowchart TD
A{Designing a feature?} -->|yes| B{Prompt embeds claims/<br/>assumptions/feasibility?}
B -->|yes| RAD[Research-augmented design]
B -->|no| C{Depends on unfamiliar APIs<br/>or unread existing code?}
C -->|yes| RAD
C -->|no| PB[Plain brainstorming]
Use when: the design hinges on whether something is technically possible, on
how an unfamiliar API actually behaves, on framework limits you are guessing at,
or on existing code you have not yet read. Especially when the user signals they
want the knowledge to outlive the chat ("this will be reused in planning").
Skip when: the feature is small and fully within known territory — no
external APIs, no unread code, no feasibility risk. Plain brainstorming is
enough.
The loop
flowchart TD
E[Extract verifiable claims<br/>from the prompt] --> A[Ask process/scope Qs first<br/>how to dispatch research]
A --> D[Dispatch foundational agents<br/>design-independent aspects]
D --> C[Clarify next design aspect<br/>one question at a time]
C --> N{New aspect needs verifying?}
N -->|yes| S[Spin up a fresh agent<br/>for that aspect]
N -->|no| F{Findings contradict a<br/>design assumption?}
S --> F
F -->|yes| R[Surface it, revise design]
F -->|no| AP{Design approved?}
R --> C
AP -->|no| C
AP -->|yes| H([Hand reports to writing-plans])
Step 1 — Extract verifiable claims from the prompt
Before asking anything, read the prompt as a list of hypotheses. For each, note
what would have to be true for it to work and how you would confirm it.
In the prompt
Hidden hypothesis
What to verify
"the buttons should morph between layouts"
The chosen mechanism supports continuous interpolation
Which API does it; what are its limits on this platform version
"reuse the existing sheet"
The existing code can be extended without a rewrite
Read it: how is it structured, what's its state model
"it should sync in real time"
The sync layer propagates this kind of change
How the sync engine actually behaves for this data
"open compact, expand to full"
The container exposes the state you need to drive layout
Does the API expose the signal (e.g. drag progress) you assume
The verifiable claims become your research agents. The genuinely-ambiguous
choices become your clarifying questions.
Step 2 — Ask process/scope questions first
Before launching agents, settle how research should run. These are the user's
calls, and they change everything downstream. Use AskUserQuestion:
Dispatch mode — background Agents feeding the live dialogue, a single
consolidated research Workflow, or hold research until the design is locked.
Workflow scope — which phases (research, implementation, both) get encoded
as autonomous Workflow runs vs. stay interactive.
Persistence / worktree — where research reports and the spec should live.
Note the key constraint up front: a Workflow runs autonomously and cannot pause
to ask the user mid-run, so interactive design must stay outside it. Background
Agents are the default for research that should feed an ongoing conversation.
Step 3 — Dispatch foundational agents immediately
Launch the agents whose scope is fixed regardless of remaining design
decisions. There are almost always two:
Capability research — how the unfamiliar API / framework actually works,
including version-specific limits. Have it consult current docs (context7,
official sources) and relevant skills, not just training memory.
Codebase reconnaissance — how the existing code you intend to touch is
actually built (the feature, its state model, the components, the data model).
Run them in the background (run_in_background: true) so they work while you
keep clarifying. Give them names so you can SendMessage follow-ups with their
context intact.
Each agent MUST write a persistent report, not just return prose. A known
location (e.g. docs/<...>/research/<topic>.md) means the knowledge survives
into planning and implementation. State this explicitly in the agent prompt:
"Write a comprehensive markdown report to <path> AND return a summary."
Agent prompt template:
Research <specific topic> for <feature>, targeting <platform/version>.
Cover: <enumerated sub-questions / the hypotheses from Step 1>.
Consult <current docs source> and <relevant skills>; do not rely on memory alone.
Write a comprehensive report to docs/<...>/research/<topic>.md, then return a
concise summary of the findings and any constraints that affect the design.
Step 4 — Spin up fresh agents as aspects clarify
This is the "augmented" part. Each time a clarifying answer opens a new
technical question (accessibility implications, performance under load, an edge
case), dispatch a new targeted agent for it — in parallel, in the background.
The goal is that by the time the design is settled, every assumption in it has a
verified report behind it. Do not batch all research into one upfront blob; let
the conversation pull research into existence.
Step 5 — Feed findings back into the design
When an agent reports:
Restate the finding in your own text (the user/extractor cannot see tool
output) and say which design assumption it confirms or breaks.
If it breaks an assumption, surface it immediately and revise — that is the
entire point of doing this during design rather than during implementation.
Weave confirmed constraints into the next clarifying question so the user is
choosing among feasible options.
Step 6 — Hand the reports to planning
When the design is approved, the accumulated research reports are the technical
backbone of the implementation plan. Invoke writing-plans and reference them.
Nothing researched is wasted.
Red flags
Thought
Reality
"I'll just assume the API supports this"
That assumption is the #1 source of late rework. Verify it now.
"Let me research everything before asking anything"
You'll burn effort on aspects the user rules out in one sentence. Clarify scope first.
"I'll run the research as a Workflow so it's one clean call"
Workflows can't feed a live conversation. Use background Agents for interactive design.
"The agent returned a summary, that's enough"
Without a persisted report the knowledge dies with the turn. Require a written report.
"All the research can go in one upfront agent"
New aspects surface as you clarify. Spin up fresh agents as the design evolves.
"Findings confirmed my plan, no need to mention them"
Restate findings in text — the user and downstream extractor can't see tool output.
Relationship to other skills
brainstorming — this skill overlays it; you still ask one question at a
time, propose approaches, present and get approval on the design. This adds the
parallel verification loop.
dispatching-parallel-agents — this skill is that pattern applied to the
design phase: one agent per independent verifiable claim, run concurrently.
writing-plans — the terminal hand-off; the research reports feed the plan.
