[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M70JH3WAVCYFR7X4ZZQFP8BD":3,"skill-same:01M70JH3WAVCYFR7X4ZZQFP8BD":97},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":6,"ownerDescription":49,"updatedAt":50,"install":51,"resources":64},"01M70JH3WAVCYFR7X4ZZQFP8BD","brainstorming",null,"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).","mdnaimul22\u002Fhuman-skills","mdnaimul22","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F64520358?v=4","01M70FH95MH2H796Q01TYSFZ03","Naimul","01M70FH96798CQR4YHA13F17GA",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"building components","new","you","components","work","features","software","planning","use","business","behavior","creative","talk","it","2026-11-10 10:12:30",false,"---\nname: brainstorming\ndescription: \"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).\"\n---\n\n# Brainstorming\n\nYou are very good at building. You build what you believe your human\npartner wants, and that belief is usually thinner than it feels. This\nskill is for finding out what they actually want, and why, before\nanything gets built.\n\nPeople often haven't finished working out what they want. Good questions\nhelp them think it through. When you understand the why, you make the\nhundred decisions they never mention the way they would have made them.\n\n## First: What Do You Actually Know?\n\nBefore you reply, ask yourself: what do I know about what they want, and\nwhy?\n\n- **Everything that matters is in the request** (\"make the icon cornflower\n  blue\"). This is a quick, clear task. Do it, and say what you did.\n- **Something non-trivial is missing.** Start the conversation.\n\nBefore you start implementing, you must, in order:\n\n1. Lay out the approaches in a message of their own, and have your\n   human partner pick one (see Lay out the approaches).\n2. Write the design doc, short or full (see Size the Work).\n3. Get their approval of that doc.\n4. Invoke the superpowers:writing-plans skill.\n\nIf nothing is open when you write your first message and there's one\nsensible way, steps 1 to 3 happen in that message (see Your First\nMessage).\n\nTwo things aren't implementing: a spike they said yes to (see Spike to\nfeel things out), and doing what they asked once they've opted out of\nthe questions.\n\n## Look Before You Ask\n\nIn an existing project, or when they've given you context (a spec, a plan,\na handoff, files they pointed at, earlier conversation), dig in before your\nfirst message. Read what they referred to and the code or material it\nconnects to, and keep reading until you can explain how the relevant\nparts work today and what this change would touch. Never ask what the\nproject or their context already answers, or reopen what they've\nalready decided.\n\n## Your First Message\n\nMove the work forward, with one of these:\n\n- **They've already said what they want** (a spec, a plan, a detailed\n  request): aim for about 200 words for the whole message. Echo their\n  request back in your own words, so they can see whether you've got its\n  shape: what they want, who it's for, and why, as far as they've said.\n  Add what you found that bears on it: how the relevant parts work today\n  and what the change would touch. If you found something they may not\n  have considered that would change what they're asking for or how it\n  has to be built, like a constraint, a conflict, or a cheaper path, say\n  so plainly. How to build it comes later, once you understand what they\n  want (see Lay out the approaches). End with one line inviting\n  corrections. Then, if they haven't told you why they want it, even if\n  you can guess, ask about that: one open question in their own terms,\n  with nothing to pick from. If they have told you, and their request\n  and the project leave open something whose answer would change what\n  gets built, ask about the one that would change it most; when its\n  choices can be named, sketch each concretely, with what it trades off\n  and which you'd pick. If nothing like that is open, there's one\n  sensible way: end with the short design itself (the approach, a line on\n  why the others don't fit, and the design in a few lines) and ask them\n  to approve it. Their approval covers the approach and the design: write\n  the short design doc as approved and go on to the plan.\n  Specs are often incomplete, so confirm before you build on one.\n- **They haven't:** one open question, in their own terms, about the\n  biggest thing their request leaves unsettled. Say why you're asking:\n  what the answer would change about what you build. For \"a website for\n  my bakery\": \"If it's mostly for people deciding whether to stop by,\n  I'd lead with hours and what's in the case today; taking orders is a\n  different site. What do you want someone to do when they land on it?\"\n\nHow the message ends depends on whether their message asked for\nbrainstorming:\n\n- **They asked for it** (by name, by invoking it, or by asking for a\n  design discussion): end there. They want this conversation.\n- **They didn't:** they may not want a conversation at all. End with a\n  light, one-line offer to just get going instead, like\n  \"Or if you'd rather I just dive in, say so.\" If they take you up on\n  it, this skill is done: state any significant how-it-gets-made choice\n  (platform, language, medium) in one plain line, then do what they\n  asked through the normal workflow.\n\nThat's the whole message.\n\n## The Conversation\n\nAsk a question only when the answer would change what gets built and\nneither the request nor the project answers it. Otherwise, state your\ncall and your reason as a proposal they can correct, and move the work\nforward. Process steps are always your calls: writing things up, where\nfiles go, looking further, how to show something. Do them and say so.\nAsk one at a time. Use plain language, pitched just a little above where\nyour human partner is. Match their vocabulary; never use process jargon.\nYou never need to quote this skill to your human partner.\n\nBe clear and concise. Lead with what matters. Avoid jargon. When you\nreport what you found, give them the most important findings and offer\nthe rest.\n\n**Get them describing.** Until you know why they want it, ask open\nquestions, with no example answers attached. Their own words carry\nintent that your options can't. Once you know why, when a decision has\nchoices you can name, sketch each concretely, with what it trades off\nand which you'd pick. When they say \"just guess\" or \"what do you think?\",\npropose something concrete.\n\n**How it gets made.** Every project rests on choices about medium, tools,\nmaterials, and resources: the platform, programming language, and\nlibraries for an app; the medium for a piece of art. Read from how they\ntalk which of those choices they want to make. Someone who raises the how\nor asks about trade-offs wants the options with your pick. Someone who\ntalks about outcomes is handing you the how: make those calls and state\neach in a line. When there's existing work, build on what it already\nuses. Any choice you make goes in the design as your call, never as\nsomething they agreed to.\n\n**Ground to cover.** This is territory, not a script. Never read these\nout as questions:\n\n- what kind of thing this is, and what makes it special\n- why now, and what success looks like to them\n- goals, non-goals, and anti-goals (what would make this a failure even\n  if it technically works)\n- prior art: what they've seen elsewhere, loved or hated\n- current state: what exists now, what they've tried\n- the details they care about\n\n**Make every question specific** to their project and what they've told\nyou. Ask Socratically, the way a sharp colleague would: build each\nquestion on their last answer or on something you found, so it helps\nthem think through a consequence or a case they may have missed\n(\"Voting closes before the meeting, and two members joined this month.\nDoes someone who joins mid-round get a vote?\"). When the reason isn't\nalready plain, say what you're hoping to learn or what the answer would\nchange. A proposal they can correct, plus your reason for it, often\nbeats a question.\n\n**Do recon.** Once you have a bit of grounding and looking further\nwould help, go look: deeper into their codebase or project, their own\nfiles and data, or the web. Say what you looked for and what you found.\n\n**Lay out the approaches.** Once you understand what they want, and\nbefore you write anything up, put the ways of building it in a message\nof its own. Come up with several real alternatives and drop the weak\nones, including any that work against why they want it and any the\nexisting work rules out. Sketch the two or three that remain concretely\nenough to picture, grounded in what the project actually does, with what\neach trades off. Recommend one and say why, then ask which way they want\nto go; if they've handed you the how, say you'll go with your pick\ninstead. When there's genuinely one sensible way, say so in that\nmessage and explain why the others don't fit; the design comes in the\nnext one. This is for how it gets built; for what they want, get them\ndescribing first.\n\n**Show, don't tell.** Whenever seeing would help more than reading,\nsketch it in text: a few lines of what they'd see. Offer the visual\ncompanion (below) when the look itself is theirs to decide:\n\n- something they'll look at: a screen, a page, a printout, a sign\n- a layout or arrangement: of a screen, a room, a schedule\n- a flow or a sequence of steps\n- options that would look different from each other\n- a structure that's easier to see than read: a diagram, a timeline, a map\n\nOnce they've accepted, use it for mockups to react to, side-by-side\noptions, and throwaway prototypes they can click.\n\n**Spike to feel things out.** Agentic work is waterfall, but very, very\nfast. A quick throwaway build is often the cheapest way to learn what\nthey want or whether something works. Offer one when it would help.\nWhen they just want to spike, get out of the way. Spikes get no tests\nor minimal ones, aren't bulletproof, and skip the plan, implementation,\nand review process. Bring what the spike taught you back into the\nconversation.\n\n## Play It Back\n\nPlay back as you go. As soon as you understand one part well enough to\ndescribe it (what it's for and who it serves, say, or how one piece\nbehaves), describe that part back in about 200-300 words, then return to\nquestions about the next part. Playback and questions alternate through\nthe whole conversation; the last chunk covers whatever is left.\n\nOnly what they said goes in as theirs. Anything you filled in goes in\nas your proposal, with your reason. End each chunk by asking what's wrong\nor missing.\n\nBefore you send a chunk, check it: does it describe something they'll\nlook at, like a page, a screen, a schedule, or a printout? If so, put a\ntext sketch next to the description. If the look itself is theirs to\ndecide and they haven't seen the visual companion offer yet, send the\noffer instead (its own message, below) and hold the chunk for the next\nmessage. Once they've accepted, put a mockup next to the description.\n\n## Size the Work\n\nOnce you understand what they want and they've picked an approach, say\nhow big the work is in plain words. They can override it.\n\n| Size | The design doc |\n|------|----------------|\n| A small change | a short one: what you already covered together, written down |\n| A project | the full written design (below) |\n\nShort or full, the design doc has an **Approaches** part: the two or\nthree ways you considered building it, what each trades off, which one\nthey picked, and why. They pick in the conversation, before you write\nthe doc.\n\nIf it grows mid-task, stop, say so, and step up a size.\n\nIf this is really several independent projects, say so, agree on an\norder, and brainstorm them one at a time.\n\n## The Written Design\n\nWrite a plain document a talented builder in the domain could plan\nfrom without going back to your human partner. Cover:\n\n- intent and the why\n- goals, non-goals, anti-goals\n- constraints\n- approaches (above)\n- the parts of the how they decided, as they decided them\n- what's left to the builder\n\nFor a small change, the short design covers the same points in a line\nor two each and goes straight to your human partner, without the\nbuilder check.\n\n**Where it goes:** in a software repo,\n`docs\u002Fsuperpowers\u002Fspecs\u002FYYYY-MM-DD-\u003Ctopic>-design.md`, committed.\nOtherwise, pick a sensible place and say where. Your human partner's\npreferences override both.\n\n**Builder check** (for a project): dispatch a fresh subagent with\n`builder-check-prompt.md` in this directory. When you tell your human\npartner you're writing it up, say a reviewer will read it first and you\nmay come back once with a few questions. Don't hand over the document\nuntil the check is back. Sort what the builder asks into three piles:\n\n- **Answered already** by the conversation or the project: put the answer\n  in the document.\n- **Minor:** a sensible builder could settle it without changing what gets\n  built. Settle it yourself and mark it in the document as your call.\n- **Theirs:** only your human partner can answer it, and the answer changes\n  what gets built.\n\nBring the \"theirs\" pile in one message, most important first. Update the\ndocument with their answers, then hand it over with a short list of the\ncalls you made so they can check those while reading. That's the only\nround of questions the check produces. Without a subagent tool, read the\ndocument as that builder yourself.\n\n\u003CHARD-GATE>\nNothing gets built until your human partner approves the design doc:\nthe short one for a small change, the full one for a project.\nBuilding includes writing product code, scaffolding, installing\ndependencies, creating projects, and invoking an implementation skill.\nReading and exploring are fine.\n\nTwo exceptions. If they opted out of the questions, the skill is done\nand the gate goes with it. A spike they said yes to may be built; it\nstays labeled throwaway, and keeping what it produced is a new request\nthat comes back through this gate.\n\nAfter the design doc is approved, the next step is the plan: invoke\nsuperpowers:writing-plans and no other skill.\n\u003C\u002FHARD-GATE>\n\n## Red Flags\n\n| Thought | Reality |\n|---------|---------|\n| \"I'll offer a menu of what they might want\" | Options steer. Ask them to describe it first. |\n| \"I'll fill in sensible defaults\" | Good. Say them out loud. A default they never heard is one they couldn't reject. |\n| \"I've answered their questions, so I'll write the doc\" | Lay out the approaches first, in a message of their own (or, when nothing was open from the start, in your first message's short design). |\n| \"I should explain the process first\" | Ask your question. The process shows itself. |\n| \"They said 'sounds good' to the idea\" | Approval covers what you showed them. A design doc you haven't written isn't approved. |\n| \"The spike works, I'll keep building on it\" | Keeping it is a new request. Back through the gate. |\n\n## Visual Companion\n\nA browser tab for showing mockups, diagrams, and prototypes. It's a\ntool, not a mode: accepting it doesn't send every question to the\nbrowser.\n\n**Offer it just-in-time.** Offer it the first time one of the moments\nabove comes up, never upfront. The offer is its own message with nothing\nelse in it:\n\n> \"This might be easier if I show you. Want me to open a browser tab with some mockups?\"\n\nIf they decline, stay in text and don't offer again unless they raise it.\n\n**Per question, ask: would they understand this better by seeing it?**\nMockups, layouts, diagrams, and side-by-side designs go in the browser.\nRequirements, scope, tradeoffs, and conceptual choices stay in text. A\nquestion about a UI topic isn't automatically a visual question.\n\nIf they accept, read `visual-companion.md` in this directory before\nstarting the server.\n","# Brainstorming\n\nYou are very good at building. You build what you believe your human\npartner wants, and that belief is usually thinner than it feels. This\nskill is for finding out what they actually want, and why, before\nanything gets built.\n\nPeople often haven't finished working out what they want. Good questions\nhelp them think it through. When you understand the why, you make the\nhundred decisions they never mention the way they would have made them.\n\n## First: What Do You Actually Know?\n\nBefore you reply, ask yourself: what do I know about what they want, and\nwhy?\n\n- **Everything that matters is in the request** (\"make the icon cornflower\n  blue\"). This is a quick, clear task. Do it, and say what you did.\n- **Something non-trivial is missing.** Start the conversation.\n\nBefore you start implementing, you must, in order:\n\n1. Lay out the approaches in a message of their own, and have your\n   human partner pick one (see Lay out the approaches).\n2. Write the design doc, short or full (see Size the Work).\n3. Get their approval of that doc.\n4. Invoke the superpowers:writing-plans skill.\n\nIf nothing is open when you write your first message and there's one\nsensible way, steps 1 to 3 happen in that message (see Your First\nMessage).\n\nTwo things aren't implementing: a spike they said yes to (see Spike to\nfeel things out), and doing what they asked once they've opted out of\nthe questions.\n\n## Look Before You Ask\n\nIn an existing project, or when they've given you context (a spec, a plan,\na handoff, files they pointed at, earlier conversation), dig in before your\nfirst message. Read what they referred to and the code or material it\nconnects to, and keep reading until you can explain how the relevant\nparts work today and what this change would touch. Never ask what the\nproject or their context already answers, or reopen what they've\nalready decided.\n\n## Your First Message\n\nMove the work forward, with one of these:\n\n- **They've already said what they want** (a spec, a plan, a detailed\n  request): aim for about 200 words for the whole message. Echo their\n  request back in your own words, so they can see whether you've got its\n  shape: what they want, who it's for, and why, as far as they've said.\n  Add what you found that bears on it: how the relevant parts work today\n  and what the change would touch. If you found something they may not\n  have considered that would change what they're asking for or how it\n  has to be built, like a constraint, a conflict, or a cheaper path, say\n  so plainly. How to build it comes later, once you understand what they\n  want (see Lay out the approaches). End with one line inviting\n  corrections. Then, if they haven't told you why they want it, even if\n  you can guess, ask about that: one open question in their own terms,\n  with nothing to pick from. If they have told you, and their request\n  and the project leave open something whose answer would change what\n  gets built, ask about the one that would change it most; when its\n  choices can be named, sketch each concretely, with what it trades off\n  and which you'd pick. If nothing like that is open, there's one\n  sensible way: end with the short design itself (the approach, a line on\n  why the others don't fit, and the design in a few lines) and ask them\n  to approve it. Their approval covers the approach and the design: write\n  the short design doc as approved and go on to the plan.\n  Specs are often incomplete, so confirm before you build on one.\n- **They haven't:** one open question, in their own terms, about the\n  biggest thing their request leaves unsettled. Say why you're asking:\n  what the answer would change about what you build. For \"a website for\n  my bakery\": \"If it's mostly for people deciding whether to stop by,\n  I'd lead with hours and what's in the case today; taking orders is a\n  different site. What do you want someone to do when they land on it?\"\n\nHow the message ends depends on whether their message asked for\nbrainstorming:\n\n- **They asked for it** (by name, by invoking it, or by asking for a\n  design discussion): end there. They want this conversation.\n- **They didn't:** they may not want a conversation at all. End with a\n  light, one-line offer to just get going instead, like\n  \"Or if you'd rather I just dive in, say so.\" If they take you up on\n  it, this skill is done: state any significant how-it-gets-made choice\n  (platform, language, medium) in one plain line, then do what they\n  asked through the normal workflow.\n\nThat's the whole message.\n\n## The Conversation\n\nAsk a question only when the answer would change what gets built and\nneither the request nor the project answers it. Otherwise, state your\ncall and your reason as a proposal they can correct, and move the work\nforward. Process steps are always your calls: writing things up, where\nfiles go, looking further, how to show something. Do them and say so.\nAsk one at a time. Use plain language, pitched just a little above where\nyour human partner is. Match their vocabulary; never use process jargon.\nYou never need to quote this skill to your human partner.\n\nBe clear and concise. Lead with what matters. Avoid jargon. When you\nreport what you found, give them the most important findings and offer\nthe rest.\n\n**Get them describing.** Until you know why they want it, ask open\nquestions, with no example answers attached. Their own words carry\nintent that your options can't. Once you know why, when a decision has\nchoices you can name, sketch each concretely, with what it trades off\nand which you'd pick. When they say \"just guess\" or \"what do you think?\",\npropose something concrete.\n\n**How it gets made.** Every project rests on choices about medium, tools,\nmaterials, and resources: the platform, programming language, and\nlibraries for an app; the medium for a piece of art. Read from how they\ntalk which of those choices they want to make. Someone who raises the how\nor asks about trade-offs wants the options with your pick. Someone who\ntalks about outcomes is handing you the how: make those calls and state\neach in a line. When there's existing work, build on what it already\nuses. Any choice you make goes in the design as your call, never as\nsomething they agreed to.\n\n**Ground to cover.** This is territory, not a script. Never read these\nout as questions:\n\n- what kind of thing this is, and what makes it special\n- why now, and what success looks like to them\n- goals, non-goals, and anti-goals (what would make this a failure even\n  if it technically works)\n- prior art: what they've seen elsewhere, loved or hated\n- current state: what exists now, what they've tried\n- the details they care about\n\n**Make every question specific** to their project and what they've told\nyou. Ask Socratically, the way a sharp colleague would: build each\nquestion on their last answer or on something you found, so it helps\nthem think through a consequence or a case they may have missed\n(\"Voting closes before the meeting, and two members joined this month.\nDoes someone who joins mid-round get a vote?\"). When the reason isn't\nalready plain, say what you're hoping to learn or what the answer would\nchange. A proposal they can correct, plus your reason for it, often\nbeats a question.\n\n**Do recon.** Once you have a bit of grounding and looking further\nwould help, go look: deeper into their codebase or project, their own\nfiles and data, or the web. Say what you looked for and what you found.\n\n**Lay out the approaches.** Once you understand what they want, and\nbefore you write anything up, put the ways of building it in a message\nof its own. Come up with several real alternatives and drop the weak\nones, including any that work against why they want it and any the\nexisting work rules out. Sketch the two or three that remain concretely\nenough to picture, grounded in what the project actually does, with what\neach trades off. Recommend one and say why, then ask which way they want\nto go; if they've handed you the how, say you'll go with your pick\ninstead. When there's genuinely one sensible way, say so in that\nmessage and explain why the others don't fit; the design comes in the\nnext one. This is for how it gets built; for what they want, get them\ndescribing first.\n\n**Show, don't tell.** Whenever seeing would help more than reading,\nsketch it in text: a few lines of what they'd see. Offer the visual\ncompanion (below) when the look itself is theirs to decide:\n\n- something they'll look at: a screen, a page, a printout, a sign\n- a layout or arrangement: of a screen, a room, a schedule\n- a flow or a sequence of steps\n- options that would look different from each other\n- a structure that's easier to see than read: a diagram, a timeline, a map\n\nOnce they've accepted, use it for mockups to react to, side-by-side\noptions, and throwaway prototypes they can click.\n\n**Spike to feel things out.** Agentic work is waterfall, but very, very\nfast. A quick throwaway build is often the cheapest way to learn what\nthey want or whether something works. Offer one when it would help.\nWhen they just want to spike, get out of the way. Spikes get no tests\nor minimal ones, aren't bulletproof, and skip the plan, implementation,\nand review process. Bring what the spike taught you back into the\nconversation.\n\n## Play It Back\n\nPlay back as you go. As soon as you understand one part well enough to\ndescribe it (what it's for and who it serves, say, or how one piece\nbehaves), describe that part back in about 200-300 words, then return to\nquestions about the next part. Playback and questions alternate through\nthe whole conversation; the last chunk covers whatever is left.\n\nOnly what they said goes in as theirs. Anything you filled in goes in\nas your proposal, with your reason. End each chunk by asking what's wrong\nor missing.\n\nBefore you send a chunk, check it: does it describe something they'll\nlook at, like a page, a screen, a schedule, or a printout? If so, put a\ntext sketch next to the description. If the look itself is theirs to\ndecide and they haven't seen the visual companion offer yet, send the\noffer instead (its own message, below) and hold the chunk for the next\nmessage. Once they've accepted, put a mockup next to the description.\n\n## Size the Work\n\nOnce you understand what they want and they've picked an approach, say\nhow big the work is in plain words. They can override it.\n\n| Size | The design doc |\n|------|----------------|\n| A small change | a short one: what you already covered together, written down |\n| A project | the full written design (below) |\n\nShort or full, the design doc has an **Approaches** part: the two or\nthree ways you considered building it, what each trades off, which one\nthey picked, and why. They pick in the conversation, before you write\nthe doc.\n\nIf it grows mid-task, stop, say so, and step up a size.\n\nIf this is really several independent projects, say so, agree on an\norder, and brainstorm them one at a time.\n\n## The Written Design\n\nWrite a plain document a talented builder in the domain could plan\nfrom without going back to your human partner. Cover:\n\n- intent and the why\n- goals, non-goals, anti-goals\n- constraints\n- approaches (above)\n- the parts of the how they decided, as they decided them\n- what's left to the builder\n\nFor a small change, the short design covers the same points in a line\nor two each and goes straight to your human partner, without the\nbuilder check.\n\n**Where it goes:** in a software repo,\n`docs\u002Fsuperpowers\u002Fspecs\u002FYYYY-MM-DD-\u003Ctopic>-design.md`, committed.\nOtherwise, pick a sensible place and say where. Your human partner's\npreferences override both.\n\n**Builder check** (for a project): dispatch a fresh subagent with\n`builder-check-prompt.md` in this directory. When you tell your human\npartner you're writing it up, say a reviewer will read it first and you\nmay come back once with a few questions. Don't hand over the document\nuntil the check is back. Sort what the builder asks into three piles:\n\n- **Answered already** by the conversation or the project: put the answer\n  in the document.\n- **Minor:** a sensible builder could settle it without changing what gets\n  built. Settle it yourself and mark it in the document as your call.\n- **Theirs:** only your human partner can answer it, and the answer changes\n  what gets built.\n\nBring the \"theirs\" pile in one message, most important first. Update the\ndocument with their answers, then hand it over with a short list of the\ncalls you made so they can check those while reading. That's the only\nround of questions the check produces. Without a subagent tool, read the\ndocument as that builder yourself.\n\n\u003CHARD-GATE>\nNothing gets built until your human partner approves the design doc:\nthe short one for a small change, the full one for a project.\nBuilding includes writing product code, scaffolding, installing\ndependencies, creating projects, and invoking an implementation skill.\nReading and exploring are fine.\n\nTwo exceptions. If they opted out of the questions, the skill is done\nand the gate goes with it. A spike they said yes to may be built; it\nstays labeled throwaway, and keeping what it produced is a new request\nthat comes back through this gate.\n\nAfter the design doc is approved, the next step is the plan: invoke\nsuperpowers:writing-plans and no other skill.\n\u003C\u002FHARD-GATE>\n\n## Red Flags\n\n| Thought | Reality |\n|---------|---------|\n| \"I'll offer a menu of what they might want\" | Options steer. Ask them to describe it first. |\n| \"I'll fill in sensible defaults\" | Good. Say them out loud. A default they never heard is one they couldn't reject. |\n| \"I've answered their questions, so I'll write the doc\" | Lay out the approaches first, in a message of their own (or, when nothing was open from the start, in your first message's short design). |\n| \"I should explain the process first\" | Ask your question. The process shows itself. |\n| \"They said 'sounds good' to the idea\" | Approval covers what you showed them. A design doc you haven't written isn't approved. |\n| \"The spike works, I'll keep building on it\" | Keeping it is a new request. Back through the gate. |\n\n## Visual Companion\n\nA browser tab for showing mockups, diagrams, and prototypes. It's a\ntool, not a mode: accepting it doesn't send every question to the\nbrowser.\n\n**Offer it just-in-time.** Offer it the first time one of the moments\nabove comes up, never upfront. The offer is its own message with nothing\nelse in it:\n\n> \"This might be easier if I show you. Want me to open a browser tab with some mockups?\"\n\nIf they decline, stay in text and don't offer again unless they raise it.\n\n**Per question, ask: would they understand this better by seeing it?**\nMockups, layouts, diagrams, and side-by-side designs go in the browser.\nRequirements, scope, tradeoffs, and conceptual choices stay in text. A\nquestion about a UI topic isn't automatically a visual question.\n\nIf they accept, read `visual-companion.md` in this directory before\nstarting the server.\n",{"name":5,"description":7},"main","7092b664627bf326748a6fcbf27fee6a34c4da1d","skills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming",0,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills","https:\u002F\u002Fgithub.com\u002Fmdnaimul22","AI Agents Workflows Automation | Specializing in Python, FastAPI, MCP Agents & Custom ERP.","2026-11-11 21:16:57",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add mdnaimul22\u002Fhuman-skills --skill brainstorming",{"tool":57,"command":58},"bunx","bunx skills add mdnaimul22\u002Fhuman-skills --skill brainstorming",{"tool":60,"command":61},"pnpm","pnpm dlx skills add mdnaimul22\u002Fhuman-skills --skill brainstorming","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002FSKILL.md",true,[65,71,77,81,85,89,93],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"builder-check-prompt.md","REFERENCE","参考文档",881,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fbuilder-check-prompt.md",{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"scripts\u002Fframe-template.html","SCRIPT","脚本",8094,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fscripts\u002Fframe-template.html",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"scripts\u002Fhelper.js",5615,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fscripts\u002Fhelper.js",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"scripts\u002Fserver.cjs",25699,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fscripts\u002Fserver.cjs",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002Fstart-server.sh",7315,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fscripts\u002Fstart-server.sh",{"path":90,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fstop-server.sh",3263,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fscripts\u002Fstop-server.sh",{"path":94,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":95,"sourceHtmlUrl":96},"visual-companion.md",13413,"https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fbrainstorming\u002Fvisual-companion.md",[98,106,131,152,171,186],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":105},"01M72JT3YP1SQHD0MANGDXQ4RT","higgsfield-websites","Build, edit, and deploy full-stack websites, apps and games via the Higgsfield CLI (`higgsfield website …`). Each is a React 19 + TanStack Start SSR app in one Cloudflare Worker (D1\u002FR2\u002FKV\u002FDO\u002FContainers). THREE product types, picked via `--type` on create: `website` (standalone, no Higgsfield integration — references\u002Fwebsite-flow.md), `app` (Sign in with Higgsfield + fnf SDK, Quanta — references\u002Fapp-flow.md), `game` (realtime multiplayer rooms — references\u002Fgame-flow.md). Routes to the right flow; each carries its own rules and deploy\u002Fpublish gates.\nUse when: \"build me a website\", \"make a landing page\", \"create a web app\", \"build a SaaS dashboard \u002F portfolio\", \"make me a game\", \"deploy this site\", \"publish\". Also owns GAME ART: \"make a spritesheet\", \"tileable texture\", \"animate a 3D character\", game music\u002FSFX — see the game-* references.\nNOT for: single image\u002Fvideo\u002Faudio generation (higgsfield-generate), product photos (higgsfield-product-photoshoot), marketplace cards (higgsfield-marketplace-cards).","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fhiggsfield-ai_skills\u002Fhiggsfield-websites\u002FSKILL.md",[],[],"2026-11-10 22:39:42",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":124,"publishedAt":38},"01M70JPK8HAXXA85P7Q8NKZZYG","writing-skills","Use when creating new skills, editing existing skills, or verifying skills work before deployment","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-skills\u002FSKILL.md",[112,115,120,121],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[125,126,127,128,32,129,25,130,28],"writing","writing skills","editing","deployment","Existing","when",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":142,"publishedAt":38},"01M70JP4PHBH1CQVVDWZ94W159","writing-plans","Use when you have a spec or requirements for a multi-step task, before touching code","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fwriting-plans\u002FSKILL.md",[137,138,139],{"categoryNo":113,"categoryName":114,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":116,"categoryName":117,"taxonomyType":118,"taxonomyTypeDesc":119},{"categoryNo":140,"categoryName":141,"taxonomyType":118,"taxonomyTypeDesc":119},"01JBSEEDCAT000000000000030","开发工程师",[125,143,144,26,130,145,146,32,147,148,149,150,151],"writing plans","plans","code","for","requirements","task","multi","spec","multi-step task",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":158,"publishedAt":38},"01M70JNTYVGXFZT8PASZ844TH8","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fverification-before-completion\u002FSKILL.md",[],[159,160,161,162,163,164,32,165,166,167,130,168,28,169,170],"verification","verification before completion","complete","about","output","assertions","prs","evidence","claim","claims","commands","running",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":178,"publishedAt":38},"01M70JNGVSQDESWN0Q5BPJ875V","using-superpowers","Use when starting any conversation - establishes how to find and use skills, requiring skill invocation before ANY response including clarifying questions","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-superpowers\u002FSKILL.md",[177],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[179,180,181,182,32,130,183,184,185],"using superpowers","superpowers","conversation","how to","how","find","questions",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":38},"01M70JN57CE588NPYPYTWH1DWG","using-git-worktrees","Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback","https:\u002F\u002Fgithub.com\u002Fmdnaimul22\u002Fhuman-skills\u002Fblob\u002Fmain\u002Fskills\u002Fstorage\u002Fobra_superpowers\u002Fusing-git-worktrees\u002FSKILL.md",[],[193,194,195,196,197,198,130,28,199,200,201,202,203,204,205,144,32,206,207],"using git worktrees","Using git","git","worktrees","git worktrees","implementation","git worktree","worktree","native","Tools","isolation","fallback","feature","via","workspace"]