brainstorming — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited brainstorming (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
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.
Treat this as a checkpoint you must pass through before writing code for anything complex, underspecified, or new.
Two responsibilities live here:
| Incoming request | Required move |
|---|---|
| "Build / create / make X" with thin detail | 🛑 Pose ~3 questions first |
| A sizeable feature or architectural choice | 🛑 Pin down direction before coding |
| "Change / update / tweak X" | 🛑 Lock the scope before touching it |
| Fuzzy or open-ended ask | 🛑 Probe purpose, audience, limits |
Before generating any questions, look for accumulated context so you don't re-ask what's already settled:
CHECK: Is .aim-agents/memory/MEMORY.md present?
├─ Found → Read its index, quietly reuse relevant prior decisions,
│ and drop any question the memory already answers.
└─ Absent → Run the full gate below as normal..aim-agents/memory/ for anything already decided on this topic./remember [decision].This gate is the backbone of the /brainstorm workflow.
⛔ Canned question lists are off-limits. Every question is generated from the actual request. The full method lives in dynamic-questioning.md; the essentials:
| Guiding idea | What it means in practice |
|---|---|
| Questions expose consequences | A question earns its place only by tying to a real architectural fork |
| Frame before content | First classify the work — greenfield, addition, refactor, or debug |
| Fewest questions that matter | Keep a question only if it rules out an implementation path |
| Ask, don't presume | Offer the options and their trade-offs instead of guessing |
1. Read the request → name the domain, the features, the scale signals
2. Spot the forks → which choices block progress vs. which can wait
3. Rank the asks → P0 blocking > P1 high-leverage > P2 optional
4. Dress each one → state the choice, the stakes, the options, the default### [PRIORITY] **[THE DECISION]**
**Question:** [a sharp, answerable question]
**Why it matters:**
- [the architectural consequence it triggers]
- [what it moves: cost / effort / timeline / scale]
**Options:**
| Option | Upside | Downside | Fits when |
|--------|--------|----------|-----------|
| A | [+] | [-] | [scenario] |
**Default if silent:** [the fallback + a one-line reason]Reach for dynamic-questioning.md when you need the per-domain question banks and the generation algorithm.
Why it matters: visible, actionable status is what earns trust during a long-running task.
Keep a running board:
| Agent | State | Working on | Done |
|---|---|---|---|
| [name] | ✅ 🔄 ⏳ ❌ ⚠️ | [what it's doing] | [% or count] |
Legend:
| Mark | Reads as | When to use |
|---|---|---|
| ✅ | Done | Finished cleanly |
| 🔄 | Active | Currently in flight |
| ⏳ | Held | Stuck on a dependency |
| ❌ | Failed | Broke, needs a look |
| ⚠️ | Caution | A concern, but not a blocker |
Why it matters: a failure is a prompt for clear communication, not a dead end.
Walk every error through the same arc:
1. Name it → say plainly that something failed
2. Translate it → explain the cause in human terms
3. Offer ways out → give concrete fixes, each with its trade-off
4. Hand it back → let the user pick or supply another routeCommon cases and how to meet them:
| Situation | How to respond |
|---|---|
| Port already in use | Suggest a free port or offer to stop the squatter |
| Package not installed | Install it, or ask first if that's wiser |
| Build won't compile | Surface the exact error and a proposed fix |
| Message is cryptic | Request specifics — console output, a screenshot, repro steps |
Why it matters: a clean finish confirms the win and points the way forward.
Close out in this order:
1. A short "it worked" note
2. A concrete recap of what changed
3. A way to check or test it yourself
4. A nudge toward the sensible next step| Habit | What it looks like |
|---|---|
| Brief | Skip filler, land the point |
| Scannable | Lean on icons (✅ 🔄 ⏳ ❌) so status reads at a glance |
| Concrete | "~2 minutes," never "give it a moment" |
| Optioned | When blocked, lay out more than one road |
| Forward-looking | Always close with a suggested next move |
| Trap | Cost |
|---|---|
| Coding before you understand the ask | Effort sunk into the wrong problem |
| Inventing requirements instead of asking | Output nobody wanted |
| Gold-plating version one | Value arrives late |
| Brushing past stated constraints | A solution that can't be used |
| Hedging with "I think…" | Doubt that a question would resolve |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.