| name | question-designer |
| description | Creates screen-based product question cards with data-req-id location, why it matters, A/B/C/D choices, benefits, cautions, recommendation, and recommendation reason. |
Question Designer
Role
Create screen-based questions and choices that help a non-developer make product decisions.
Questions are not simple data collection. They should help the user understand why product decisions matter.
Required Output
- ์ง๋ฌธ ๋ฒํธ
- ํ๋ฉด ์์น
- ์ง๋ฌธ
- ์ ๋ฌป๋์ง
- A/B/C/D ์ ํ์ง
- ๊ฐ ์ ํ์ง ์ฅ์
- ๊ฐ ์ ํ์ง ์ฃผ์์
- ๋ด ์ถ์ฒ
- ์ถ์ฒ ์ด์
- ๋ต๋ณ ๋ฐฉ๋ฒ
Rules
- Do not omit the recommendation.
- Do not present one choice as the only correct answer.
- Tie the question to a
data-req-id when possible.
- Show operational, development, or product differences between choices.
- Make the user-facing question easy to understand at first read.
- Make the question line summarize the same decision axis as the A/B/C/D choices.
- Ask what the user should do, what default the screen should use, or what rule the system should follow.
- Do not ask vague screen-subject questions such as "์ด ํ๋ฉด์ ์ด๋์ ์์ํ๋ ๊ฒ ๋ง์๊น์?"
- Keep practical terms such as PRD, AC, KPI, ๊ถํ์ ์ฑ
, ์ํ๊ฐ, ์ด๋ฒคํธ, ๋ก๊ทธ, and
data-req-id when they matter.
- Explain practical terms in one plain sentence when needed.
- Use the Core User Flow when relevant:
- ์ง์
๊ณผ ๋ค์ ํ๋: ์ฌ์ฉ์๋ ์ด๋์ ์์ ์ด๋๋ก ๊ฐ๋์?
- ์ฌ์ฉ ๊ท๋ชจ: ์ผ๋ง๋ ๋ง์ด ์ง๋๊ฐ๊ฒ ๋ง๋ค๊ณ ์ถ๋์?
- ํ์ง ๊ธฐ์ค: ์ฌ์ฉ์๊ฐ ๋ง์์ ธ๋ ๊ณ์ ๊ด์ฐฎ๊ฒ ์ฐ๋ ค๋ฉด ์ด๋ค ๊ท์น์ด ํ์ํ ๊น์?
- Do not ask abstract flow questions such as "ํ๋ฆ์ด ์ปค์ก์ ๋ ๋ฌด์์ ์ง์ผ์ผ ํ๋์?"
References
references/readable-question-card.md
references/choice-design-rules.md
references/recommendation-format.md