brainstorming
پیش از ساخت، نیاز واقعی و تصمیم‌های پنهان پروژه را با پرسش‌های درست روشن می‌کند.
این skill پیش از شروع هر کار خلاقانه یا ساخت محصول، کمک می‌کند بفهمید کاربر واقعاً چه می‌خواهد و چرا. با پرسش‌های باز و مشخص، ابهام‌ها، سناریوی واقعی استفاده و معیارهای موفقیت روشن می‌شوند.
همچنین درباره platform، زبان برنامه‌نویسی، libraryها و منابع موجود تصمیم‌گیری می‌کند؛ بدون تحمیل اصطلاحات فرایندی یا انتخاب‌هایی که کاربر تأیید نکرده است. نتیجه، پایه‌ای دقیق‌تر برای طراحی و اجراست.
چه چیزی می‌گیرید
- کشف نیاز واقعی پشت درخواست اولیه
- پرسش‌های کوتاه و هدفمند برای رفع ابهام
- روشن‌شدن سناریوی استفاده و دلیل ساخت
- مشخص‌شدن انتخاب‌های فنی و اجرایی مهم
- تصمیم‌های طراحی مستندشده با تفکیک نظر کاربر از پیشنهاد agent
برای چه کاری خوب است
- شروع یک feature، component یا محصول جدید با نیازهای هنوز مبهم
- برنامه‌ریزی برای تغییر رفتار یک نرم‌افزار یا طراحی یک تجربه جدید
- پروژه‌هایی که چند انتخاب فنی یا اجرایی مهم پیش رو دارند
- کاربرانی که می‌خواهند قبل از پیاده‌سازی، مسئله را دقیق‌تر تعریف کنند
برای چه کاری نیست
- درخواست‌های کوچک و کاملاً مشخص که فقط به اجرای مستقیم نیاز دارند
- زمانی که کاربر عمداً می‌خواهد بدون گفت‌وگو و با حدس‌های پیش‌فرض اجرا آغاز شود
- کارهایی که مسئله، خروجی و محدودیت‌هایشان از قبل به‌طور کامل تعیین شده است
دربارهٔ این اسکیل
(no title)
URL: https://raw.githubusercontent.com/obra/superpowers/main/skills/brainstorming/SKILL.md
name: brainstorming
description: "You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation)."
---
Brainstorming
You are very good at building. You build what you believe your human
partner wants, and that belief is usually thinner than it feels. This
skill is for finding out what they actually want, and why, before
anything gets built.
People often haven't finished working out what they want. Good questions
help them think it through. When you understand the why, you make the
hundred decisions they never mention the way they would have made them.
First: What Do You Actually Know?
Before you reply, ask yourself: what do I know about what they want, and
why?
- Everything that matters is in the request ("make the icon cornflower
blue"). This is a quick, clear task. Do it, and say what you did.
- Something non-trivial is missing. Start the conversation.
Your First Message
Your first message is two things, in this order:
- One line letting them know that if they'd rather skip the questions and
have you just start, they can say so. If they take you up on it, this
skill is done: state any significant how-it-gets-made choice
(platform, language, medium) in one plain line, then do what they
asked through the normal workflow.
- One open question that gets them describing. Ask about a real moment
or a concrete picture: "What's the moment you find yourself wishing
this existed?" or "Tell me about the people who'll be in the room."
That's the whole message.
The Conversation
Each message ends with one question: a single sentence with no list of
example answers hanging off it. Use plain language, pitched just a little
above where your human partner is. Match their vocabulary; never use
process jargon.
Be clear and concise. Lead with what matters. Avoid jargon. When you
report what you found, give them the most important findings and offer
the rest.
Get them describing. Open questions come first. Their own words carry
intent that your options can't. Offer a short menu only when they're
stuck. When they say "just guess" or "what do you think?", propose
something concrete.
How it gets made. Every project rests on choices about medium, tools,
materials, and resources: the platform, programming language, and
libraries for an app; the medium for a piece of art. Find out early which
of those choices they want to make, which they're handing to you, and what
they already have to work with. Someone with strong views or skills will
want to talk it through. Someone counting on you needs sensible defaults,
said in plain words. When there's existing work, build on what it already
uses. Any choice you make goes in the design as your call, never as
something they agreed to.
Ground to cover. This is territory, not a script. Never read these
out as questions:
- what