brainstorming — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited brainstorming (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
Before you reply, ask yourself: what do I know about what they want, and why?
blue"). This is a quick, clear task. Do it, and say what you did.
Before you start implementing, you must, in order:
human partner pick one (see Lay out the approaches).
Two things aren't implementing: a spike they said yes to (see Spike to feel things out), and doing what they asked once they've opted out of the questions.
In an existing project, or when they've given you context (a spec, a plan, a handoff, files they pointed at, earlier conversation), dig in before your first message. Read what they referred to and the code or material it connects to, and keep reading until you can explain how the relevant parts work today and what this change would touch. Never ask what the project or their context already answers.
Move the work forward, with one of these:
request): aim for about 200 words for the whole message. Echo their request back in your own words, so they can see whether you've got its shape: what they want, who it's for, and why, as far as they've said. Add what you found that bears on it: how the relevant parts work today and what the change would touch. If you found something they may not have considered that would change what they're asking for or how it has to be built, like a constraint, a conflict, or a cheaper path, say so plainly. How to build it comes later, once you understand what they want (see Lay out the approaches). End with one line inviting corrections, then one question about what they want: the thing their request leaves open whose answer would most change what gets built. Specs are often incomplete, so confirm before you build on one.
biggest thing their request leaves unsettled. Say why you're asking: what the answer would change about what you build. For "a website for my bakery": "If it's mostly for people deciding whether to stop by, I'd lead with hours and what's in the case today; taking orders is a different site. What do you want someone to do when they land on it?"
How the message ends depends on whether their message asked for brainstorming:
design discussion): end with your question. They want this conversation.
question, add a light, one-line offer to just get going instead, like "Or if you'd rather I just dive in, 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.
That's the whole message.
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. You never need to quote this skill to your human partner.
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:
if it technically works)
Make every question specific to their project and what they've told you. Ask Socratically, the way a sharp colleague would: build each question on their last answer or on something you found, so it helps them think through a consequence or a case they may have missed ("Voting closes before the meeting, and two members joined this month. Does someone who joins mid-round get a vote?"). When the reason isn't already plain, say what you're hoping to learn or what the answer would change. A proposal they can correct, plus your reason for it, often beats a question.
Offer recon. Once you have a bit of grounding and looking further would help, offer to go look: deeper into their codebase or project, their own files and data, or the web. Say what you'd look for. They decide whether you go.
Lay out the approaches. Once you understand what they want, and before you write anything up, put the ways of building it in a message of its own. Come up with several real alternatives and drop the weak ones, including any that work against why they want it and any the existing work rules out. Present the two or three that remain, grounding each in what the project actually does and saying what it trades off. Recommend one and say why, then ask which way they want to go. When there's genuinely one sensible way, say so and explain why the others don't fit. This is for how it gets built; for what they want, get them describing first.
Show, don't tell. Offer the visual companion (below) whenever seeing would help more than reading:
Once they've accepted, use it for mockups to react to, side-by-side options, and throwaway prototypes they can click.
Spike to feel things out. Agentic work is waterfall, but very, very fast. A quick throwaway build is often the cheapest way to learn what they want or whether something works. Offer one when it would help. When they just want to spike, get out of the way. Spikes get no tests or minimal ones, aren't bulletproof, and skip the plan, implementation, and review process. Bring what the spike taught you back into the conversation.
Play back as you go. As soon as you understand one part well enough to describe it (what it's for and who it serves, say, or how one piece behaves), describe that part back in about 200-300 words, then return to questions about the next part. Playback and questions alternate through the whole conversation; the last chunk covers whatever is left.
Only what they said goes in as theirs. Anything you filled in goes in as your proposal, with your reason. End each chunk by asking what's wrong or missing.
Before you send a chunk, check it: does it describe something they'll look at, like a page, a screen, a schedule, or a printout? If so, and they haven't seen the visual companion offer yet, send the offer instead (its own message, below) and hold the chunk for the next message. Once they've accepted, put a mockup next to the description.
Once you understand what they want and they've picked an approach, say how big the work is in plain words. They can override it.
| Size | The design doc |
|---|---|
| A small change | a short one: what you already covered together, written down |
| A project | the full written design (below) |
Short or full, the design doc has an Approaches part: the two or three ways you considered building it, what each trades off, which one they picked, and why. They pick in the conversation, before you write the doc.
If it grows mid-task, stop, say so, and step up a size.
If this is really several independent projects, say so, agree on an order, and brainstorm them one at a time.
Write a plain document a talented builder in the domain could plan from without going back to your human partner. Cover:
For a small change, the short design covers the same points in a line or two each and goes straight to your human partner, without the builder check.
Where it goes: in a software repo, docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md, committed. Otherwise, ask. Your human partner's preferences override both.
Builder check (for a project): dispatch a fresh subagent with builder-check-prompt.md in this directory. When you tell your human partner you're writing it up, say a reviewer will read it first and you may come back once with a few questions. Don't hand over the document until the check is back. Sort what the builder asks into three piles:
in the document.
built. Settle it yourself and mark it in the document as your call.
what gets built.
Bring the "theirs" pile in one message, most important first. Update the document with their answers, then hand it over with a short list of the calls you made so they can check those while reading. That's the only round of questions the check produces. Without a subagent tool, read the document as that builder yourself.
<HARD-GATE> Nothing gets built until your human partner approves the design doc: the short one for a small change, the full one for a project. Building includes writing product code, scaffolding, installing dependencies, creating projects, and invoking an implementation skill. Reading and exploring are fine.
Two exceptions. If they opted out of the questions, the skill is done and the gate goes with it. A spike they said yes to may be built; it stays labeled throwaway, and keeping what it produced is a new request that comes back through this gate.
After the design doc is approved, the next step is the plan: invoke superpowers:writing-plans and no other skill. </HARD-GATE>
| Thought | Reality |
|---|---|
| "I'll offer a menu of what they might want" | Options steer. Ask them to describe it first. |
| "I'll fill in sensible defaults" | Good. Say them out loud. A default they never heard is one they couldn't reject. |
| "I've answered their questions, so I'll write the doc" | Lay out the approaches first, in a message of their own. |
| "I should explain the process first" | Ask your question. The process shows itself. |
| "They said 'sounds good' to the idea" | Approval covers what you showed them. A design doc you haven't written isn't approved. |
| "The spike works, I'll keep building on it" | Keeping it is a new request. Back through the gate. |
A browser tab for showing mockups, diagrams, and prototypes. It's a tool, not a mode: accepting it doesn't send every question to the browser.
Offer it just-in-time. Offer it the first time one of the moments above comes up, never upfront. The offer is its own message with nothing else in it:
"This might be easier if I show you. Want me to open a browser tab with some mockups?"
If they decline, stay in text and don't offer again unless they raise it.
Per question, ask: would they understand this better by seeing it? Mockups, layouts, diagrams, and side-by-side designs go in the browser. Requirements, scope, tradeoffs, and conceptual choices stay in text. A question about a UI topic isn't automatically a visual question.
If they accept, read visual-companion.md in this directory before starting the server.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.