brainstorm — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited brainstorm (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 entering the Brainstorm Phase of the Structured Agentic Development Workflow.
Output style: Check memory for workflow-config:caveman-level. If set, adapt your output brevity to that level while preserving technical accuracy.<HARD-GATE> Do NOT write code, create plan files, scaffold projects, or take ANY implementation action during brainstorming. Code is the LAST thing we touch — not the first. This applies regardless of how simple the task seems. You are thinking, not building. </HARD-GATE>
Explore the problem space for: $ARGUMENTS
Restate the problem in your own words. Identify the core need vs. nice-to-haves.
What exists today? What code, patterns, or infrastructure is already in place that this work touches?
You MUST include both ends of the spectrum — don't just propose variations of the same idea:
For each approach:
Before making your recommendation, ask yourself:
Which approach do you recommend and why? What would change your recommendation?
What do you need the human to clarify before planning begins?
Once the user has picked a direction (or the discussion has reached a natural conclusion), ask the user if they'd like to save the discussion as a decision document. Brainstorming sessions are where architectural decisions are made and trade-offs are weighed — this context is valuable and worth preserving.
If the user agrees, write a decision document to docs/discussions/YYYY-MM-DD-<topic>.md with this structure:
# Decision: [Topic]
*Date: YYYY-MM-DD*
## Problem
[What we were trying to solve]
## Approaches Considered
### [Approach A name]
- **How it works:** [summary]
- **Pros:** [list]
- **Cons:** [list]
- **Impact:** [blast radius summary]
### [Approach B name]
...
## Decision
**Chosen approach:** [name]
**Why this approach won:**
- [key reason 1]
- [key reason 2]
**Why the others were rejected:**
- [Approach X]: [specific reason it lost]
- [Approach Y]: [specific reason it lost]
## Consequences
- [What this decision enables]
- [What this decision makes harder or rules out]
- [What to watch for / revisit if assumptions change]When the human picks a direction, suggest transitioning to /write-plan to formalize the approach into a phased implementation plan.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.