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.
This skill enforces design-before-implementation to prevent costly rework and clarify requirements.
HARD-GATE: No code or implementation until design is approved.
This is non-negotiable. Time pressure, user authority, simplicity, or urgency are NOT valid reasons to skip design.
Before asking questions, review existing context to avoid redundant questions:
workspace/docs/ for existing designs or decisionsAsk 2-5 clarifying questions one at a time to understand:
Rules:
Present 2-3 distinct approaches with:
Keep this section brief (3-5 sentences per approach).
After user selects approach, present detailed design in digestible sections:
A. Architecture Overview
B. Implementation Details
C. Open Questions
D. Next Steps
Explicitly ask: "Does this design look good? Any changes needed?"
Wait for approval. Do NOT proceed to implementation without explicit confirmation.
Upon approval, save the design to:
workspace/docs/plans/YYYY-MM-DD-<topic>-design.mdInclude:
After saving, invoke the writing-plans skill:
"Design approved and saved. Invoking writing-plans skill to break this into executable tasks."
Common excuses for skipping design and why they're wrong:
| Excuse | Why It's Wrong | Counter |
|---|---|---|
| "User is in a hurry" | Quick design (2-5 min) prevents slow rework (hours/days) | Time pressure makes design MORE important, not less |
| "User knows what they want" | Users know goals, not implementation details | Questions reveal hidden requirements and assumptions |
| "It's simple, doesn't need design" | "Simple" projects hide the most assumptions | Simple projects need simple designs (still designs) |
| "No long discussions needed" | Design ≠ long discussion | Design can be 2 minutes. Approval can be one word. |
| "User gave detailed specs" | Specs describe what, not how | Design clarifies architecture, trade-offs, and approach |
| "Just a prototype/MVP" | Prototypes become production code | Good architecture costs the same time upfront |
| "We can refactor later" | Later never comes | Design now or debug forever |
The rule: If you're typing code, you skipped a step.
Watch for these signs you're about to violate the hard-gate:
🚩 You're thinking about file structure before getting approval 🚩 You're considering library choices before presenting approaches 🚩 You're writing pseudocode before user responds 🚩 You catch yourself thinking "I'll just start with..." 🚩 You're rationalizing why THIS case is different 🚩 User says "just start" and you feel compelled to obey
When you see red flags: Stop. Return to step 2 (questions) or step 5 (get approval).
Main session (direct user chat):
Shared contexts (Discord, groups):
All designs save to:
workspace/docs/plans/YYYY-MM-DD-<descriptive-name>-design.mdExamples:
2026-02-25-todo-cli-design.md2026-02-25-user-auth-design.md2026-02-25-api-refactor-design.mdAfter approval and save:
writing-plans skillRespond with:
"I understand you want to move quickly. A 2-minute design will save hours of rework. Let me ask 2 quick questions, propose an approach, and get your thumbs-up. Total time: 3 minutes. Deal?"
Even trivial changes get lightweight design:
"Quick design: Change X in file Y because Z. Sound good?"
Wait for confirmation before implementing.
If user provides existing design document:
Reference previous design:
"Building on the design from 2026-02-20-todo-cli-design.md. Proposed change: [describe change]. This affects: [components]. Sound good?"
Wait for approval before implementing.
User: "Build a todo CLI"
Agent: *writes complete Python application*User: "Build a todo CLI"
Agent: "Great! Quick questions:
1. How should todos be stored? (JSON file / SQLite / plain text)
2. Need due dates or just simple list?"
[After answers...]
Agent: "Here are 2 approaches:
A. Simple JSON file + Python CLI
- Pros: Easy to inspect/backup, no dependencies
- Cons: Not ideal for large lists, manual file locking
B. SQLite + Python CLI
- Pros: Better for large lists, built-in queries
- Cons: Binary format, slightly more complex
I recommend A for simplicity unless you expect >1000 todos. Thoughts?"
[After user picks A...]
Agent: "Design:
Architecture:
- Single Python script: todo.py
- JSON storage: ~/.todos.json
- Commands: add, list, done, delete
Implementation:todo.py (main CLI)
~/.todos.json structure: [ {"id": 1, "text": "...", "done": false}, ... ]
Does this design work for you?"
[Wait for approval...]
Agent: "Approved! Saving to workspace/docs/plans/2026-02-25-todo-cli-design.md and invoking writing-plans skill."You've successfully used this skill when:
✅ No code written before approval ✅ At least 2 clarifying questions asked ✅ Multiple approaches presented ✅ Design saved to workspace/docs/plans/ ✅ User gave explicit approval ("yes", "looks good", "approved", etc.) ✅ writing-plans skill invoked for next phase
You've violated this skill if:
❌ Code appears before design approval ❌ Jumped straight to implementation ❌ Rationalized why design wasn't needed ❌ User pressure caused you to skip steps ❌ Wrote pseudocode before getting approach approval ❌ Saved design but implemented before invoking writing-plans
When you catch yourself failing: Stop immediately. Delete any code. Return to the process.
Based on obra/superpowers methodology. Pressure-tested and hardened against rationalization.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.